速度提升5~10倍，基于WRITESET的MySQL并行复制 #M1013#

本文转自 https://mp.weixin.qq.com/s/oj-DzpR-hZRMMziq2_0rYg备忘

MySQL主从复制一致性问题早已解决，然而主从复制延迟的问题依然困扰着开发人员和DBA。开发通常想将从机作为读写分离的一种选择，奈何复制延迟导致实际生产上，依然选择主实例（Master）作为查询源。对于DBA来说，高可用切换时，从发现到切换的整个过程堪称秒级切换，只是在最后开放写入这个过程中，需要大量时间等待从机的回放（Applier），整个过程被迫从秒级切换降级为分钟级切换。曾经DBA面试的一道经典题，其实是没有什么比较好的答案，因为这是MySQL复制机制的硬伤：

请问你是如果解决复制延迟的？

为此，MySQL从5.6版本开始支持并行复制机制，官方称为：MTS（Multi-Thread Slave），经过几个版本的迭代，目前MTS支持以下几种机制：

版本	MTS机制	实现原理
5.6	Database	基于库级的并行复制
5.7	COMMIT_ORDER	基于组提交的并行复制
5.7.22	WRITESET / WRITESET_SESSION	基于WRITESET的并行复制

基于Database级别的并行复制效果并不特别好，因为大多数生产的架构依然习惯于单库多表的架构，这种情况下MTS依然还是单线程的效果。但Database级别并行复制的好处是可以兼容任何二进制日志，从机都可以进行库级别的并行回放。

基于Commit_Order的并行复制是在主数据库实例事务提交时，写入一些额外信息，从而在从机回放时，可以根据这些信息判断是否可以进行并行的回放。这种实现机制的巧妙之处在于：同一组提交的事务之间是不冲突的，因此可以并行回放

在代码实现中，同一组的事务拥有同一个parent_commit（父亲），在二进制日志中可以看到类似如下的内容:

last_commit相同可视为具有相同的parent_commit，事务在同一组内提交，因此在从机回放时，可以并行回放。例如last_committed = 0的有7个事务，sequence_number 1 ~ 7，则这7个可以并行执行。last_committed = 7有6个事务，sequence_number 9 ~ 14，可以并行回放执行。

在上面的并行执行中，last_committed = 1 的事务需要等待last_committed = 0的7个事务完成，同理，last_committed = 7的6个事务需要等待last_committed = 1的事务完成。但是MySQL 5.7还做了额外的优化，可进一步增大回放的并行度。思想是LOCK-BASED，即如果两个事务有重叠，则两个事务的锁依然是没有冲突的，依然可以并行回放。

在上面的例子中，last_committed = 1的事务可以和last_committed = 0的事务同时并行执行，因为事务有重叠。具体来说，这表示last_committed = 0的事务进入到COMMIT阶段时，last_committed的事务进入到了PREPARE阶段，即事务间依然没有冲突。具体实现思想可见官方的Worklog： WL#7165: MTS: Optimizing MTS scheduling by increasing the parallelization window on master

基于COMMIT_ORDER的并行复制机制虽好，然而需要有一个条件：每组提交事务要足够多。即，业务量要足够大。但是当你的业务量比较小，并发度不够时，基于COMMIT_ORDER的并行复制依然会退化为单线程复制。虽然有经验的小伙伴知道可以通过调整参数binlog_group_commit_sync_delay、binlog_group_commit_sync_no_delay_count来优化组提交的效率，但最终的效果其实并不理想。只能说某些情况有些用，大部分情况依然然并卵。

为了进一步解决复制延迟问题，MySQL 5.7.22版本推出了基于WriteSet机制的并行复制，从机并行执行无需依赖组复制机制。简单来说，WriteSet并行复制的思想是：不同事务的不同记录不重叠，则都可在从机上并行回放，可以看到并行的力度从组提交细化为记录级。

所谓不同的记录，在MySQL中用WriteSet对象来记录每行记录，从源码来看WriteSet就是每条记录hash后的值（必须开启ROW格式的二进制日志），具体算法如下：

WriteSet=hash(index_name | db_name | db_name_length | table_name | table_name_length | value | value_length)

上述公式中的index_name只记录唯一索引，主键也是唯一索引。如果有多个唯一索引，则每条记录会产生对应多个WriteSet值。另外，Value这里会分别计算原始值和带有Collation值的两种WriteSet。所以一条记录可能有多个WriteSet对象。举例来说，下面的表t1，有2个唯一索引：

