mysql实战45讲--- 26 主备库并行复制策略

主备库并行复制策略

如果备库执行日志的速度低于主库日志生成的速度，那么这个延迟就有可能更长，而且对于一个压力持续比较高的主库来说，备库很可能永远追不上主库

下面介绍备库并行复制能力

谈到主备的并行能力，就关注图中2个黑色的箭头，一个代表主库并行写入，另外一个代表备库并行sql_thread执行relay_log。并行度主库要高于备库。

在主库上，影响并发的原因就是各种锁，由于innodb引擎支持行锁，除了所有并发事务更新同一行（热点行）这种极端场景外，它对业务并发度的支持还是很好的，

所以，在性能测试的时候，并发压测就比单线程时，总的吞吐量高。

而日志在备库上的执行，是由sql_thread线程更新数据（data）的逻辑，如果用单线程的话，就会导致备库应用日志不够快，造成主备延时。

在5.6版本之前，mysql只支持单线程复制

在所有的多线程复制机制，都是把一个sql_thread线程，拆成多个线程

图中的coordinator就是原来的sql_thread，不过现在它不在直接更新数据，只负责读取中转日志和分发事务，真正更新日志的，变成了worker线程，

而work线程的个数，由参数slave_parallel_workers决定，把这个值设置为8~16比较好（32核物理机情况）。

 

事务能不能按照轮询的方式分发给各个worker线程呢，也就是第一个事务的分给worker_1，第二个事务发给worker_2呢

其实是不行的，因为事务被分发给worker后，不同的worker就独立执行了，由于cpu的调度策略，很可能第二个事务最终比第一个事务先执行，

而如果这2个事务刚好更新是同一行，就意味着，同一行上的2个事务，在主备库上执行的顺序相反，导致主备不一致。

同一个事务的多个更新语句，能否分给不同的worker来执行呢

答案是，也不行，会破坏事务逻辑的原子性

所以，coordinator在分发的时候，需要满足一下这2个基本要求

1 不能造成更新覆盖，这要求更新同一行的2个事务，必须分发到同一个worker中

2 同一个事务不能被拆开，必须放到同一个worker中

Mysql 5.5版本的并行复制策略

官方的mysql5.5版本并不支持并发，这里介绍2个版本的并发策略

按表分发策略

基本思路是，如果两个事务更新不同的表，它们就可以并行，因为数据存在表里，所以按表分发，可以保证两个worker不会更新同一行

当然，如果有跨表的事务，还是要把2张表放在一起

可以看到，每个worker线程对应一个hash表用于保存当前这个worker的执行队列里的事务所涉及的表，hash表的key是”库名.表名”，values是一个数字，表示队列中多个事务修改这个表

在有事务分配给worker时，事务里面涉及的表会被加到对应的hash表中，worker执行完成后，这个表会被从hash表中去掉。

上图中，hash_table1表示，在worker_1的”待执行事务队列”里，有4个事务涉及到db1.tb1表，有1个事务涉及到db2.t2，hash_table_2表示，worker_2中油一个事务涉及到更新表t3的数据

假设在图中的情况下，coordinator从中转日志中读入一个新事务T，这个事务修改的行涉及到表t1和t3

现在我们用事务T的分配流程，来看一下分配规则

1 由于事务T中涉及修改表t1，而worker_1队列中有事务在修改表t1，事务T和队列中的某个事务要修改同一表的数据，这种情况我们说事务T和worker_1是冲突的

2 按照这个逻辑，顺序判断事务T和每个worker队列的冲突关系，会发现事务T和worker_2也冲突

3 事务T跟多于一个worker冲突，coordinator线程就进入等待

4 每个worker继续执行，同时修改hash_table，假设hash_table_2里面涉及到修改表t3的事务先执行完成，就会从hash_table_2中把db1.t3这一项去掉

5 这样coordinator会发现跟事务T冲突的worker只有worker_1，因此就把它分配给worker_1线程

6 coordinator继续读下一个中转日志，继续分配事务

