如何修复MySQL GTID的混合问题

共计 1727 个字符，预计需要花费 5 分钟才能阅读完成。

这篇文章主要讲解了“如何修复 MySQL GTID 的混合问题”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“如何修复 MySQL GTID 的混合问题”吧！

整体服务是在两个机房对等部署，然后通过级联复制的方式串起来。

实际切换前，节点 B 因为是从库，是很容易摘除的，所以整体的部署架构仅剩下 A,C,D

同时在切换前，为了保证整个业务访问域名的可用性，会临时开启双主复制，这个阶段能够最大程度保证数据的完整性。当然这里会有两种模式，一种是最大保护模式，最大保护模式意味着数据只能从一个入口写入，如果双写很可能会数据冲突，第二种是最大可用模式，也就意味着整个过程数据在两边始终可以写入。这个模式的选用和具体的业务特点有关 (读多写少，读多写多等)。

所以 A 和 C 之间的双主配置就显得尤其重要，也是整个平滑切换数据完整性的基础。

目前 A,C,D 节点的 GTID 基本信息如下：

A: show master status

Executed_Gtid_Set: A:1-222717169,B:1-697

C：show slave status

Executed_Gtid_Set: A:1-222716771,B:1-700

D：show slave status

Executed_Gtid_Set: A:1-222716771,B:1-700

这个数据表达的含义比较深刻，那就是在数据链中，存在已被摘除的节点 B 的 GTID 信息，而从 C,D 的 GTID 相关信息可以看到，B 中是丢失了一个数据事务的 (当然这个过程不是真正的数据变化，和操作不规范有关)

所以在这种情况下如果要配置双主，需要解决的就是 B 相关 GTID 的差异，一种是直接抹去 B 的痕迹，这个过程需要在 C,D 上面可操作，但是实际复制双主的时候又会出问题。

如果把 GTID 当做一种数据血缘的角度会发现，整个 GTID 真是一个很有灵性的设计。假设红色是 A 的数据血缘，绿色是 B 的数据血缘。

舍弃了 B 之后，A,C 开启了双主，整个数据血缘就是如下的状态了：

所以整个复制拓扑中的任何数据变化都能够有理有据的追溯，这是 GTID 设计很有价值的一件事情。

关于修复方式，也比较清晰，那就是把 C 和 D 的数据血缘 B 的部分做下“回退”，如下：

A: show master status

Executed_Gtid_Set: A:1-222717169,B:1-697

C：show slave status

Executed_Gtid_Set: A:1-222716771,B:1-697

D：show slave status

Executed_Gtid_Set: A:1-222716771,B:1-697

按照这种模式来一次修改 C 和 D，整个双向复制就能够很快构建起来了。

回置 GTID 的原理可以参考如下的图，通过 gtid_purged 可以间接实现裁剪。

C 端修复的步骤如下：

1)stop slave;

2)show slave status\G

3)reset master;

切记是在 Slave 端执行，这个阶段的目的就是要重新配置 GTID 的校准值。这个时候 mysql.gtid_executed 应该就是空的了。

4) 重置 GTID_purged 值

SET @@GLOBAL.GTID_PURGED= A:1-222716771,B:1-697

5) 删除从库的复制配置

reset slave all;

6) 配置复制关系

CHANGE MASTER TO MASTER_USER= dba_repl , MASTER_PASSWORD= xxxx ,  MASTER_HOST= xxxxx ,MASTER_PORT=xxxx,MASTER_AUTO_POSITION = 1;

7) 重启 Slave 节点，查看状态

start slave; show slave status\G

修复好之后，这部分打算是写一个巡检 GTID 和修复的脚本逻辑，能够把这部分的管理做得更细致一些。

感谢各位的阅读，以上就是“如何修复 MySQL GTID 的混合问题”的内容了，经过本文的学习后，相信大家对如何修复 MySQL GTID 的混合问题这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！