MySQL 5.6 GTID复制 乱序复制

最近一直在弄基于MySQL5.6 GTID 复制功能的DBScale高可靠测试。

测试过程中发现GTID功能在某些情况下不能保证所有的事件在slave上按照与master一样的执行顺序执行。

GTID复制中的事件有一个UUID和一个递增数字编号进行唯一标识。MySQL5.6可以保证同一个UUID下的事件会按照数字编号的顺序在slave上执行。但似乎不能保证不同UUID下的事件的顺序关系。

测试环境中我搭建了一个2级复制：
global_master->global_slave->global_master
global_master->par_master->par_slave
测试中有2张表global_table, par_table. 通过DBScale,global_table被部署在global_master中， par_table被部署在 par_master中。

在测试高可用切换过程中出现过一次par_slave上的变更在1小时之后才同步到par_master的情况，由于这些变更和其他事件的执行顺序已经改变，导致par_master和par_slave数据严重不一致。
（延迟1小时是通过分析主从两个mysql的binlog文件发现的。slave上有开启log-slave-updates。）

这种延迟复制不是必然出现，我在测试过程中有多次启停mysql，而且有过多次表truncate（par_master和par_slave上都有执行）。

先博客记录下，后面再具体分析下，看看什么情况会触发这种情况。出现过就肯定是有问题的，如何在客户现场避免这种情况才是关键。

转载请注明转自高孝鑫的博客