人人都会AI编程

19.4 主从不一致原因与数据修复

更新时间：2026-07-10

主从复制在理想情况下，从库应该与主库数据完全一致。但在实际运维中，由于各种原因，主从数据可能出现差异。这些差异如果未被及时发现，轻则导致业务查询结果异常，重则造成数据决策错误。因此，理解不一致的常见原因，并掌握检测与修复方法，是运维人员和后端开发必备的能力。

19.4.1 主从不一致的常见原因

1. 从库写入数据

这是最常见也最不应该发生的原因。主从复制中，所有写入操作都应该发生在主库，从库仅用于只读查询。如果有人在从库上执行了 INSERT、UPDATE、DELETE 等写操作，从库就会拥有主库所没有的数据，或者主库后续对该行的修改在从库上被覆盖，从而导致不一致。

  • 防范措施：将从库设置为只读模式（SET GLOBAL read_only = ON;），并确保应用账户没有 SUPER 权限（该权限可以绕过只读限制）。

2. SQL 语句在主从执行结果不同

即使所有写入都只在主库执行，如果 SQL 本身存在不确定性，主从执行时可能会产生不同结果。例如：

  • 使用 LIMIT 但未配合 ORDER BY，导致每次返回的受影响行不一样。
  • 使用 NOW()、RAND()、UUID() 等函数，生成的值在主从可能不同。
  • 对于基于行复制（ROW）模式，这些函数会被复制为实际的值，因此问题较少。但如果是基于语句复制（STATEMENT）或混合复制（MIXED）且被判定为可以使用语句复制，就可能导致不一致。
  • 用户定义的变量或 @@hostname 等系统变量也可能导致歧义。

3. 事务隔离级别和锁机制导致的不一致

在 STATEMENT 或 MIXED 复制模式下，如果主库执行了一个更新操作，该操作在从库重放时，由于数据状态（如其他事务的提交顺序）不同，可能导致不同结果。例如，从库重放 UPDATE ... WHERE id IN (SELECT ...) 时，子查询返回的结果在主库和从库不同。

4. 从库复制线程中断，跳过错误继续应用

复制过程中，从库可能因为主键冲突、更新找不到行等错误而中断。如果运维人员使用 STOP SLAVE; SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1; START SLAVE; 跳过了某个错误，就等于忽略了一个事务的差异。之后的操作就可能以错误的状态为基础继续执行，导致数据偏差累积。

5. 非事务引擎表与崩溃恢复

如果使用了 MyISAM 等非事务引擎表，主库某个操作执行到一半崩溃，恢复后可能处于部分更新的状态，而从库已经执行了完整语句。这类不一致很难追踪，因此推荐使用 InnoDB。

6. 主库 Binlog 格式或参数变更

复制进行中，如果更改了 Binlog 格式（如从 ROW 变成 STATEMENT），或者修改了影响复制的参数（如 sql_mode、character_set_server 等），可能导致从库重放时行为不一致。

7. 主从版本不一致导致的兼容性问题

从库升级到了新版本，主库停留在旧版本，或者反之。某些 SQL 行为在新版本中有所改变（例如默认 sql_mode 改变），导致同样的 Binlog 在从库执行时含义不同。

8. 人为误操作与外部工具影响

  • 对主库使用数据导出工具直接修改数据后，又从备份恢复部分数据。
  • 使用 XtraBackup 恢复从库时未正确同步复制位置。
  • 迁移、扩容过程中，复制链路中断后通过有人工操作重新对齐时出现偏差。

19.4.2 检测主从数据不一致

越早发现不一致，修复代价越低。常见的检测手段包括：

1. 使用 pt-table-checksum（Percona Toolkit）

这是目前最成熟的检测工具。它在主库上对每张表的分块数据计算 CRC32 校验和，并将校验和写入一个结果表中，通过复制流到达从库。从库再次计算本地相同数据块的校验和，对比后即可发现差异。

pt-table-checksum h=主库IP,P=3306,u=checksum_user,p=password \
  --databases db1,db2 --tables t1,t2 \
  --replicate=percona.checksums --no-check-replication-filters

优点：对线上影响小，支持按块（chunk）计算，可以指定数据库和表。

2. 使用 mysqldbcompare（MySQL Utilities）

该工具在两个数据库之间逐表对比对象定义和行数据，适合小规模、可隔离的对比场景。

mysqldbcompare --server1=user:pass@host1:3306 --server2=user:pass@host2:3306 db1:db1

3. 应用层数据对比

对于关键业务表，可在应用代码里定时查询主从相同的主键数据，对比关键字段的取值或更新时间。例如，每天凌晨对比昨天订单的总金额是否一致。这种方案最简单，但需要知道对比哪些列，且无法发现隐藏的不一致。

