主从一致性需通过监控异常信号、区分修复类型、执行修复前检查及分层验证来保障。具体包括识别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 执行时刻交叉比对

主从一致性不是配置完就一劳永逸的事，而是一个需要监控、预警、归因、验证的闭环。修复动作本身不难，难的是判断“该不该修”“修到哪一步为止”“修完是否真一致”。保持敬畏，每次操作留痕，比任何自动化脚本都可靠。