MySQL GTID的混合问题修复和思考

微信扫一扫,分享到朋友圈

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的混合问题修复和思考

为什么不用Rust?

上一篇

[图]所有251款Xbox Game Pass游戏容量有多大?12TB硬盘还剩7.5TB

下一篇

你也可能喜欢

MySQL GTID的混合问题修复和思考

长按储存图像,分享给朋友