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，也能避开后续三天排查磁盘告警的时间。
