主从切换后需执行RESET SLAVE ALL清除残留relay-log文件，否则磁盘空间增长且启动复制时报Failed to open relay log index；GTID模式下若主库purge了所需GTID，必须重建从库；跨版本迁移应统一binlog_format为ROW并校验非确定性语句；mysqldump时需按目标环境选择--set-gtid-purged参数。
MySQL 主从切换后 relay log 文件残留问题
主从角色切换后，旧主库可能残留未清理的 relay-log 文件（如 mysql-relay-bin.000001），但 relay_log_index 文件已清空或指向错误位置。此时执行 RESET SLAVE 通常能清除元数据，但物理文件不会自动删除——这会导致磁盘空间缓慢增长，且下次启动复制时可能因索引缺失而报错 Failed to open the relay log index file。
实操建议：
- 先运行
SHOW SLAVE STATUS\G确认Relay_Log_File和Relay_Log_Index值，再检查对应目录下文件实际存在性 -
RESET SLAVE ALL比RESET SLAVE更彻底：它不仅重置 SQL 线程状态，还会删除所有relay-log文件并清空relay_log_index - 若需保留部分 relay log（如用于审计回溯），应手动备份后再执行
RESET SLAVE ALL，否则不可逆
GTID 模式下 binlog 日志同步中断的恢复逻辑
启用 gtid_mode=ON 后，复制不再依赖 binlog filename + position，而是靠 Executed_Gtid_Set 和 Retrieved_Gtid_Set 对齐。一旦网络抖动或从库宕机时间过长，主库的 binlog 可能已被 purge（由 binlog_expire_logs_seconds 或 expire_logs_days 控制），导致从库无法追上：错误信息通常是 The slave is connecting using CHANGE MASTER TO MASTER_AUTO_POSITION = 1, but the master has purged binary logs containing GTIDs that the slave requires。
实操建议：
- 检查主库已 purge 的 GTID 范围：
SELECT * FROM performance_schema.replication_applier_status_by_coordinator;结合SHOW MASTER LOGS;和SELECT @@global.gtid_purged; - 若从库缺失的 GTID 已被 purge，必须重新搭建从库——不能仅靠
SET GLOBAL gtid_purged = '...'注入，除非你确认该 GTID 集合确实未在任何节点执行过 - 日常应监控
Seconds_Behind_Master和Retrieved_Gtid_Set与Executed_Gtid_Set的差值，差值持续增大说明日志消费滞后
跨版本迁移时 binlog 格式兼容性陷阱
MySQL 5.7 升级到 8.0 是常见路径，但默认 binlog_format 行为有变化：5.7 默认为 STATEMENT 或 MIXED，而 8.0 推荐且部分特性（如某些 JSON 函数、窗口函数）强制要求 ROW。若迁移后仍用旧格式，可能触发复制中断，错误类似 Error 'Cannot execute statement: binlogging of stored functions and triggers is not allowed' on query。
实操建议：
- 迁移前在 5.7 主库执行
SET GLOBAL binlog_format = 'ROW';并写入配置文件my.cnf，确保重启后持久生效 - 检查所有存储过程、函数、触发器是否含非确定性语句（如
NOW(),UUID(), 用户变量赋值），这些在ROW模式下可能被拒绝写入 binlog - 8.0 中
binlog_row_image = FULL是默认值，但若从库是 5.6 或更早版本，需设为MINIMAL以兼容；不过跨大版本主从已不被官方支持，应避免
SET GLOBAL binlog_format = 'ROW'; SET GLOBAL binlog_row_image = 'FULL'; FLUSH LOGS;
mysqldump 导出时如何保证日志位置与 GTID 一致
使用 mysqldump --single-transaction 备份时，若同时开启 GTID，容易忽略 --set-gtid-purged=ON（默认值）带来的副作用：它会在 dump 文件头部写入 SET @@GLOBAL.GTID_PURGED='...';。若目标实例已有其他 GTID 记录，这条语句会直接失败，报错 Cannot add or update a child row: a foreign key constraint fails（实际是 GTID 冲突）。
实操建议：
- 对 GTID 已启用的实例，dump 时显式指定
--set-gtid-purged=AUTO：当导出包含binlog位置时自动关闭注入，否则保留 - 若目标库是全新实例，用
--set-gtid-purged=ON是安全的；但如果是追加数据到已有从库，必须用--set-gtid-purged=OFF并手动记录SHOW MASTER STATUS中的Executed_Gtid_Set - 务必验证 dump 文件开头是否含
SET @@GLOBAL.GTID_PURGED行，并与目标环境 GTID 状态比对
日志文件不是“备份完就没事”的静态产物，它的生命周期横跨备份、传输、恢复、复制多个环节。最容易被跳过的一步，是迁移后对 relay-log 目录的手动巡检——哪怕只多一行 ls -lt | head -5，也能避开后续三天排查磁盘告警的时间。
