MySQL备库的并行复制策略

任卓

在上一篇文章中，我们介绍了MySQL高可用的基础---主备切换，并介绍了影响主备切换策略的参数---主备延迟。这篇文章我们就来说说如何能够降低主备延迟。

前期文章回顾

• MySQL的主备一致性
  
• MySQL的高可用保证
  

备库并行复制

在介绍备库并行复制能力之前，我们先来看下之前介绍的主备切换流程图：


图中①的部分代表了客户端发起的SQL请求，支持多客户端的并发访问。但是对于备库的红色箭头来说，由于是单线程复制，就会导致由于复制的速度不够快而出现的主备延迟。
在MySQL5.6版本之前，只支持单线程复制，当主库的并发高、TPS高时就会导致严重的主备延迟。
所以基于此，就出现了多线程的复制模型，架构图如下：


事务分发给worker线程需要遵循两个原则：
（1）同一个事务必须在一个worker中运行
（2）更新同一个行的两个事务必须在一个worker中运行
下面我们介绍的各种多线程复制策略都遵循了这两个原则。
数据库分发

在官方MySQL5.6版本中，支持按照数据库名并行复制，即两个事务如果更新的数据库不同，就分发给不同的worker执行。如下图：


从图中可以看出，每个worker线程中有一个hash表，key为数据库名，value为修改数据库的事务。当有事务分配给worker时，会将事务修改的表增加到对应的hash表中，当worker执行完后，这个表也会从hash表中删去。
假如当前存在事务T，修改的数据库为db1和db4，则分配流程如下：

• 判断事务T和每个worker线程的冲突关系，如果多余一个，则暂时不分配，coordinator进入等待状态
  当事务T修改的数据库在worker的hash表中存在，则认为事务T和worker冲突
  
• worker继续执行，当worker队列中只有一个与事务T冲突，此时将事务T分配给该worker
  
• 如果事务T与worker队列无冲突，则随机分配给某个worker即可。
  

当主库上有多个DB，并且每个DB的压力均匀，该种策略的效果比较好。
事务状态分发

MariaDB的并行复制策略利用了redo log的组提交优化的特性：

• 能够在同一个组提交的事务，可以并发执行
  
• 主库上并发执行的事务，在备库上也可以并发执行
  

所以，MariaDB将组提交的事务的commit_id直接写入binlog文件中，coordinator线程每次取一个commit_id下的所有事务，然后分发给不同的worker，执行完后再去下一个commit_id。
MySQL5.7版本的并行复制策略和上述MariaDB的策略非常像，只要同时处于prepare状态的事务在备库就是可以同时执行的。
MySQL5.7版本中slave-parallel-type参数可以控制并行复制策略的选择：

• DATABASE：表示按照数据库分发
  
• LOGICAL_CLOCK：表示同时处于prepare状态的事务可以同时执行
  

按行分发

MySQL5.7.22版本中增加了一个新的并行复制策略，通过binlog-transaction-dependency-tracking来控制：

• COMMIT_ORDER：表示前面介绍的策略，按照同时处于prepare来判断是否并行的策略
  
• WRITESET：事务更新的每一行，计算其hash，组成writeset集合，如果两个事务的writeset集合没有交集，则可以并行
  
• WRITESET_SESSION：在主库同一线程先后执行的两个事务，在备库执行的时候，要保证相同的先后顺序
  

总结

• 按照数据库分发的策略在DB比较多、压力均匀的前提下，效果很好，但是如果只有一个DB，或者不同DB的热点不同，那么也无法起到并行的效果
  
• 按照事务的状态来分发，很容易被大事务拖后腿，比如同一组里面有一个大事务，当其他事务已经执行完成后，需要等到该事务完成，coordinator才会去取下一批commit_id。
  
• 按行分发会在主库执行的时候将writeset写入binlog，所以不要求binlong必须是row格式。
  

参考

MySQL实战45讲-----第26讲 备库为什么会延迟好几个小时？

白沙洲

路过