
上QQ阅读APP看本书,新人免费读10天
设备和账号都新为新人
1.4.4 主从切换
切换必须保证主从没有延迟,可以通过对照主从库的gtid_executed变量进行确认。同时,切换时必须要确认原从库(新主库)没有做过本地GTID操作。如果原从库(新主库)做过本地GTID操作,那么切换后新从库(原主库)需要拉取这一部分的GTID Event,如果部分Event已经不存在了,那么会报错,即著名的1236错误。具体的判断过程我们将在3.5节和3.6节进行介绍。
正常的切换步骤如下。
(1)原从库(新主库)执行如下操作。

(2)原主库(新从库)执行如下操作。

实际就是这么简单,新主库(原从库)会生成自己的GTID事务,新从库(原主库)接受后执行即可。切换后主库的gtid_executed变量会出现两个server_uuid,如下。

总的说来,切换的从库不能在从库本地做任何生成GTID的操作。如果确实要做,比如加索引等不影响数据一致性的操作,则可以使用如下方法。

这样也不会增加从库本地的GTID。