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一致或相差较小的时再做主从切换。
---------------------
作者:jh993627471
来源:CSDN
原文:https://blog.csdn.net/jh993627471/article/details/79704939
版权声明:本文为博主原创文章,转载请附上博文链接!
【推荐】国内首个AI IDE,深度理解中文开发场景,立即下载体验Trae
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
· 阿里最新开源QwQ-32B,效果媲美deepseek-r1满血版,部署成本又又又降低了!
· 开源Multi-agent AI智能体框架aevatar.ai,欢迎大家贡献代码
· Manus重磅发布:全球首款通用AI代理技术深度解析与实战指南
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· AI技术革命,工作效率10个最佳AI工具
2015-05-22 SQL Server 复制(Replication) ——事务复制搭建