Seconds_Behind_Master为NULL或0但数据不一致，通常因复制中断未报错：需检查Slave_IO_Running和Slave_SQL_Running是否均为Yes；若否，则Seconds_Behind_Master无意义，应排查binlog清理、磁盘满、网络闪断等诱因。
主从复制中 Seconds_Behind_Master 为 NULL 或 0 但数据不一致
这通常不是延迟问题，而是复制已中断但未报错。执行 SHOW SLAVE STATUS\G 后重点看 Slave_IO_Running 和 Slave_SQL_Running 是否都为 Yes；若其中一个是 No，说明 IO 线程或 SQL 线程已停止，需进一步查 Seconds_Behind_Master 无意义。
常见诱因包括：主库 binlog 被清理（expire_logs_days 过小）、从库磁盘满导致 relay log 写入失败、网络闪断后 IO 线程未自动重连（尤其在低版本 MySQL 中）。
- 检查
Relay_Log_Space是否持续不增长 → 指向 IO 线程异常 - 检查
Retrieved_Gtid_Set和Executed_Gtid_Set是否相等 → 不等说明 SQL 线程卡在某条事务 - 查看错误日志路径：
SELECT @@log_error;，然后用tail -n 50 /var/log/mysqld.log找最近的SLAVE相关报错
Got fatal error 1236：从库无法读取主库 binlog 文件
典型错误信息如：Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'。本质是主库上被请求的 binlog 文件已被删除，而从库的 Master_Log_File 还指向它。
原因多为：主库设置了过短的 expire_logs_days = 1，而从库因故障停顿超 24 小时；或手动执行了 PURGE BINARY LOGS 却未同步更新从库位点。
- 确认主库当前 binlog 列表：
SHOW BINARY LOGS; - 对比从库
Master_Log_File值是否仍在主库列表中 - 若已丢失，必须重新搭建从库（GTID 模式下可尝试
SET GLOBAL gtid_purged = '...';补齐，但需确保 purged 集合完全覆盖缺失部分，否则仍会失败）
GTID 复制下 The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1 却跳过事务
当从库 SQL 线程报错（如主键冲突、字段类型不匹配），且启用了 slave_skip_errors，MySQL 会跳过该事务并继续执行后续 GTID，但不会记录跳过的细节 —— 导致数据逻辑不一致却无明显报错。
关键风险在于：跳过错误后，Executed_Gtid_Set 会包含一个本不该执行的 GTID（因为跳过不等于执行成功），后续切换主从或做一致性校验时会出问题。
- 禁用
slave_skip_errors，改用SET GLOBAL sql_slave_skip_counter = 1;（仅适用于非 GTID 模式） - GTID 模式下，必须用
SET GTID_NEXT = 'xxx-xxx-xxx:nnn'; BEGIN; COMMIT;注入空事务来跳过，且xxx-xxx-xxx:nnn必须严格匹配报错事务的 GTID - 生产环境应避免跳过，优先定位并修复源头问题（如建表语句未同步、字符集不一致导致插入失败）
从库 relay-log.info 文件损坏或与实际状态不一致
MySQL 5.6 及更早版本依赖 relay-log.info 文件持久化 SQL 线程位置；若该文件写入中途崩溃（如断电），重启后可能回退到旧位点，造成重复执行或跳过事务。
MySQL 5.7+ 默认启用 relay_log_info_repository = TABLE，将位置存于 mysql.slave_relay_log_info 表中，配合 sync_relay_log_info = 1 可大幅降低风险。但升级前遗留的旧部署仍可能出问题。
- 检查当前设置：
SELECT * FROM performance_schema.global_variables WHERE VARIABLE_NAME IN ('relay_log_info_repository', 'sync_relay_log_info'); - 若仍为 FILE 模式，建议停库后修改配置并重启，再执行
CHANGE MASTER TO ... MASTER_AUTO_POSITION = 1;强制重建 relay log - 切勿手动编辑
relay-log.info文件 —— 格式敏感且极易写错，应通过STOP SLAVE; RESET SLAVE;重置后重新配置
STOP SLAVE; RESET SLAVE ALL; CHANGE MASTER TO MASTER_HOST='192.168.1.10', MASTER_USER='repl', MASTER_PASSWORD='xxx', MASTER_PORT=3306, MASTER_AUTO_POSITION=1; START SLAVE;
GTID 模式下最易被忽略的是：RESET SLAVE 不会清空 gtid_executed，但 RESET SLAVE ALL 会清除 gtid_purged 和 gtid_executed 的部分状态，务必确认主库当前 gtid_purged 值后再执行。
