MySQL主从复制技术应用非常广泛，M-S复制架构、keepalived＋M-M复制架构、MHA等高可用架构都基于MySQL主从复制技术。但因主从复制是基于binlog的逻辑复制，实际应中,可能会因为各种原因出现主从数据不一致的情况,关系数据则无小事,因此我们需要定期或不定期地开展主从复制数据一致性的校验和修复工作。那么对于mysql主从数据不一致的情况,应该怎样修复呢?不止一次听到说只需要从主库重新导入备库就可以了,咋一听似乎没毛病,但细思极恐,下面我们来探讨这些问题。
Master节点
mysqldump -uxxx -p test aa--set-gtid-purged=OFF > aa.sql
Slave节点
Source aa.sql
Start slave;
很多人处理数据不一致时采用以上操作,甚至有些专业MySQLDBA也是采取如此操作,如果数据完全静态,这样操作没有问题。但数据往往都是动态变化的,那如何确保导出导入和salve故障点的时刻的一致性呢?“现在mysql都是基于GTID的复制,mysql自己会找去从哪里开始复制”有人这样解释,但是GTID是全局的,在运行的复制架构中,无法自动针对某一张表去挑选数据进行复制应用。
下面就上面的操作进行详细分析,以下数据表特指复制中存在数据差异的数据表：
T1时刻发现复制异常
T2时刻在master导出数据表
T3时刻在slave导入数据表并启动复制
T1时刻之前就已经发生了错误,复制异常时binglog日志中记录的错误时间点早于T1时刻,slave导入数据之后,日志开始应用的位置是早于T1而不是从T2开始,那么salve节点将会重复故障点到T2时刻的操作,结果大概率是报错,或者是主从数据仍然不一致。
那么可以临时跳过出错的表(REPLICATE_WILD_IGNORE_TABLE),主从复制无延迟的时候再进行修复导出导入的修复操作,还是以上面的图为例:
假定数据是持续变化的,修复过程中salve不停止应用日志,且复制基本无延迟：
T1时刻在master导出数据表
T2时刻在slave导入数据表,并取消REPLICATE_WILD_IGNORE_TABLE设置,重启slave复制
那么slave节点将缺少T1至T2时刻的数据表的数据变更,结果要么无法启动复制要么数据存在不一致,存在后续复制异常的隐患。
既然导数过程种slave复制正常运行会导致异常,那停止slave复制后再修复是怎样的呢,下面来看一下:
T1时刻在slave停止复制
T2时刻在master导出数据表
T3时刻在slave导入数据表,并取消REPLICATE_WILD_IGNORE_TABLE设置,重启slave复制
那么slave节点将重复T1至T2时刻的数据表的数据变更,结果要么无法启动复制要么数据存在不一致,存在后续复制异常的隐患。
既然无论slave是保持复制还是停止复制,数据都不对,那正确操作是怎样的?
既然无论slave是保持复制还是停止复制,数据都不对,那正确操作是怎样的?假如salve节点在a时刻停止复制,master在b时刻导出数据,如a时刻salve节点应用binlog的位置和b时刻Masterbinlog位置相同即可确保数据一致,该操作几乎无法人为确保,但是我们可以确a和b之间数据表没有数据变更,下面描述具体过程:
T1:设置数据表只读
lock tables aa read;
T2:停止slave复制(复制无延迟的情况下,确保停止时间点在T1之后)
T3:一致性导出数据表
mysqldump -uroot test aa--set-gtid-purged=OFF --single-transaction > aa.sql
导出后可解锁master上的锁定,减少业务影响时间,如执行如上语句做一致性快照导出,导出开始后即可解锁master,无需等待导出结束
T4:在slave导入数据表,并取消REPLICATE_WILD_IGNORE_TABLE设置,重启slave复制
因为T1至T3时刻数据表没有数据变更,salve复制停止在T1与T3之间,故master和slave数据是一致的,T4时刻开启复制应用,salve从T2时刻的日志开始应用,数据一致,不会发生异常。
除了以上方式将数据修复一致之外,还可以使用pt-table-sync,以及传输表空间的方式进行数据修复,甚至手工处理差异的数据,视具体场景(差异量,影响范围,修复所需时间及影响)选择合适的修复方式。
相比修复问题,日常预防问题发生更加重要,异常宕机以及人为操作常常导致数据差异。
异常宕机：可通过更安全的配置选项规避,但安全性和性能往往不能兼得,需要结合具体业务评估。
人为操作：我遇到的数据不一致大部分为非运维人员不恰当的操作导致数据差异,设置salve节点只读可有效避免。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/130140.html
摘要：简介项目地址主从环境下数据一致性校验经常会用工具，它的原理及实施过程之前写过一篇文章生产环境使用检查数据一致性。上面的配置文件可以认为是用于控制程序的，这个配置文件是指定要校验的源库和目标库信息，以及要检验哪些表。 1. 简介 项目地址：https://github.com/seanlook/p... 主从环境下数据一致性校验经常会用 pt-table-checksum 工具，它的原理...
摘要：通过对一些客户的跨云迁移过程进行总结，发现普遍存在的挑战有三点数据完整性和一致性挑战。简而言之，跨云迁移过程中的数据一致性主要就集中在存量数据的迁移如何保证一致。前言随着互联网业务发展对容灾以及对访问加速、多供应商成本控制等需求的产生，互联网公司的多云部署和跨云迁移逐渐成为刚需，而在此过程中，最困扰运维和研发人员的就是数据的迁移和同步。俗语说 上屋搬下屋，搬洒一箩谷 ，在业务的迁移过程中一旦...
摘要：的主从备份相关配置服务器号，不要和其他服务器重复开启二进制日志索引二进制日志的文件名设为就是把每次发生的修改和事件的日志即时同步到硬盘上复制模式防止从服务器在崩溃后自动开启，以给你足够的时间修复。 实践背景 最近加入了同学的技术分享小组，4个人分两组，半月进行一次技术分享，现在一起搞Mysql我被分到讲解Mysql日志方面，上周已经讲完了，不过他们总是觉得对于日志这块了解不透彻，觉得不...
阅读 1345·2023-01-11 13:20
阅读 1680·2023-01-11 13:20
阅读 1132·2023-01-11 13:20
阅读 1857·2023-01-11 13:20
阅读 4098·2023-01-11 13:20
阅读 2704·2023-01-11 13:20
阅读 1384·2023-01-11 13:20
阅读 3594·2023-01-11 13:20
