MySQL 5.7 mysqldump的Bug导致复制异常
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了MySQL 5.7 mysqldump的Bug导致复制异常相关的知识,希望对你有一定的参考价值。
DB版本:5.7.17
问题描述:mysqldump逻辑搭备库都相信大家都使用的非常普遍,大致做法如下:
1、在源库上mysqldump --single-transaction --master-data=2 -A ... >XXX.sql
2、在目标备库上stop slave;reset master; reset slave all; source XXX.sql
3、如果导入了用户信息需要flush privileges生效
4、change master to .. master_auto_position=1;
5、start slave完事
查看复制状态一切正常...
看起来很规范,整个过程很顺畅,没毛病!
问题来了:mysql或者主机需要维护重启。正常停止完了启动mysql,start slave发现复制出错了!!!why?
https://bugs.mysql.com/bug.php?id=82848 BUG在此
说是mysql的bug其实如果了解mysql 5.7针对GTID复制的优化以后,是可以避免这个坑的:
1、5.7不需要备库开启log-slave-updates选项,也就无需读写binglog来计算复现的事务信息了
2、作为改进,mysql库新增了一张表gtid_executed表用来记录执行过的事务信息
3、该表并不是实时更新的,只有binlog switch或者mysql shutdown的时候更新
基于这3点:由于mysqldump全库导入了,mysql.gtid_executed也导入到mysql库了.由于该表没有及时更新(由于gtid不同,在新库已经无法正常更新).这样重启后读取mysql.gtid_executed作为gtid_executed的信息,并以此状态向主库复制。就会拿到已经执行或的binlog继续应用,重复执行导致复制报错。
how to do:
mysqldump时增加--ignore-table =mysql.gtid_executed或者增加-F 参数触发mysql.gtid_executed数据更新
以上是关于MySQL 5.7 mysqldump的Bug导致复制异常的主要内容,如果未能解决你的问题,请参考以下文章
通过 mysqldump 完全恢复 MySQL 5.7 数据库
通过 mysqldump 搭建基于 gtid MySQL 5.7 主从复制
使用 mysqldump 实现 MySQL 5.7 基于时间点的恢复