组提交与并行复制

基于组提交的并行复制

如何表示并行度

为了表示主库并行度，在binlog row event增加了如下的标识。

#160807 15:48:10 server id 100  end_log_pos 739 CRC32 0x2237b2ef        GTID    last_committed=0        sequence_number=3
SET @@SESSION.GTID_NEXT= '8108dc48-47de-11e6-8690-a0d3c1f20ae4:3'/*!*/;

即在gtid_event中增加两个字段：

long long int last_committed;
long long int sequence_number;

sequence_number 是自增事务 ID，last_commited 代表上一个提交的事务 ID。
如果两个事务的 last_commited 相同，说明这两个事务是在同一个 Group 内提交的。

生成时机

每个事务GTID EVENT中last_committed与sequence_number的生成时机。
last_committed是在prepare阶段，binlog prepare时将上一次COMMIT队列中最大的sequence_number写入到本次事务的last_committed中。
sequence_number是在flush阶段，和gtid一对一的关系，和gtid生成的时机一致。

如何提高从库并发事务数

调整binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count

Binlog中顺序

按照严格sequence_number顺序一致，但不按照last_committed顺序一致。

image.png

原因是组提交保证flush、sync、commit阶段有序，但是并不保证prepare有序。
如

session 1: insert into t1 value(100, 'xpchild');

session 2: insert into t1 value(101, 'xpchild');
session 1: prepare
session 2: prepare
session 2: commit;

session 3: insert into t1 value(102, 'xpchild');
session 3: prepare
session 3: commit;
session 1: commit;

出来的结果是这样的

#160807 15:47:58 server id 100  end_log_pos 219 CRC32 0x3f295e2b        GTID    last_committed=0        sequence_number=1
### INSERT INTO `tp`.`t1`
### SET
###   @1=101 /* INT meta=0 nullable=0 is_null=0 */
.....
#160807 15:48:05 server id 100  end_log_pos 479 CRC32 0xda52bed0        GTID    last_committed=1        sequence_number=2
### INSERT INTO `tp`.`t1`
### SET
###   @1=102 /* INT meta=0 nullable=0 is_null=0 */
......
#160807 15:48:10 server id 100  end_log_pos 739 CRC32 0x2237b2ef        GTID    last_committed=0        sequence_number=3
### INSERT INTO `tp`.`t1`
### SET
###   @1=100 /* INT meta=0 nullable=0 is_null=0 */

案例延伸自：http://mysql.taobao.org//monthly/2016/08/01/

LOGICAL CLOCK并行复制

Logical Clock并行复制的实现，最初是Commit-Parent-Based方式，同一个commit parent的事务可以并发执行。但这种方式会存在可以保证没有冲突的事务不可以并发，事务一定要等到前一个commit parent group的事务全部回放完才能执行。后面优化为Lock-Based方式，做到只要事务和当前执行事务的Lock Interval都存在重叠，即保证了Master端没有锁冲突，就可以在Slave端并发执行。LOGICAL CLOCK可以保证非并发执行事务，即当一个事务T1执行完后另一个事务T2再开始执行场景下的Causal Consistency。
Commit-Parent-Based

image.png

Lock-Based

image.png

WRITESET

8.0 引入了参数 binlog_transaction_dependency_tracking 来控制事务依赖模式，让备库根据 commit timestamps 或者 write sets 并行回放事务，有三个取值

* COMMIT_ORDERE：使用 5.7 Group commit 的方式决定事务依赖
* WRITESET：使用 WriteSet 的方式决定判定事务直接的冲突，发现冲突则依赖冲突事务，否则按照 COMMIT_ORDERE 方式决定依赖
* WRITESET_SESSION：在 WRITESET 方式的基础上，保证同一个 session 内的事务不可并行

binlog_transaction_dependency_tracking参数的作用时间是在组提交的Flush阶段。

image.png

WRITESET是在COMMIT_ORDERE做的进一步优化，通过向前优化last_committed，比如把last_committed从125优化到120，从而实现更高的并发度。
看代码当binlog_transaction_dependency_tracking为COMMIT_ORDERE时只调用 m_commit_order.get_dependency(thd, sequence_number, commit_parent)，当binlog_transaction_dependency_tracking为WRITESET时，在m_commit_order.get_dependency(thd, sequence_number, commit_parent)的基础上又调用了m_writeset.get_dependency(thd, sequence_number, commit_parent)。

