- 深入理解MySQL主从原理
- 高鹏
- 373字
- 2021-04-16 16:29:25
1.4.11 离线开启GTID丢失数据的测试
这个测试很简单,实际上在线开启GTID丢失数据也是一样的道理,但是在线开启GTID丢失数据的情况不太好模拟,因此我们以离线开启GTID为例。
首先,我们需要在POSITION MODE的主库中执行如下大事务。
![](https://epubservercos.yuewen.com/A01218/19823444008569806/epubprivate/OEBPS/Images/txt001_58.jpg?sign=1739582023-kWIahsfWeotuGbowya2JQJCXhuOu9j20-0-08a316ab9017e1d88e86fe9b94c9c760)
从库中的结果如图1-3所示。
![](https://epubservercos.yuewen.com/A01218/19823444008569806/epubprivate/OEBPS/Images/txt001_59.jpg?sign=1739582023-9KSlUEwVHsGEVXdbZPcnUZvb4a5GuaDF-0-000441672e11a837aecd19cba8336a68)
图1-3
这个时候,我们执行“stop slave”命令关闭主库和从库实例,然后修改GTID相关参数开启GTID。实际上正常关闭从库将会进行大事务的回滚,这将会在4.7节介绍。
接着启动主库和从库实例,注意从库需要设置 skip-slave-start 不随实例启动,然后设置MASTER_AUTO_POSTION=1,如下。
![](https://epubservercos.yuewen.com/A01218/19823444008569806/epubprivate/OEBPS/Images/txt001_60.jpg?sign=1739582023-c49ITbPzs6L3EpYKutRJXsg4Nfnre13q-0-2b2064c48452fc83e13b6656d0cbcef6)
启动后发现testgpan表中的数据并没有被删除,但是主从状态是正常的,如图1-4所示。
![](https://epubservercos.yuewen.com/A01218/19823444008569806/epubprivate/OEBPS/Images/txt001_61.jpg?sign=1739582023-Efm6aNa8fV6KvaTUccsX0f2MernInv3o-0-a77fecf1abf4535d0b809395f1606830)
图1-4
也就是说,数据已经不一致了,造成这种问题的原因有如下两个。
(1)设置MASTER_AUTO_POSITION = 1会清理原来的所有relay log,因此relay log中已经没有这个匿名事务的Event了。
(2)设置MASTER_AUTO_POSITION = 1,DUMP线程会使用从库的Executed_Gtid_Set和Retrieved_Gtid_Set的并集定位binary log,因此匿名事务的Event也不会发送了。这将在3.5节和4.4节介绍。