【1】现有情况
主从同步搭建好了,show slave status 一直报错 说某个表的某行记录找不到!
有很多情况
(1)主库有,从库没有,这次我遇到的就是这个问题
由于 myisam 备份时没有加 lock-tables(只管MYISAM),导致不一致问题出现;
就是dump按道理是一个整体时间点;但由于 MYISAM 即没有事务,也没有快照,所以只有轮到它的时候才是实际取数据的时候;
这就意味着,记录的 binlog 位置与 gtid 执行位置是 10点钟的,但某些表真正 dump 时是 11点钟的;
这就造成了10点的binlog,有些表数据是11点,那么10点-11点的 binlog重做时,这些表这个时候有什么删除 更新 插入等等 很容易造成 key不存在,或者重复唯一键;
(2)那种主从同步的好好的,有人手贱删掉了从库的数据、更新从库数据
这些可能是几天之前的,你如果用Binlog2sql 等工具,可能需要大量重做、折腾;
甚至有可能更久远的 Binlog,只是没报错出来;突然报错出来了,但你发现binlog已经被清理掉了;
解决办法见【2】
【2】实际操作
假设是这个表,users_propstime
【2.1】主库:备份 故障表
mysqldump --lock-tables --master-data=2 --set-gtid-purged=off propdb users_propstime > users_propstime.sql
more users_propstime.sql ,找binlog 信息
【2.2】从库:忽略 故障表
stop slave;
change replication fliter replication_ignore_table=(db.users_propstime ) change replication fliter replication_wild_ignore_table=(db.users_propstime )
【2.3】从库:开启从库知道执行到 指定 master_file 与 master_Postion
start slave until MASTER_LOG_FILE='mysql-bin.000007', MASTER_LOG_POS=377534137;
主从同步执行到这个点之后,IO线程会继续执行,但SQL线程会自动关闭
【2.4】从库:根据备份文件恢复 故障表
mysql propdb < users_propstime.sql
【2.5】从库:去掉忽略,开始真正的主从同步
stop slave; change replication fliter replication_ignore_table=() change replication fliter replication_wild_ignore_table=() start slave;
至此,完成!