/**   
  Get the dependencies in a transaction, the main entry point for the
  dependency tracking work.
*/
void Transaction_dependency_tracker::get_dependency(THD *thd,
                                                    int64 &sequence_number,
                                                    int64 &commit_parent) {
  sequence_number = commit_parent = 0;

  switch (m_opt_tracking_mode) {
    case DEPENDENCY_TRACKING_COMMIT_ORDER:
      
      /* COMMIT_ORDERE 只调用 m_commit_order.get_dependency() */
      m_commit_order.get_dependency(thd, sequence_number, commit_parent);
      break;
    case DEPENDENCY_TRACKING_WRITESET:
      m_commit_order.get_dependency(thd, sequence_number, commit_parent);
      
      /* WRITESET 在 COMMIT_ORDERE 的基础上再调用 m_writeset.get_dependency() */
      m_writeset.get_dependency(thd, sequence_number, commit_parent);
      break;
    case DEPENDENCY_TRACKING_WRITESET_SESSION:
      m_commit_order.get_dependency(thd, sequence_number, commit_parent);
      m_writeset.get_dependency(thd, sequence_number, commit_parent);
      
      /* WRITESET_SESSION 在 WRITESET 的基础上再调用 m_writeset_session.get_dependency */
      m_writeset_session.get_dependency(thd, sequence_number, commit_parent);                                                                                                                               
      break;
    default:
      DBUG_ASSERT(0);  // blow up on debug
      /*
        Fallback to commit order on production builds.
       */
      m_commit_order.get_dependency(thd, sequence_number, commit_parent);
  }
}

怎么优化的

上文说了WRITESET是在COMMIT_ORDERE做的进一步优化，来看下怎么优化的。
WRITESET的前提是没有主键或唯一键冲突的事务就可以并行复制。
MySQL会有一个变量来存储已经提交的事务HASH值，所有已经提交的事务所修改的主键（或唯一键）的值经过hash后都会与那个变量的集合进行对比，来判断修改的行是否与其冲突，最终确定last_committed可以向前优化到的值。
这个变量的周期是什么？
变量的大小由binlog_transaction_dependency_history_size控制，参数默认值为25000。代表的是我们说的 Writeset 历史 MAP 中元素的个数。如前面分析的 Writeset 生成过程中修改一行数据可能会生成多个 HASH 值，因此这个值还不能完全等待于修改的行数，可以理解为如下：

binlog_transaction_dependency_history_size/2=修改的行数 * （1+唯一键个数）

当历史 MAP会清空，所以历史MAP可以优化的区间是一轮一轮的，历史MAP会清空老事务的数据，写入更新事务的数据。
于此同时，清空历史MAP也会导致last_committed可以优化到最小值变大，比例历史MAP当前存的是事务50~60的事务hash值，当清空后开始写入61+的事务hash值，因为最早只能跟61对比了，所以last_commited无法优化到61之前。
其次内存中还维护一个叫做 m_writeset_history_start 的值，用于记录 Writeset 的历史 MAP 中最早事务的 seq number,即上文假设的50和61。如果 Writeset 的历史 MAP 满了就会清理这个历史 MAP 然后将本事务的 seq number 写入 m_writeset_history_start ，作为最早的 seq number 。后面会看到对于事务 last commit 的值的修改总是从这个值开始然后进行比较判断修改的，如果在 Writeset 的历史 MAP 中没有找到冲突那么直接设置 last commit 为这个 m_writeset_history_start 值即可。
一个具体的案例参看下文第7节。
https://mp.weixin.qq.com/s?__biz=MzU2NzgwMTg0MA==&mid=2247485508&idx=1&sn=c6d0e98a02da81729618713b6f3460f9&chksm=fc96eadbcbe163cd78a64041fbaeebf33106f46e5d787bf1a6c6af52cc1ae4da1161a42864e2&scene=21%23wechat_redirect

http://mysql.taobao.org//monthly/2016/08/01/
https://blogs.vicsdf.com/article/974
https://zhuanlan.zhihu.com/p/87963038
http://mysql.taobao.org/monthly/2018/06/04/