MySQLGTID的混合问题修复和思考

　　这是学习笔记的第2276篇文章
　　这几天做一个跨机房实时迁移的操作，碰到一个有些奇怪的问题，记录一下。
　　整体服务是在两个机房对等部署，然后通过级联复制的方式串起来。
　　实际切换前，节点B因为是从库，是很容易摘除的，所以整体的部署架构仅剩下A，C，D
　　同时在切换前，为了保证整个业务访问域名的可用性，会临时开启双主复制，这个阶段能够最大程度保证数据的完整性。当然这里会有两种模式，一种是最大保护模式，最大保护模式意味着数据只能从一个入口写入，如果双写很可能会数据冲突，第二种是最大可用模式，也就意味着整个过程数据在两边始终可以写入。这个模式的选用和具体的业务特点有关（读多写少，读多写多等）。
　　所以A和C之间的双主配置就显得尤其重要，也是整个平滑切换数据完整性的基础。
　　目前A，C，D节点的GTID基本信息如下：
　　A：showmasterstatus
　　ExecutedGtidSet：A：1222717169，B：1697
　　C：showslavestatus
　　ExecutedGtidSet：A：1222716771，B：1700
　　D：showslavestatus
　　ExecutedGtidSet：A：1222716771，B：1700
　　这个数据表达的含义比较深刻，那就是在数据链中，存在已被摘除的节点B的GTID信息，而从C，D的GTID相关信息可以看到，B中是丢失了一个数据事务的（当然这个过程不是真正的数据变化，和操作不规范有关）
　　所以在这种情况下如果要配置双主，需要解决的就是B相关GTID的差异，一种是直接抹去B的痕迹，这个过程需要在C，D上面可操作，但是实际复制双主的时候又会出问题。
　　如果把GTID当做一种数据血缘的角度会发现，整个GTID真是一个很有灵性的设计。假设红色是A的数据血缘，绿色是B的数据血缘。
　　舍弃了B之后，A，C开启了双主，整个数据血缘就是如下的状态了：
　　所以整个复制拓扑中的任何数据变化都能够有理有据的追溯，这是GTID设计很有价值的一件事情。
　　关于修复方式，也比较清晰，那就是把C和D的数据血缘B的部分做下回退，如下：
　　A：showmasterstatus
　　ExecutedGtidSet：A：1222717169，B：1697
　　C：showslavestatus
　　ExecutedGtidSet：A：1222716771，B：1697
　　D：showslavestatus
　　ExecutedGtidSet：A：1222716771，B：1697
　　按照这种模式来一次修改C和D，整个双向复制就能够很快构建起来了。
　　回置GTID的原理可以参考如下的图，通过gtidpurged可以间接实现裁剪。
　　C端修复的步骤如下：
　　1）stopslave；
　　2）showslavestatusG
　　3）resetmaster；
　　切记是在Slave端执行，这个阶段的目的就是要重新配置GTID的校准值。这个时候mysql。gtidexecuted应该就是空的了。
　　4）重置GTIDpurged值
　　SETGLOBAL。GTIDPURGEDA：1222716771，B：1697；
　　5）删除从库的复制配置
　　resetslaveall；
　　6）配置复制关系
　　CHANGEMASTERTOMASTERUSERdbarepl，MASTERPASSWORDxxxx，MASTERHOSTxxxxx，MASTERPORTxxxx，MASTERAUTOPOSITION1；
　　7）重启Slave节点，查看状态
　　startslave；
　　showslavestatusG
　　修复好之后，这部分打算是写一个巡检GTID和修复的脚本逻辑，能够把这部分的管理做得更细致一些。