mysql5.7切换导致gtid不一致

今天在公司的工程环境中做了个案例，手动切换关闭主库的mysql服务，从库上升为主库之后，发现主库处于read_only状态，通过高可用的组件观察了剩余主从库的alive以及delay的状态发现均正常。由于处于公司的内网环境中，所以就没有保存图片，就通过文字的方式记录下今天这个案例。

环境：mysql5.7.18 一主两从 做了高可用

操作步骤：通过高可用组件发现三台mysql的主从关系，alive，delay均为正常状态，登录主库所在的主机进行关闭数据库服务，正常情况下，关闭主库之后，一个从库上升为新主，另一台同时为主库形成一主一从的架构。但是，实际结果为一个从库上升为主库，但是处于read_only状态；另一台从库还是和旧主同步，因为旧主已经关闭，所以存在主从同步异常。

处理过程：通过分析，新主置于read_only状态的原因为：主从切换之后，从库上升为新主，但是存在主从同步异常，此时只有一个主库的架构，所以新主为read_only状。此时的处理方法为将旧主服务启动，这样就能形成主从关系，新主就不会为read_only状态。启动完旧主之后(它与新主之后有个gtid比对的过程，多与新主则flashback闪回)，与新主形成主库关系，发现另一个从库与新主没有形成主从关系，通过查看从库show slave status记下gtid和查看主库show master status的gtid，发现两个数据库之间的gtid的不一致。所以就通过reset slave all从库然后再将set_purge置于主库的gtid，然后start slave。发现主从关系正常。最后通过自己手动切换主从关系，查看是否还存在主从关系异常的状况，发现无异常。

总结：以后在做手动切换主从之类的操作，应该谨慎比对主从之间的gtid的值，发现不一致时应该不操作，需等到gtid一致或相差较小的时再做主从切换。

译者介绍：家华，从事mysqlDBA的工作，记录自己对mysql的一些总结