CREATE TABLE t1 (

a BIGINT NOT NULL AUTO_INCREMENT,

b VARCHAR(36) NOT NULL,

c INT NOT NULL,

PRIMARY KEY(a),

UNIQUE KEY idx_b(b)

)CHARSET=utf8mb4

当用户执行INSERT INTO test.t1 VALUES (NULL,UUID(),3)时，对产生多个个WriteSet值，分别是：

WriteSet1=hash(PRIAMRY|test|4|t1|2|1|8)
WriteSet2=hash(PRIAMRY|test|4|t1|2|1(with collation)|8)
WriteSet3=hash(idx_b|test|4|t1|2|'2'|1)
WriteSet4=hash(idx_b|test|4|t1|2|'2'(with collation)|1)

参数transaction_write_set_extraction用来选择hash函数，推荐设置为XXHASH64，相比MURMUR32有更好的散列性。产生的WriteSet对象会插入到WriteSet哈希表，哈希表的大小由参数binlog_transaction_dependency_history_size设置，默认25000。WriteSet哈希表的类型为std::map<uint64,int64>，保存每条记录的WriteSet值和对应的sequence_number。

当事务每次提交时，会计算修改的每个行记录的WriteSet值，然后查找哈希表中是否已经存在有同样的WriteSet，若无，WriteSet插入到哈希表，写入二进制日志的last_committed值不变。若有，则last_committed值更新为sequnce_number。

对于上面的INSERT语句，在插入后WriteSet哈希表中记录的内容为：

Key	Value
WriteSet1	1
WriteSet2	1
WriteSet3	1
WriteSet4	1

若这时另一个事务再次执行了INSERT INTO test.t1 VALUES (NULL,UUID(),3),则会产生新的WriteSet对象，但和上述的WriteSet没有冲突，直接插入WriteSet哈希表，表中内容更新为：

Key	Value
WriteSet1	1
WriteSet2	1
WriteSet3	1
WriteSet4	1
WriteSet5	2
WriteSet6	2
WriteSet7	2
WriteSet8	2

接着当用户执行DELETE FROM test.t1 WHERE a = 1，这时事务提交时会发现能在WriteSet哈希表中找到之前a=1对应的WriteSet，因此需要更新对应的sequence_number值，并且这时last_committed值也要更新为对应的sequence_number值：

Key	Value
WriteSet1	3
WriteSet2	3
WriteSet3	3
WriteSet4	3
WriteSet5	2
WriteSet6	2
WriteSet7	2
WriteSet8	2

回放时和基于COMMIT_ORDER的并行复制一样，具有相同的last_committed值可以并行回放，但是由于是基于WriteSet机制的，因此不同的记录能并行执行。同一条记录回放，last_committed值必然不同，必须等待之前的一条记录回放完成后才能执行。

默认MySQL依然还是基于库级别的并行复制配置，因此开启基于WriteSet并行复制需要进行如下的设置：

# master
loose-binlog_transaction_dependency_tracking = WRITESET

loose-transaction_write_set_extraction = XXHASH64
#slave
slave-parallel-type = LOGICAL_CLOCK

slave-parallel-workers = 32

接着用命令mysqlslap来执行上述SQL语句：INSERT INTO test.t1 VALUES (NULL,UUID(),3)，线程设置为1，即单线程执行插入操作:

mysqlslap --query=insert_one.sql --number-of-queries=10 -c 1

虽然是单线程运行，但在二进制日志中可以看到大量相同last_committed值得记录，因此记录在从机都是可以并行执行。其实若继续插入，整个二进制日志中显示的last_committed可能都是1，因为测试的插入操作没有行冲突：

但若是基于Commit_Order的并行复制，由于是单线程中运行，在二进制日志中看到每个事物的last_committed值都不同，回访时依然只能是单线程回放：

根据上述单线程的测试对比，WriteSet的性能比Commit_Order要快5~6倍，效果非常明显。如果是有延迟要追的，WriteSet毫无疑问是胜者。Commit_Order的瓶颈依然是需要主有足够的并发度，实际生产上确很难达到，除非是业务高峰期。MySQL官方测试（来源：https://mysqlhighavailability.com/improving-the-parallel-applier-with-writeset-based-dependency-tracking/）结果如下，当然看看即可，最主要还是自己生产上的实际效果，不过姜老师坚信这次的效果会远好于Commit_Order。