现象描述

Slave在开启并行复制后, 默认会乱序提交事务, 可能会引起同步中断;

Slave端表现为同步的SQL线程抛出异常, 为主键重复, 修改的数据行不存在等;

GTID信息类似于: 9a2a50aa-5504-11e7-9e59-246e965d93f4:1-1371939844:1371939846

其中1371939845为报错的事务, 直观上看, Slave端先提交了1371939846事务;

解决办法

MySQLversion>=5.7.5

slave_preserve_commit_order:OFF(default)->ON

注:binlog_order_commits=ON(default)

问题分析

参考官方的WL#6314和WL#7165, 这里对原文内容进行简单的归纳, 有兴趣的可以看看原文的High Level Architecture;

WL#6314 : https://dev.mysql.com/worklog/task/?id=6314

WL#7165 : https://dev.mysql.com/worklog/task/?id=7165

注: 英文原文中的commit-parent transaction, sequence number指的就是binlog中的last_commited和sequence_number; 即简单翻译中的”逻辑时间戳标记”

WL#6314 关于slave端的并行applier

当事务进入prepare阶段(组提交流程的某一个阶段)时, 这些事务都会获得一个逻辑时间戳的标记, 用来标记最新提交的事务是哪个;

在master端, 有关流程如下:

在prepare阶段, 从commit_clock中获取时间戳并存储下来, 用来标记最新提交的事务;

在commit阶段(事务已经写入binlog, 但是在引擎层提交前), 对commit_clock执行步进操作;

在Slave端, 有关流程如下:

coordinate线程会读取relaylog的event, 如果这些event都有相同的逻辑时间戳(last_commited), 那么这些event就可以由worker并行执行;

WL#7165 有关并行复制的并行度优化

参照WL#6314的描述, 虽然已经实现了并行复制, 但是并没有达到预期的程度;

举例: 下图代表各个事务的执行顺序与时间线, 其中P代表单个事务的prepare阶段, 在这个阶段会获取到commit_clock的时间戳, C代表这个事务的写binlog的阶段, 在这里会对commit_clock进行步进操作;

如上图所示, Trx1, Trx2, Trx3的P阶段获取到的都是同一个last_commited值(比如说是1), 因此这三个事务可以在Slave端并行执行; 同理, Trx4不能和< Trx1, Trx2, Trx3 > 一起并行回放, 因为Trx4的P阶段, 获取到的last_commited值是Trx1执行完步进以后的值(步进之后变成了2);

按照WL#6314的逻辑, Slave端可以发现这七个事务分成了四个事务组, 分别是< Trx1, Trx2, Trx3 >, < Trx4 >, < Trx5, Trx6 >, < Trx7 >;

但是需要注意的是, 对于不同的事务组, < Trx4 > 和 < Trx5, Trx6 > 是能并发执行的, 因为从时间线上看, < Trx4 > 和 < Trx5, Trx6 > 的prepare阶段在时间线上是有重叠的, 这也就意味着这两组事务并不存在锁的冲突, 那么就可以在Slave并行执行;

对于并行度的优化

改进后的并行复制使用锁来判断是否可以进行并发;

基本逻辑如下:

L代表锁阶段开始, C代表锁阶段结束;

A中的Trx1和Trx2由于锁阶段存在重合, 也没有发生冲突, 说明Trx1和Trx2是可以并行执行的, 但是B不行, 因为Trx1和Trx2的锁阶段没有重合, 所以无法确认是不是可以并行执行(不做额外的判断, 直接当做不可并行处理, 节约性能开销);

关于锁阶段的判断, WL中明确表示没有进行锁分析, 而是直接把事务提交的一些阶段作为加锁与释放锁的时间点(从事务提交的阶段来看, 也没什么问题);

假设在进行存储引擎层的提交之前, 所有的锁都已已经释放(锁阶段结束的时间点);

假设在prepare阶段开始的时候, 所有需要的锁已经全部获取到(锁阶段开始的时间点);

在MySQL的binlog中, L所指的标记就是last_commited, C所指的标记就是sequence_number;

关于last_commited和sequence_number, WL#7165有做如下描述

在事务进入flush阶段前, 会步进transaction.sequence_number的值 –> 显示为sequence_number

在事务进入引擎层提交之前, 会修改 global.max_committed_transaction的值

= max(global.max_committed_timestamp, transaction.sequence_number)

= transaction.sequence_number (如果binlog_order_commits使用默认值ON)

因此, Slave端在决定SQL是否可以并发执行时, 参考如下原则:

-----------------------------------------------------------------------------------------------------------

Slave can execute a transactionifthe smallest sequence_number

among all executing transactions is greater than transaction.last_committed.

-----------------------------------------------------------------------------------------------------------

伪代码会更直观一些:

-----------------------------------------------------------------------------------------------------------

Slave logic:

-before scheduler pushes the transaction for execution : wait until         transaction_sequence[0].sequence_number>transaction.last_committed

-----------------------------------------------------------------------------------------------------------

所以使用基于锁的并行度优化后, 确实可以让WL#6314的< Trx4 > 和 < Trx5, Trx6 > 并发执行;

故障场景还原

Slave上报错的事务为1371939845, binlog内容如下, 事务缺少1371939845;

Master上的事务序列如下:

参考WL#6314的格式, 根据Master的事务序列绘制事务序列图, GTID, last_commited, sequence_number均使用最后两位数作为标记;

由于Slave是乱序提交的, 所以这些事务在Slave的binlog中并非严格按照GTID递增的顺序出现

根据WL#7165的描述, 可以得出: 在Slave上, 当Trx41执行完毕之后, Slave认为, Trx46与Trx47已经可以由coordinate进行调度, 与< Trx42, Trx43, Trx44, Trx45 > 并行执行了, 但是Trx45与Trx46, Trx47 存在业务上的先后顺序(且确实存在锁冲突), 所以先执行的Trx46删除了Trx45需要的数据, 导致同步中断;

PS: 既然Trx45和Trx46有锁冲突, 为什么Trx46会拿到84作为last_commited, 而不是88?

参考WL#7165的伪代码,

-----------------------------------------------------------------------------------------------------------

When@@global.binlog_order_commitsistrue,inprinciple we could reduce the max

to an assignment:

global.max_committed_transaction=transaction.sequence_number

-----------------------------------------------------------------------------------------------------------

MySQL-5.7.21的源代码:

MYSQL_BIN_LOG::ordered_commit-->

process_commit_stage_queue-->

update_max_committed

-----------------------------------------------------------------------------------------------------------因此推测主库当时候是如下场景:作为一个事务组,进入到了存储引擎的commit阶段前,会递增sequence_number,而不是一次到位的全部加上;

所以Trx46进入prepare阶段时,刚好是Trx41完成了commit阶段,所以拿到的是84,而不是88;虽然官方描述中,认为会达到最终一致的状态,但是同步过程中会存在短暂的不一致现象,这种现象被描述为"GAP";