MySQL主从数据差异修复

背景概述

MySQL主从复制技术应用非常广泛。然而，由于主从复制是基于binlog的逻辑复制，实际应用中可能会因为各种原因出现主从数据不一致的情况。因此，我们需要定期或不定期地开展主从复制数据一致性的校验和修复工作。但是，一些不正确的操作可能会导致修复后数据仍然不一致，下面我们来探讨这些问题。

MySQL主从数据差异修复

错误操作

很多人处理数据不一致时采用从主库重新导入备库的操作，甚至有些专业MySQLDBA也是采取如此操作。但是这种操作可能会导致数据不一致，因为数据往往是动态变化的，并且复制基于GTID的复制无法自动针对某一张表去挑选数据进行复制应用。

错误分析

在解决主从数据不一致的问题时，有些人试图停止或保持slave复制，然后在master导出或slave导入数据表，重启slave复制。然而，在该操作过程中，如果T1时刻之前就已经发生了错误，复制异常时binglog日志中记录的错误时间点早于T1时刻。此时，slave导入数据之后，日志开始应用的位置是早于T1而不是从导入时刻开始。那么，slave节点将会重复故障点到导出时刻的操作，结果可能报错，或者导致主从数据仍然不一致。

正确操作

为了确保数据一致性，下面是一些正确的操作方法：

停止slave复制，在T1时刻设置数据表只读，然后在T2时刻在master导出数据表，并在T3时刻在slave导入数据表，最后在T4时刻重启slave复制。在该操作过程中，T1至T3时刻数据表没有数据变更，因此，slave复制停止在T1和T3之间，master和slave的数据是一致的，T4时刻开启复制应用，slave从T2时刻的日志开始应用，数据一致，不会发生异常。
使用pt-table-sync进行数据修复。
通过传输表空间的方式进行数据修复。
手工处理差异的数据，视具体场景（差异量、影响范围、修复所需时间及影响）选择合适的修复方式。