GTID复制踩到的坑

问题背景:
在搭建完成GTID复制环境以后, 从库show slave status\G输出可以看到Slave_IO_Running和Slave_SQL_Running状态是YES

主库show master status输出

从库show master status输出

看起来主从结构并没有什么问题,但当把从库关闭再重启启动的时候,show master status输出却变成:

1937661e-4a69-11e7-a82d-00155d016710:1-6不见了?事实上, 这些GTID事务是主库mysqldump全备文件中的,也就是说, 主库mysqldump出1-6的事务导入从库做的GTID复制,把主从关系建立起来,复制也没问题,而从库mysqld实例重启以后,这些全备的事务丢失了?如果这样就执行start slave肯定出问题!!!

经过分析,这个问题与mysql.gtid_executed有关!

在主库执行select * from mysql.gtid_executed; 返回空, 而从库

解决办法就是把interval_start的最小的值由7改为1
set sql_log_bin=0;
update mysql.gtid_executed set interval_start=1 where source_uuid='1937661e-4a69-11e7-a82d-00155d016710' and interval_start=7;
set sql_log_bin=1;
重启mysqld,可以看到show master status输出正常,执行start slave;主从关系恢复正常;

那怎么避免这个问题的发生呢?在主库备份之前,确认purged掉的gtid已经写入mysql.gtid_executed中,有时可能没有及时写入这个表,可以kill -HUP $(pgrep msyqld)触发写这个表,有时可能执行一次kill不行的,可以执行多几次。

最后一定要注意, 遇到这种情况,可以忽略GTID事务的,可以通过跳过GTID事务的方式修复解决;而如果通过reset master和gtid_purged方式, 存在比较大的风险;最好还是避免这类问题的发生;

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