MySQL 并行回放在一路改进，从5.6的schema并行，到5.7的group commit， 再到8.0的write set

MTS based on schema

这种方式不用多说，涉及不同schema的DML操作，在slave端可以按schema粒度并行回放，弱点也很明显，如果实例中的schema较少，并行回放效果并不理想。

其优化方式也比较简单slave_parallel_workers 小于等于master的schema数量。

LOGICAL_CLOCK

MySQL 5.7 增加了基于group commit的并行回放策略，使得slave可以接近master同样并发回放事务，master并发越高，slave并行回放效果越明显。

在binlog中每个事务会有多出两个标签

sequence_number：随每个事务递增的自增ID，每次新的binlog会从1开始

last_committed：当前事务所依赖的上次事务的sequence_number，每次新的binlog会从0开始

last_committed相同值的事务代表同时提交的，可以并行回放。

#180105 20:08:33 ... last_committed=7201 sequence_number=7203

#180105 20:08:33 ... last_committed=7203 sequence_number=7204

#180105 20:08:33 ... last_committed=7203 sequence_number=7205

#180105 20:08:33 ... last_committed=7203 sequence_number=7206

#180105 20:08:33 ... last_committed=7205 sequence_number=7207

7203事务依赖7201

7204、7205、7206事务依赖7203，可以并行提交

7207事务依赖7205，由于7205依赖7203，那么在7205执行完后，7207可以和7206并行执行

优化方式通过调整master group commit size和slave的并行work线程数，提升并行效率。

master group commit size和并发压力，以及下面两个参数相关

binlog_group_commit_sync_delay 表示binlog提交事务前等待多少微秒

binlog_group_commit_sync_no_delay_count 表示同步队列最大允许的事务数，当等待提交的线程达到多少时, 就不在等待

在master低并发的负载下，并行回放效果就不好了，如果想要提高并行度，需要增加binlog_group_commit_sync_delay，积累较多的分组大小，副作用是拉低master吞吐量。

Write set

MySQL 8.0.1 & 5.7.22 在group commit基础上进一步改善了并行复制效率，增加了新的跟踪事务依赖关系的机制。相对于基于事务commit timestamp，即使master低并发场景下也能使slave根据事务依赖关系并行重放，充分利用硬件资源，不需要像MySQL 5.7增加binlog_group_commit_sync_delay延迟的方式，增加可并行的事务，降低复制延迟。

在master上满足以下条件binlog_format=row

开启transaction_write_set_extraction=XXHASH64

更新表必须有主键，如果更新事务包含外键，则退回commit_order方式

binlog_transaction_dependency_tracking = [COMMIT_ORDER | WRITESET | WRITESET_SESSION]

slave上开启slave_parallel_workers

COMMIT_ORDER 基于commit timestamp

不同会话在相同时间执行可以并行回放

WRITESET 变更不同行的操作都可以并行无主键 退回commit_order模式

hongbin@MBP ~/w/s/msb_8_0_3> mysqlbinlog data/MBP-bin.000013 |grep last_ |sed -e 's/server id.*last/[...] last/' -e 's/.rbr_only.*/ [...]/'

#180105 21:19:31 [...] last_committed=0 sequence_number=1 [...] create table t1 (id);

#180105 21:19:50 [...] last_committed=1 sequence_number=2 [...] insert t1 value(1);

#180105 21:19:52 [...] last_committed=2 sequence_number=3 [...] insert t1 value(2);

#180105 21:19:54 [...] last_committed=3 sequence_number=4 [...] insert t1 value(3);

有主键 单个会话也可以并行

#180105 21:23:58 [...] last_committed=4 sequence_number=5 [...] create table t2 (id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY, str VARCHAR(80) NOT NULL UNIQUE);

#180105 21:24:19 [...] last_committed=5 sequence_number=6 [...] session1: insert t2(str) value('a');

#180105 21:24:21 [...] last_committed=5 sequence_number=7 [...] session1: insert t2(str) value('b');

#180105 21:24:25 [...] last_committed=5 sequence_number=8 [...] session1: insert t2(str) value('c');

WRITESET_SESSION 相同会话不会被重新排序,不同会话可并行

在相同会话中执行

#180106 13:15:26 [...] last_committed=0 sequence_number=1 [...] session1：insert t2(str) value('h');

#180106 13:15:31 [...] last_committed=1 sequence_number=2 [...] session1：insert t2(str) value('l');

在不同会话中执行

#180106 13:17:08 [...] last_committed=1 sequence_number=3 [...] session1: insert t2(str) value('q');

#180106 13:17:09 [...] last_committed=1 sequence_number=4 [...] session2: insert t2(str) value('w');

如何观测并行回放

如何评估slave_parallel_workers设置多少合适？如果设置小了，任务会有积压，如果设置大了，多余的线程是空闲的。

计算机领域有这么个公式专门来研究系统资源分配公平性。

出自论文《A Quantitative Measure Of Fairness And Discrimination For Resource Allocation In Shared Computer Systems》引用数4000+

这个公式称为 jain's index 计算一系统共享资源分配公平性的指数，指数值在0

借用此公式是不是可以来计算回放线程任务分配的公平性，如果slave_parallel_workers设置过大，反应任务分配公平性较差。找到合适的slave_parallel_workers

这里需要启用performance_schema的transaction级的instrument，搜集线程事务提交信息。call sys.ps_setup_enable_consumer('events_transactions%');

call sys.ps_setup_enable_instrument('transaction');

将公式转换为SQL语句如下select ROUND(POWER(SUM(trx_summary.COUNT_STAR), 2)

(@@GLOBAL.slave_parallel_workers * SUM(POWER(trx_summary.COUNT_STAR, 2))), 2) AS replica_jain_index

from performance_schema.events_transactions_summary_by_thread_by_event_name as trx_summary join performance_schema.replication_applier_status_by_worker as applier

on trx_summary.THREAD_ID = applier.THREAD_ID

在slave上观测，如果该指数值越接近0说明当前applier线程越空闲率高，如果该指数值越接近1说明当前applier线程空闲率越低。动手试试吧！

参考

https://www.percona.com/blog/2016/02/10/estimating-potential-for-mysql-5-7-parallel-replication/

https://www.slideshare.net/JeanFranoisGagn/fosdem-2018-premysql-day-mysql-parallel-replication

https://jfg-mysql.blogspot.hk/2017/02/metric-for-tuning-parallel-replication-mysql-5-7.html

https://jfg-mysql.blogspot.com/2018/01/write-set-in-mysql-5-7-group-replication.html?m=1

http://mysqlhighavailability.com/improving-the-parallel-applier-with-writeset-based-dependency-tracking/