MySQL主从复制中从库的binlog何时可以安全清理-mysql教程-PHP中文网

从库的relay log由relay_log_purge控制自动清理，该参数默认on，sql线程执行完后即删；若关闭则需手动purge relay logs，严禁rm删除，否则破坏index文件致同步失败。

mysql主从复制中从库的binlog何时可以安全清理

从库默认不生成 binlog（除非开了 log_bin），它只写 relay log（中继日志）。所以严格来说，“从库的 binlog”这个说法本身容易误导——你要清理的其实是 relay log，而它的清理由 relay_log_purge 控制。

该变量默认为 ON，意味着 SQL 线程执行完 relay log 中的事件后，MySQL 会自动删除对应文件。这是安全的，无需人工干预。

若手动关了：SET GLOBAL relay_log_purge = OFF;，relay log 就会不断堆积，必须定期 PURGE RELAY LOGS
检查当前状态：SHOW VARIABLES LIKE 'relay_log_purge';
确认 relay log 当前位置：SHOW SLAVE STATUS\G 中的 Relay_Log_File 和 Relay_Log_Pos

即使 relay_log_purge = ON，有时也会因异常中断（如 SQL 线程 crash）导致旧 relay log 残留。此时想手动清理，不能只看文件名序号，必须确认这些文件里的事件已被完全应用。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

先查同步状态：SHOW SLAVE STATUS\G，确保 Slave_SQL_Running: Yes 且 Seconds_Behind_Master 为 0 或稳定值
再看 Relay_Master_Log_File 和 Exec_Master_Log_Pos：它们共同标识“主库上哪个 binlog 文件、哪个位置，已成功在从库执行”
执行 PURGE RELAY LOGS BEFORE 'mysql-relay-bin.000123'; 时，目标文件必须早于 Relay_Log_File（不是 Relay_Master_Log_File）——因为 Relay_Log_File 是当前正在读的 relay log 名

如果从库同时作为下级主库（级联复制），或开启了 log_bin，那它确实会产生自己的 binlog。这部分 binlog 的清理规则和主库完全一致：只能删被所有下游从库消费过的部分。

先查本机 SHOW MASTER STATUS 确认当前最新 binlog 文件（如 mysql-bin.000201）
再登录所有下游从库，执行 SHOW SLAVE STATUS\G，取所有 Relay_Master_Log_File 中序号最小的那个（比如 mysql-bin.000198）
你最多只能 PURGE BINARY LOGS TO 'mysql-bin.000198'; —— 删掉 000197 及更早，000198 必须保留
注意：这种场景下，expire_logs_days 或 binlog_expire_logs_seconds 依然生效，但必须设得比最大从库延迟还长

MySQL 不靠文件系统列表来定位 relay log，而是依赖 relay-log.index 文件记录已加载的 relay log 路径。手动 rm 会破坏这个索引与实际文件的一致性。

SQL 线程可能报错：Could not find target log file mentioned in relay log info
执行 START SLAVE 时卡住，甚至无法恢复同步
PURGE RELAY LOGS 是唯一安全方式，它会同步更新 index 文件并清空磁盘
临时应急可先 RESET SLAVE（清空 relay log 和复制元数据），但必须确保主库 binlog 还在、且你能重新 CHANGE MASTER TO

关键点在于：从库的 relay log 清理是自动的，binlog 清理则要看它是否承担主库角色；无论哪种，都别碰文件系统层面的 rm，所有清理必须走 MySQL 内部命令。