这几天一直在做跨机房的实时迁移操作，遇到一个有点奇怪的问题，记录一下。整体服务点对点部署在两个机房，再通过级联复制连接起来。在实际切换前，节点B因为是从库，很容易被移除，所以整体的部署架构只有A、C、D。同时在切换前，为了保证整个的可用性业务访问域名，会暂时开启双主复制，这个阶段可以最大程度保证数据的完整性。当然，这里有两种模式。一种是最大保护模式。最大保护模式意味着数据只能从一个条目写入。如果双写容易造成数据冲突，其次是最大可用模式，即整个进程数据始终两边可写。这种模式的选择与具体的业务特性有关（读多写少，读多写多等）。所以A和C之间的双主配置就显得尤为重要，也是整个平滑切换的数据完整性的基础。目前A、C、D节点的GTID基本信息如下：A:showmasterstatusExecuted_Gtid_Set:A:1-222717169,B:1-697C:showslavestatusExecuted_Gtid_Set:A:1-222716771,B:1-700D:showslavestatusExecuted_Gtid_Set:A:1-222716771,B:1-700这个数据表达了更深层次的意思，就是在数据链中，有被移除的节点B的GTID信息，从GTID中C和D的信息，可以看出，B丢失了一个数据事务（当然这个过程不是真正的数据变化，和不规范的操作有关）。所以这种情况下，如果要配置双主，需要解决B相关的GTID的不同，就是直接抹掉B的痕迹，这个过程需要在C和D上都可以操作，但是会有实际复制双主控时会出现问题。如果你把GTID当成一种数据血统，你会发现整个GTID真的是一个很有灵性的设计。假设红色是A的数据沿袭，绿色是B的数据沿袭。放弃B后，A和C启用双主，整个数据沿袭处于如下状态：所以整个复制拓扑中的任何数据变化都可以以合理的证据进行追溯，这在GTID设计中是一件很有价值的事情。至于修复方法，比较清楚，就是把C和D的数据的血统B部分“回滚”，如下：A:showmasterstatusExecuted_Gtid_Set:A:1-222717169,B:1-697C:showslavestatusExecuted_Gtid_Set:A:1-222716771,B:1-697D:showslavestatusExecuted_Gtid_Set:A:1-222716771,B:1-697按照这个模式，修改一次C和D，整两个可以快速建立单向复制。重置GTID的原理可以参考下图，可以通过gtid_purged间接实现剪枝。C端修复步骤如下：1）停止slave；2)显示从站状态\G3)重置主站；记得在slave端执行，这个阶段的目的是重新配置GTID的校准值。这时候mysql.gtid_executed应该是空的。4)重置GTID_purged值SET@@GLOBAL.GTID_PURGED='A:1-222716771,B:1-697';5）从库中删除复制配置resetslaveall；6)配置复制关系CHANGEMASTERTOMASTER_USER='dba_repl',MASTER_PASSWORD='xxxx',MASTER_HOST='xxxxx',MASTER_PORT=xxxx,MASTER_AUTO_POSITION=1;7)重启Slave节点，查看启动slave的状态；showslavestatus\G修复后，这部分的目的是写一个GTID检查和修复的脚本逻辑，可以让这部分的管理更加细化。本文转载自微信公众号《杨建荣的学习笔记》，可通过以下二维码关注。转载本文请联系杨建荣学习笔记公众号。
