概念

我们先介绍两个系统变量

binlog_order_commits

MySQL 5.6.6引入，默认开启
事务按照在binlog中写入的顺序进行commit

slave_preserve_commit_order

MySQL 5.7.5引入，默认关闭
在并行复制场景下，事务在Slave上commit与在Msater上的commit的顺序保持一致
接下来分析什么场景可能出现乱序的GTID

并行复制

在并行复制场景下，5.7.7之前因为没有slave_preserve_commit_order，并不保证事务在Slave上commit与在Msater上的commit的顺序一致

  • 如果Master是事务顺序提交，GTID严格递增

  • 在Slave上，可能由于并行复制导致事务的提交顺序与Master上并不一致，那么Slave的GTID就产生了“局部乱序”

    人为修改GTID_NEXT

  • 如果当前gtid_executed为server_uuid:1-10

  • 设置gtid_next = server_uuid:15
  • 执行事务A，A的GTID为server_uuid:15
  • 设置gtid_next = AUTOMATIC
  • 执行事务B，B的GTID为server_uuid:11

那么A，B的GTID就是“局部乱序”的，binlog中的记录类似这样：