也就说，每个事务在分发的时候，跟所有worker的冲突关系包括以下三种
1 如果跟所有worker都不冲突，coordinator线程就会把这个事务分配给最空闲的worker

2 如果跟多于一个worker冲突，coordinator线程就进入等待状态，直到和这个事务存在冲突关系的worker只剩下1个

3 如果只跟1个worker冲突，coordinator线程就把这个事务分配与存在冲突的worker

这个按表分发的方案，在多个表负载均匀的场景里应用效果很好，但是碰到热点表，比如所有的更新事务都涉及到某一个表的时候，所有事务都被分配到同一个worker线程，就变成单线程复制了。

 

按行分发策略

 

要解决热点表的并行复制问题，就需要一个按行并行复制的方案，核心思路是：如果两个事务没有更新相同的行，它们在备库上可以并行执行，这个要求binlog的模式必须是row

这时候，我们判断一个事务T和worker是否冲突，规则就是”修改同一行”

按行复制和按表复制的数据结构差不多，也是为每个worker分配一个hash表，只要实现按行分发，这时候的key，就必须是”库名+表名+唯一键的值”

但是，这个唯一键只有主键id还是不够，需要唯一索引

CREATE TABLE `t26` (
  `id` int(11) NOT NULL,
  `a` int(11) DEFAULT NULL,
  `b` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `a` (`a`)
) ENGINE=InnoDB;

insert into t26 values(1,1,1),(2,2,2),(3,3,3),(4,4,4),(5,5,5);

 

假设，接下来在主库执行2个事务

SESSION A	SESSION B
update t26 set a=6 where id=1;
	update t26 set a=1 where id=2;

可以看到，这两个事务要更新的行的主键值不同，但是如果它们被分到不同的worker，就有可能session B先执行，这时候id=1的行a的值还是1，就会报唯一键冲突。

因此，基于行的策略，事务hash表中还需要考虑唯一键，即key应该是”库名+表名+索引a的名字+a的值”

因此，coordinator在解析这个语句的binlog的时候，这个事务的hash表就有三项
1 key=hash_func(db1+t26+primary+2),value=2，这里values=2是因为修改前后行的id值不变，出现了2次。

2 key=hash_func(db1_t26+”a” +2),value=1 表示会影响到这个表a=2的行

3 key=hash_func(db1_t26+”a” +1),value=1 表示会影响到这个表a=1的行

相比按表并行分发策略，按行并行的策略在决定线程分发的时候，需要消耗更多的计算资源，其中还有约束条件
1 binlog格式必须是row

2 表必须有主键

3 表不能有外键

对比按表和按库这两个方案，按行分发策略的并行度更高，不过，如果操作很多行的大事务的话，按行分发的策略有两个问题：

1 耗费内存，比如一个语句要删除100w行数据，这时候，hash表就要记住这100w个项

2 耗费cpu，解析binlog，然后计算hash值，对于大事务，这个成本比较高

所以，在实现这个策略的时候会设置一个阈值单个事务如果超过这个设置（比如单个事务更新的行数超过10w行），就暂时退化为单线程模式

1 coordinator暂时先hold这个事务

2 等待所有worker都执行完成，变成空队列

3 coordinator直接执行这个事务

4 恢复并行模式

Mysql5.6版本的并行复制策略

官方5.6版本，支持了并行复制，只是支持的粒度是按库并行，与上面按表分的类似，用于决定分发策略的hash表里，key就是数据库名

这个策略的并行效果，取决于压力模型，如果在主库上有多个db，并且各个db的压力均衡，使用这个策略的效果会好

如果在主库上把所有的表都放在一个库，那这个策略就没效果了

Mariadb的并行复制策略

前几篇中提到了redo log组提交（group commit）优化，mariadb的并行复制策略就是利用这个特性

1 能够在同一组事务的提交，一定不会修改同一行

2 主库上可以并行执行的事务，备库上也一定是可以并行执行的

在实现上，mariadb是这么做的：