4. 利用 GTID 判断

如果使用 GTID 复制，可以通过查询主库和从库的 SHOW MASTER STATUS 和 SHOW SLAVE STATUS 的 GTID 集合差异，判断是否存在滞后或无数据差异但在事务上不一致。Executed_Gtid_Set 如果与主库不完全相同，通常意味着有未复制的或额外的事务。

19.4.3 数据修复方案

确认不一致后，修复方案取决于差异的范围和业务影响程度。

方案一：重新同步从库（全量修复）

最简单、最彻底的方式。适用于数据量可控、允许短暂延迟的场景。

步骤：

  1. 在主库上使用 XtraBackup 做热备份并记录位点（或 GTID）。
  2. 将备份恢复到一个新的从库或直接恢复现有从库的数据目录。
  3. 配置复制，使用备份时的位点或 GTID 启动复制。
  4. 验证数据一致性。
# 主库备份
xtrabackup --backup --target-dir=/backup/mysql --user=root --password=xxx
xtrabackup --prepare --target-dir=/backup/mysql
# 将 /backup/mysql 复制到从库数据目录，启动从库

优点：最彻底，数据一定一致。
缺点：数据量大时备份恢复耗时，而且需要停掉从库或切换只读。

方案二：使用 pt-table-sync 增量修复

Percona Toolkit 中的 pt-table-sync 可以对比主从数据差异，并生成或直接执行 SQL 语句来修复不一致的行。可以指定要修复的表，也支持只打印 SQL 让 DBA 审核后执行。

# 打印修复 SQL（不执行）
pt-table-sync --print h=主库IP,D=db1,t=t1 h=从库IP
# 直接在从库上修复
pt-table-sync --execute h=主库IP,D=db1,t=t1 h=从库IP

工具会根据主从校验和差异，自动在主库上查询数据，然后生成 REPLACE 或 DELETE/INSERT 语句在从库执行，使从库与主库一致。注意：对生产环境，建议先在测试库验证，并在从库上搭建临时实例操作。

方案三：逻辑备份 + 导入差异表

当只有少数几张表不一致，且数据量较小，可以手动操作：

  1. 在主库上 SELECT ... INTO OUTFILE 导出不一致表的准确数据。
  2. 导入到从库对应的表中（先清空表或对比后更新）。
  3. 或者使用 mysqldump --where 导出有差异的数据范围，再导入从库。

这种方式依赖人肉眼判断差异范围，容易遗漏，只适合应急。

方案四：GTID 模式下注入空事务

如果不一致是由于从库多出了一些事务，且不影响数据（例如从库上误执行了某些不影响数据的 DML），可以通过 GTID 注入空事务的方式，让从库与主库的 GTID 集合一致。

例如，从库多了 uuid:12 这个事务，可以注入一个空事务来绕过：

STOP SLAVE;
SET GTID_NEXT='uuid:12';
BEGIN; COMMIT;
SET GTID_NEXT=AUTOMATIC;
START SLAVE;

这个方法只能解决 GTID 集合的差异，不修复实际数据行不一致，仅用于清理多余的 GTID 记录。

方案五：部分恢复并重放 Binlog

如果主库有完整的 Binlog 保留，且你能找到不一致产生的时间点，可以用 mysqlbinlog 将之后的主库 Binlog 解析为 SQL，然后在从库跳过重复的部分，重新应用缺失的部分。这需要很强的分析能力和足够长的 Binlog 保存时间，一般不常用。

19.4.4 预防与日常维护建议

  1. 强制只读：所有从库设置 read_only=1，避免人为或应用误写。
  2. 使用 ROW 格式复制：binlog_format=ROW 是 MySQL 8.0 的默认设置，它能避免绝大多数由于语句不确定性导致的不一致，也是最安全的复制格式。
  3. 开启 GTID 复制：GTID 简化了故障转移和位点追踪，也便于检测差异。
  4. 监控复制延迟和错误：使用 SHOW SLAVE STATUS 中的 Seconds_Behind_Master 和 Last_IO_Errno、Last_SQL_Errno 字段，结合监控告警（如 Prometheus + mysqld_exporter）及时发现问题。
  5. 定期数据校验：使用 pt-table-checksum 定期（如每周）对核心业务表进行校验，建立校验基线，出现偏差立即告警。
  6. 规范变更流程：任何复制参数修改、Binlog 格式变更都要经过评审，并验证从库是否能正常应用。

总之，主从不一致就像软件中的隐蔽 Bug，不可能完全避免，但通过合理的架构、检测手段和修复流程，我们可以将其影响降到最低，确保数据一致性的底线不被突破。