MySQL主从复制中断后如何修复_重新构建从库的详细步骤
主从复制中断后怎么快速判断是临时延迟还是已断开
遇到主从同步卡住，先别急着动手重建。很多时候，所谓的“中断”只是暂时的延迟，表现为 Seconds_Behind_Master 持续显示为 NULL 或者数值飙升，但 IO 线程其实还在正常工作。那么，如何准确判断复制链路是真的断开了呢？
真正的典型信号，其实藏在 SHOW SLA VE STATUS\G 的输出里：Sla ve_IO_Running: No 或者 Sla ve_SQL_Running: No。只要这两个状态有一个不是 “Yes”，复制就已经停摆了。
真正断开的典型信号是Sla ve_IO_Running: No或Sla ve_SQL_Running: No；需同时检查两个Running状态，而非仅看Seconds_Behind_Master。
这里有个常见的误判点：只盯着 Seconds_Behind_Master 看。一旦 SQL 线程停止工作，这个延迟值就失效了。所以，必须同时检查两个 Running 状态字段，缺一不可。
- 如果看到
Sla ve_IO_Running: Yes但Sla ve_SQL_Running: No，那问题大概率出在 SQL 线程上。常见原因包括数据冲突（比如主库删除了某行，从库却试图更新它），或者 DDL 语句不兼容。 - 如果
Sla ve_IO_Running: No，首先要查的就是Last_IO_Error字段。网络不通、复制用户权限失效、或者主库的 binlog 文件被意外清理，都是背后的“元凶”。 - 定位到具体错误后，可以尝试用
mysqlbinlog --base64-output=decode-rows -v命令手动解析从库报错指向的那个 binlog 文件，确认具体的 SQL 语句，以及对应的 GTID 或 position 信息是否还能被正常定位。
GTID 模式下跳过错误的正确姿势
当数据库开启了 GTID 模式，修复思路就得调整了。传统的 SET GLOBAL sql_sla ve_skip_counter = 1 命令在这里是禁用的，因为它会破坏 GTID 的连续性，很可能导致后续同步彻底错乱，甚至引发数据不一致的严重问题。
正确的做法，是使用 SET GTID_NEXT 来“注入”一个空事务，从而跳过特定的错误事件：
STOP SLA VE; SET GTID_NEXT = 'xxx:yyy'; -- 替换为报错事件对应的 GTID BEGIN; COMMIT; SET GTID_NEXT = 'AUTOMATIC'; START SLA VE;
这个操作有几个关键点，一步都不能错：
GTID_NEXT的值必须严格匹配SHOW SLA VE STATUS结果中Retrieved_Gtid_Set和Executed_Gtid_Set的差集。简单说，就是主库已经传过来、但从库还没执行的那个 GTID。填错了，从库会拒绝执行。- 跳过之前，务必确认这个事务是可以丢弃的。比如，它是主库上误执行的一个
DROP TABLE操作。否则，跳过就等于主动丢失了数据。 - 这个方法一次只能跳过一个 GTID 事件。如果连续出错，就需要重复操作。从经验来看，不建议进行批量跳过，风险太高。
什么时候必须重建从库而不是修复
不是所有中断都能靠“跳过”来解决。遇到以下几种情况，修复的性价比极低，直接重建从库往往是更明智的选择：主库的 binlog 已经被 purge 清理掉了；从库的 relay log 文件损坏；GTID 集合出现严重不一致（Retrieved_Gtid_Set 和 Executed_Gtid_Set 完全对不上）；或者从库的表结构与主库存在不可逆的差异（典型情况是主库加了唯一索引，但从库没加，且表中已存在重复数据）。
重建从库，可不是指从头安装一个 MySQL 实例。它的核心思想，是基于主库当前的一个一致性快照，配合准确的 binlog 位点，让从库从这个新起点重新开始同步。具体步骤是：
- 首先，在主库执行
FLUSH TABLES WITH READ LOCK获取全局读锁，然后立刻记录下SHOW MASTER STATUS的输出。非 GTID 模式记下File和Position；GTID 模式则记下Executed_Gtid_Set。 - 接着，使用
mysqldump --single-transaction --master-data=2命令导出数据（如果是 GTID 模式，记得加上--set-gtid-purged=ON参数）。 - 数据导入从库后，就是重新建立复制关系。非 GTID 模式用
CHANGE MASTER TO ... MASTER_LOG_FILE='...', MASTER_LOG_POS=...指定位点；GTID 模式则先执行RESET SLA VE; SET GLOBAL gtid_purged='...';，再用CHANGE MASTER TO ... GET_MASTER_PUBLIC_KEY=1等命令配置。 - 这里有个细节容易忽略：务必确保从库的
read_only参数在导入前被设置为 0（关闭），否则 mysqldump 导入可能会失败。
重建后验证同步是否真正可靠
数据导入完成，执行 START SLA VE 后，千万别看到 Sla ve_SQL_Running: Yes 就以为万事大吉了。真正的风险，往往藏在数据一致性里。同步线程在跑，不等于数据完全一致。
推荐几个简单有效的验证方法：
- 立刻对几张核心业务表执行
SELECT COUNT(*)，对比主从库的结果。需要注意的是，由于 MVCC 机制或未提交事务的影响，COUNT 值可能在短时间内有细微差异。最好等Seconds_Behind_Master归零后再进行比对。 - 使用
pt-table-checksum工具进行全库校验（生产环境使用需谨慎，因为它会对表加读锁）。重点查看结果中的DIFFS列是否为 0。 - 观察
SHOW SLA VE STATUS中的Relay_Log_Space值。如果它持续缓慢增长，说明同步正常；如果几乎不动，那可能意味着 SQL 线程在“静默跳过”某些语句，原因可能是字符集、SQL_MODE 不一致导致的隐式转换失败。 - 定期检查从库的 error log。留意是否有
Unsafe statement或Row event apply failed这类警告。这些问题通常不会导致复制线程停止，但会悄无声息地丢失数据，危害极大。
说到底，重建从库并不是终点，而是一条全新同步链路的起点。GTID 模式下 Auto_Position=1 的配置是否启用，主库 expire_logs_days 的参数设置是否合理，这些因素决定了下次再出问题时，你还有没有足够的日志可以用来追平数据——很多时候，这些前置配置的优化，比事后的重建操作本身更为关键。
