关于MySQL GTID的一次深刻学习( 五 )_最近因为一个特别的操作需求

42结尾的Slave端是做过一次故障切换的，切换后的状态应该是

1-5046391左右，而在Slave变为主库后写入了数据，状态应该是

1-5046473 ，总之在那之后基于这个GTID再无数据写入，具体在那个时间段里发生了什么已经无法知晓，但是一个值得考虑的点就是基于MHA的健康监测是使用了ping insert的方式，在没有业务数据干扰的情况下，很可能是这个潜在的原因写入了数据，但是至于为什么没有把这些变更都同步过去，这是一个问题。当然对我们解决这个问题不是最重要的。

我们可能需要理解一下这个问题的根本原因，其实不在于是不是存在两个GTID而是根本在于Slave端的GTID(不变化的GTID)在两端不一致。

可以举个例子，比如夫妻两个人（类似于MasterSlave两个节点，为了便于理解，我就以媳妇（Master）丈夫（Slave）来简称了），先是媳妇管账， GTID以媳妇(Master)的变化为准，然后过了一段时间发生了转换，该丈夫管账，数据变化以Slave为主，结果管得不好，很快又换过来了，于是又以媳妇的（Master）为准。