从库复制失效90%应直接重建而非修复，因修复易遗漏relay log损坏、gtid不一致等隐患；主库binlog被purge导致无法追平时，需停从库、主库做一致性快照（mysqldump或xtrabackup）、传入从库导入。
从库复制失效，90%的情况不用修，直接重建更稳、更快、更少出错。修旧数据容易漏掉 relay log 损坏、GTID 集不一致、表结构隐性差异等“看不见的坑”，而重建能一并清掉。下面分场景说清楚怎么做。
主库 binlog 已被 purge，报错 Got fatal error 1236 或 Could not find first log file name
这是最典型的“无法追平”信号，说明主库已经删掉了从库需要的 binlog 文件。跳过、重设 position、手动解析 binlog 全都没用——缺的数据根本不存在了。
- 立刻停掉从库：
STOP SLAVE; - 主库做一致性快照：用
mysqldump --master-data=2 --single-transaction --all-databases > full.sql（推荐）或xtrabackup（大库首选） - 把备份传到从库，导入：
mysql - 从
full.sql里 grep 出CHANGE MASTER TO行（它带注释，去掉--再执行）；若用 GTID，改用CHANGE MASTER TO MASTER_AUTO_POSITION = 1; -
START SLAVE;后检查Slave_IO_Running和Slave_SQL_Running是否都为Yes
从库卡在 SQL 线程，Last_SQL_Error 是重复键/记录不存在，且只错一次
这类错误常见于开发误操作或临时写入从库，如果确认业务可接受单条数据不一致（比如日志表、统计缓存），可以跳过。但注意：sql_slave_skip_counter 只对 SBR 有效，RBR 和 GTID 下会失效甚至破坏一致性。
- 非 GTID + SBR 模式：执行
STOP SLAVE; SET GLOBAL sql_slave_skip_counter = 1; START SLAVE; - GTID 模式：必须用空事务注入，
SET GTID_NEXT = 'aaa-bbb:123'; BEGIN; COMMIT; SET GTID_NEXT = 'AUTOMATIC';，其中aaa-bbb:123要严格匹配SHOW SLAVE STATUS\G中的Retrieved_Gtid_Set缺失项 - 跳完立刻验证：
Seconds_Behind_Master是否开始下降？Last_SQL_Error是否清空？ - 别连续跳多次——每跳一次都要重新确认 GTID 或 position 是否对得上，否则后续同步会彻底乱掉
从库 Pod 在 K8s 里反复 CrashLoopBackOff，日志含 Lock wait timeout exceeded 或 Cannot replicate because the source purged required binary logs
这是 Bitnami MySQL Helm Chart 的典型陷阱：容器启动时自动执行 mysql_upgrade，但残留锁或缺失 binlog 会让它死循环失败。不能等它自己恢复。
- 先让 Pod 启动起来：编辑
StatefulSet，加环境变量MYSQL_SKIP_UPGRADE=yes，或覆盖command: ["bash", "-c", "sleep infinity"]进入容器手动干预 - 进容器后，用
mysql --defaults-file=/opt/bitnami/mysql/conf/my.cnf -u root -p手动连，执行DROP TABLE IF EXISTS mysql.innodb_table_stats;等疑似卡住的元数据表（具体看日志报哪张表） - 清理完再删掉
command覆盖，让容器走默认启动流程 - 此时从库只是“能跑”，不代表能复制——大概率 binlog 已断，仍需走上面的重建流程
真正耗时的从来不是命令敲几下，而是判断“该不该跳过”和“有没有漏掉 GTID 差集”。只要 Retrieved_Gtid_Set 和 Executed_Gtid_Set 对不上，或者 Relay_Master_Log_File 指向的文件在主库 SHOW BINARY LOGS 里找不到，就别折腾修复了——重建从库，5 分钟比排查两小时更可靠。
