MySQL从库长时间不同步的应急预案：何时抢救，何时重建
主从延迟超过 30 分钟，Seconds_Behind_Master 持续为 NULL 或极大值怎么办
遇到从库严重延迟，第一步永远是查看SHOW SLA VE STATUS\G的输出。这里有几个关键指标需要你重点关注：Seconds_Behind_Master、Sla ve_SQL_Running_State，以及如果启用了GTID，Retrieved_Gtid_Set和Executed_Gtid_Set的差异。
这里有个关键判断：如果Seconds_Behind_Master显示为NULL，那问题性质就变了——这通常不是“同步慢”，而是“SQL线程已经卡死”了。如果数值持续飙升，比如超过1800秒（30分钟）还在不断增长，基本可以断定同步链路靠自身已经无法恢复。
先别急着执行STOP SLA VE或重启服务。正确的做法是，根据Sla ve_SQL_Running_State的状态，判断这是否属于临时性阻塞：
- 如果状态显示
Waiting for dependent transaction to commit，这很可能是并行复制下的依赖冲突，尤其是在sla ve_preserve_commit_order=ON的设置下，需要检查事务间的依赖关系。 - 如果状态卡在
Reading event from the relay log且长时间没有进展，那么中转日志（relay log）本身损坏的可能性就很大了。这时需要用mysqlbinlog工具手动解析Relay_Log_File和Relay_Log_Pos指定位置附近的事件，看是否能正常读取。 - 如果发现
Retrieved_Gtid_Set和Executed_Gtid_Set差距巨大，并且不再变化，问题可能出在I/O线程。一个常见原因是主库的max_allowed_packet设置小于从库，导致大型事件被截断。
什么情况下必须放弃增量恢复，直接全量重建从库
在数据库运维里，时间成本也是成本。不是所有的延迟都值得投入大量精力去“抢救”。遇到以下几种情况，经验表明，直接全量重建从库往往是更高效、更稳妥的选择：
- 中转日志丢失或损坏：从库的
relay_log文件丢失或物理损坏，并且relay_log_purge=OFF导致无法自动清理和定位新的中断点。 - 主库日志已被清理：主库上
Relay_Master_Log_File所指向的那个binlog文件已经被purge命令删除（可以通过在主库执行SHOW BINARY LOGS来验证）。断了源头，增量恢复自然无从谈起。 - 出现结构性不一致错误：从库反复报错，例如
duplicate entry（主键冲突）、no such table（表不存在）等。这通常意味着主从的DDL或DML执行顺序已经不一致。在GTID模式下，连sql_sla ve_skip_counter都无法使用，修复难度极大。 - 长期阻塞的大事务：延迟已经超过24小时，并且
SHOW PROCESSLIST显示SQL线程长期处于Updating或Copying to tmp table状态。这极可能是一个超大事务在回放时卡住，强行等待它完成，不如从头开始同步。
mysqldump 全量导出时必须加的 5 个参数
决定重建，导出数据就是第一步。用mysqldump时，下面这5个参数至关重要，漏掉任何一个，都可能在从库恢复时埋下隐患，甚至导致GTID集合混乱。
--single-transaction：这个参数用于获取一个一致性快照，确保导出数据的一致性。但要注意，它只对InnoDB引擎有效。如果数据库里混用了MyISAM表，必须同时加上--lock-all-tables。--master-data=2：对于非GTID模式，这个参数会将CHANGE MASTER TO所需的binlog文件名和位置信息以注释形式写入导出文件。如果使用的是GTID模式，则应改用--set-gtid-purged=ON来导出GTID信息。--routines和--triggers：默认情况下，存储过程和触发器是不会被导出的。漏掉它们，会导致从库的业务逻辑不完整。--hex-blob：这个参数会将BLOB类型字段的内容以十六进制格式导出。尤其是在跨平台迁移时，它能有效避免二进制数据被终端或传输工具错误处理，导致数据损坏。
一个完整的导出命令示例如下：
mysqldump --single-transaction --master-data=2 --routines --triggers --hex-blob -u root -p mydb > mydb.sql
重建后校验从库数据是否真正一致
重建完成，Seconds_Behind_Master显示为0，是不是就大功告成了？千万别这么想。即使在GTID模式下，主从的Executed_Gtid_Set完全一致，也不绝对等于数据内容一致——比如某条UPDATE语句被错误跳过，GTID依然会向前推进。
因此，数据一致性校验是重建后的必修课：
- 使用专业工具进行行级校验：推荐使用Percona Toolkit中的
pt-table-checksum。它通过分块计算CRC校验码的方式对比数据，比简单的SELECT COUNT(*)可靠得多，而且支持在线运行，基本不锁表。 - 手动抽样对比：对于核心业务表，可以执行如
SELECT MD5(CONCAT_WS('|', col1, col2, ...)) FROM t ORDER BY pk LIMIT 1000这样的查询，分别在主库和从库运行，然后比对结果集的哈希值。这是一种轻量级的快速验证方法。 - 检查业务逻辑字段：查看自增主键的最大值是否连续，检查时间戳字段（如
created_at）是否有异常的未来时间点。如果从库的ID最大值远小于主库，或者出现了未来时间，很可能意味着部分数据写入已经丢失。
最后，有两个细节最容易被忽略，却可能引发后续问题：一是重建后忘记调整监控系统的告警阈值，导致延迟已经归零却还在持续报警；二是忘了重新设置read_only属性，需要先SET GLOBAL read_only=OFF以完成重建初始设置，最后再SET GLOBAL read_only=ON将从库置于只读模式，避免应用误写入。
