千家信息网

揭秘MySQL主从数据不一致

发表于:2024-11-25 作者:千家信息网编辑
千家信息网最后更新 2024年11月25日,前言:目前MySQL数据库最常用的是主从架构,大多数高可用架构也是通过主从架构演变而来。但是主从架构运行时间长久后容易出现数据不一致的情况,比如因从库可写造成的误操作或者复制bug等,本篇文章将会详细
千家信息网最后更新 2024年11月25日揭秘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两个工具,主要用于检测主从是否一致以及修复数据不一致情况。这种方案优点是修复速度快,不需要停止主从辅助,缺点是需要知识积累,如果你原来不太会用这个工具,可能需要时间去学习,去测试,特别是在生产环境,还是要小心使用的。
    关于使用方法,可以参考下面链接:
    https://www.cnblogs.com/feiren/p/7777218.html

  • 手动重建不一致的表。

    比如我们在从库发现某几张表与主库数据不一致,而这几张表数据量也比较大,手工比对数据不现实,并且重做整个库也比较慢,这个时候可以只重做这几张表来修复主从不一致。例如:a1 b1 c1这三张表主从数据不一致,那么我们可以这么做:

    1、从库停止Slave复制
    mysql>stop slave;

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

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

    4、把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已经生成了一份快照,我们只需要导入进入,然后开启同步即可。

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

    6、导入完毕后,从库开启同步即可。
    mysql>start slave;

    这样我们就恢复了3张表,并且同步也修复了。这种方案缺点是在执行导入期间需要停止从库复制,不过也是可以接受的。

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

3.如何避免主从不一致

通过上面的介绍,可能你也大概知道了修复并不容易,所以我们要从源头上避免,那么我们该如何避免主从不一致的情况呢,下面给出几个建议,希望对你有用。

  • 主库binlog采用ROW格式。
  • 主从实例数据库版本保持一致。
  • 主库做好账号权限把控,不可以执行set sql_log_bin=0。
  • 从库开启只读,不允许人为写入。
  • 定期进行主从一致性检验。

总结:

本篇文章详细介绍了造成主从不一致的原因,修复不一致的方法及如何避免主从不一致。特别是不一致修复方法,可能还有其他方案,这个要考虑实际情况选择合适的方法修复。原创不易,希望大家多多支持。

0