揭秘MySQL主从数据不一致

前言：

目前MySQL数据库最经常使用的是主从架构，大多数高可用架构也是经过主从架构演变而来。可是主从架构运行时间长久后容易出现数据不一致的状况，好比因从库可写形成的误操做或者复制bug等，本篇文章将会详细探究出现主从不一致及如何解决这种问题。

1.形成主从不一致的缘由

形成主从不一致的可能缘由有不少，下面简单列举几条：

• 主库binlog格式为Statement，同步到从库执行后可能形成主从不一致。
• 主库执行更改前有执行set sql_log_bin=0，会使主库不记录binlog，从库也没法变动这部分数据。
• 从节点未设置只读，误操做写入数据。
• 主库或从库意外宕机，宕机可能会形成binlog或者relaylog文件出现损坏，致使主从不一致。
• 主从实例版本不一致，特别是高版本是主，低版本为从的状况下，主数据库上面支持的功能，从数据库上面可能不支持该功能。
• MySQL自身bug致使。

2.主从不一致修复方法

下面介绍下主从不一致的修复方法，注意，这里讲的是修复主从不一致而不是修复主从同步错误。

想要修复主从不一致，咱们首先要发现主从不一致，下面将根据不一样情形给出合适的修复方法。

第一种状况：好比说执行脚本时，为了更快的执行完，在脚本里增长了set sql_log_bin=0。那么这个脚本的全部数据变动将没法应用到从库，这个时候主从数据就不一致了，解决的方法是先停掉主从复制，而后手动在从库执行下这个脚本，最后开启主从复制便可。

第二种状况：可能你的从库并未设置只读，同事因不太清楚架构，误操做致使在从库作了数据写入，这种状况应该及时反馈并解决。解决方法：若是这些语句确实须要执行，则能够在主库先执行set sql_log_bin=0，而后再执行语句；若是不须要执行这些语句，则须要在从库上回滚掉先前的误操做。

不过有时候状况并非那么简单，可能遇到比较多的状况是：主从两个实例已经运行好久了，某日进行一致性检验发现主从不一致了，很难找到具体发生不一致的缘由及时间。那么这个时候应该怎么办呢，有人说，从库重作一遍，虽然这也是一种解决方法，可是这个方案恢复时间比较慢，并且有时候从库也是承担一部分的查询操做的，不能贸然重建。下面重点讲下这种状况下的修复方法。

• 使用percona-toolkit工具辅助。

PT工具包中包含pt-table-checksum和pt-table-sync两个工具，主要用于检测主从是否一致以及修复数据不一致状况。这种方案优势是修复速度快，不须要中止主从辅助，缺点是须要知识积累，若是你原来不太会用这个工具，可能须要时间去学习，去测试，特别是在生产环境，仍是要当心使用的。 关于使用方法，能够参考下面连接： www.cnblogs.com/feiren/p/77…

• 手动重建不一致的表。

好比咱们在从库发现某几张表与主库数据不一致，而这几张表数据量也比较大，手工比对数据不现实，而且重作整个库也比较慢，这个时候能够只重作这几张表来修复主从不一致。例如：a1 b1 c1这三张表主从数据不一致，那么咱们能够这么作：

一、从库中止Slave复制 mysql>stop slave;

二、在主库上dump这三张表，并记录下同步的binlog和POS点 mysqldump -uroot -p123456 -q --single-transaction --master-data=2 yourdb a1 b1 c1 > ./a1_b1_c1.sql

三、查看a1_b1_c1.sql文件，找出记录的binlog和POS点 more a1_b1_c1.sql 例如MASTER_LOG_FILE='mysql-bin.002974', MASTER_LOG_POS=55056952;

四、把a1_b1_c1.sql拷贝到Slave机器上，并作Change master to指向 mysql>start slave until MASTER_LOG_FILE='mysql-bin.002974', MASTER_LOG_POS=55056952; 注：我来解释下，这步是什么意思。保障其余表的数据不丢失，一直同步，直到同步完那个点结束，a1,b1,c1表的数据在以前的dump已经生成了一份快照，咱们只须要导入进入，而后开启同步便可。

五、在Slave机器上导入a1_b1_c1.sql (若从库开启了binlog 为使导入加快，能够先执行set sql_log_bin=0) mysql -uroot -p123456 yourdb < ./a1_b1_c1.sql

六、导入完毕后，从库开启同步便可。 mysql>start slave;

这样咱们就恢复了3张表，而且同步也修复了。这种方案缺点是在执行导入期间须要中止从库复制，不过也是能够接受的。

可能还有其余修复方法，好比用Navicat等工具进行比对同步，不过这类工具只适用于小数据量，当有上千万数据时，再用这种方法就不现实了。你有没有相似经验呢，也能够留言分享下。

3.如何避免主从不一致

经过上面的介绍，可能你也大概知道了修复并不容易，因此咱们要从源头上避免，那么咱们该如何避免主从不一致的状况呢，下面给出几个建议，但愿对你有用。

• 主库binlog采用ROW格式。
• 主从实例数据库版本保持一致。
• 主库作好帐号权限把控，不能够执行set sql_log_bin=0。
• 从库开启只读，不容许人为写入。
• 按期进行主从一致性检验。

总结：

本篇文章详细介绍了形成主从不一致的缘由，修复不一致的方法及如何避免主从不一致。特别是不一致修复方法，可能还有其余方案，这个要考虑实际状况选择合适的方法修复。原创不易，但愿你们多多支持。