1 在一组里面一起提交的事务，有一个相同的commit_id，下一组就是commit_id+1

2 commit_id直接写到binlog里面

3 传到备库应用的时候，相同commit_id的事务分发到多个worker执行

4 这一组全部执行完成后，coordinator再去取下一批

Mariadb的策略是，”模拟主库的并行模式”

但是，这个策略有一个问题，它并没有实现”真正的模拟主库并发度”，在主库上，一组事务在commit的时候，下一组事务是同时处于”执行中”状态的。

Mysql5.7的并行复制策略

官方的mysql5.7版本提供了类似mariadb的方案，由参数slave-parallel-type类控制并行复制策略

1 配置为DATABASE，表示使用5.6版本的按库并行策略

2 配置为LOGICAL_CLOCK，表示的类似mariadb的策略，不过，mysql5.7这个策略针对并行做了优化

考虑一个问题：同时处于”可执行状态”的所有事务，是不是可以并行？

答案是，不能。

因为，这里面可能有与锁冲突而处于锁等待状态的事务，如果这些事务在备库上被分发到不同的worker去上执行，会出现主备不一致的情况。

还记得前面介绍的两阶段提交

1 redo log prepare： write

2 binlog：write

3 redo log prepare ：fsync

4 binlog：fsync

5 redo log commit：write

其实不用等到commit阶段，只要能够达到redo log prepare阶段，就表示事务已经通过锁检测了。

因此mysql5.7的并行复制策略的思想是：

1 同时处于prepare状态的事务，在备库执行时是可以并行的

2 处于prepare状态的事务，与处于commit状态的事务之间，在备库执行时也是可以并行的

Binlog的组提交的两个参数

1 binlog_group_commit_sync_delay，表示延迟多少微秒后才调用fsync

2 binlog_group_commit_sync_no_delay_count参数，表示累积多少次以后才调用fsync

这两个参数是用于故意拉长binlog从write到fsync的时间，以此减少binlog的写盘次数，在mysql5.7的并行复制策略里，他们可以用来制造更多的”同时处于prepare阶段的事务”，这样就增加了并行度。

也就是说，这两个参数，既可以”故意”让主库提交得慢些，又可以让备库执行的快些，在mysql5.7处理备库延时的时候，可以考虑调整这2个参数，来达到提升备库复制并发度的目的。

Mysql5.7.22的并行复制策略

在2018.4发布的mysql 5.7.22版本里，mysql增加了一个新的并行复制策略，基于WRITESET的并行策略

相应地，增加参数binlog-transaction-dependency-tracking，用来控制是否启用这个新的策略

1 COMMIT_ORDER根据同时进入prepare和commit来判断是否可以并行的策略

2 WRITESET 表示的是对于事务涉及更新的每一行，计算出这一行的hash值，组成集合writeset，如果两个事务没有操作相同的行，也就说他们的writeset没有交集，就可以并行执行

3 WRITESET_SESSION，是在writeset的基础上多了一个约束，即在主库上同一个线程先后执行的两个事务，在备库执行的时候，要保证相同的先后顺序。

当然为了唯一标识，这个hash值通过”库名+表名+索引名+值”计算，如果一个表上除了pk外，还有其他唯一索引，那么对于每个唯一索引，insert语句对于的writeset就要多增加一个hash值

1 writeset是在主库生产后直接写入到binlog里面的，这样在备库执行的时候，不需要解析binlog内容（event里的行数据），节省了很多计算量

2 不需要把整个事务的binlog都扫一遍才能决定分发到那个worker，更省内存

3 由于备库的分发策略不依赖于binlog内容，所以binlog是statement格式也可以的

当然，对于”表没有主键”和”表有外键约束”的场景，writeset策略也是没有办法并行的，也会暂时退为单线程模型。

 

官方mysql5.7版本新增的备库并行策略，修改了binlog的内容，也就说binlog协议并不是向上兼容的，在主备切换，版本升级的时候需要把这个因素也考虑进去。