MySQL 5.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值是通过“库名+表名+索引名+值”计算出来的。如果一个表上除了有主键索引外，还有其余惟一索引，那么对于每个惟一索引，insert语句对应的writeset就要多减少一个hash值。

你可能看进去了，这跟咱们后面介绍的基于MySQL 5.5版本的按行散发的策略是差不多的。不过，MySQL官网的这个实现还是有很大的劣势：

1. writeset是在主库生成后间接写入到binlog外面的，这样在备库执行的时候，不须要解析binlog内容（event里的行数据），节俭了很多计算量；
2. 不须要把整个事务的binlog都扫一遍能力决定散发到哪个worker，更省内存；
3. 因为备库的散发策略不依赖于binlog内容，所以binlog是statement格局也是能够的。

因而，MySQL 5.7.22的并行复制策略在通用性上还是有保障的。

当然，对于“表上没主键”和“外键束缚”的场景，WRITESET策略也是没法并行的，也会临时进化为单线程模型。