主从一致性需通过监控异常信号、区分修复类型、执行修复前检查及分层验证来保障。具体包括识别Seconds_Behind_Master异常等信号，针对主键冲突、表结构不一致等采取对应修复，修复前STOP SLAVE、备份、核对位点，再分元数据、逻辑、时间三层验证。
主从一致性是数据库高可用架构中的核心问题，复制异常若未及时发现和修复，可能导致从库数据滞后、查询结果错误甚至业务故障。关键在于快速定位异常类型、明确修复边界，并避免误操作扩大影响。
一、快速识别复制异常的常见信号
不要等到应用报错才去查，日常应监控以下指标：
- Seconds_Behind_Master 持续为 NULL 或突增（注意：为 0 不代表绝对一致，仅表示 IO/SQL 线程无积压）
- Slave_SQL_Running 和 Slave_IO_Running 任一为 No
- 从库 error log 中出现 Duplicate entry、Deadlock、No such table 等 SQL 线程报错
- 主从 show master status 与 show slave status 中的 binlog 文件名或 position 明显不连续
二、典型异常原因与对应修复思路
不同错误需区别对待，不能统一跳过或重放：
-
主键冲突（Duplicate entry）：常见于从库误写、主从双写、或 REPLACE/INSERT ... ON DUPLICATE KEY UPDATE 逻辑不一致。优先检查是否从库被人为写入；确认后可临时设
SET GLOBAL sql_slave_skip_counter = 1跳过，但必须记录并同步清理从库脏数据 - 表结构不一致（Error_code: 1146）：主库建表后未同步到从库，或从库误删表。禁止直接跳过，应先在从库执行相同 DDL，再 start slave
-
GTID 不一致（Executed_Gtid_Set 不匹配）：多用于 GTID 模式，常因从库被 reset、或手动注入事务导致。需用
SELECT MASTER_POS_WAIT()或比对gtid_executed确认缺失事务，必要时使用SET GTID_NEXT+ 空事务补位 -
网络中断导致 IO 线程停止：检查主库 binlog 是否保留（expire_logs_days）、从库 relay log 是否损坏。重启 IO 线程通常可自动恢复，但需确认
Master_Host和权限未变更
三、修复前必须做的三件事
防止“修一个错，出三个坑”：
- 在从库执行
STOP SLAVE，禁止自动重试掩盖问题 - 用
mysqldump --single-transaction --master-data=2对从库做快照备份（尤其在计划跳过或重放前） - 核对主从当前 binlog 位置、GTID 集合、以及最近几条变更的业务语义（例如：某笔订单状态更新是否已同步）
四、验证一致性不能只看 Seconds_Behind_Master
真正保障业务数据一致，需分层验证：
-
元数据层：对比主从
SELECT COUNT(*)、CHECKSUM TABLE（小表适用）、或 pt-table-checksum（大表推荐） - 逻辑层：抽样关键业务字段（如订单号、用户 ID、金额），用脚本比对主从查询结果
-
时间层：检查主库
SHOW BINLOG EVENTS IN 'xxx' FROM yyy LIMIT 1的时间戳，与从库SELECT @@timestamp执行时刻交叉比对
主从一致性不是配置完就一劳永逸的事，而是一个需要监控、预警、归因、验证的闭环。修复动作本身不难，难的是判断“该不该修”“修到哪一步为止”“修完是否真一致”。保持敬畏，每次操作留痕，比任何自动化脚本都可靠。
