MySQL主从复制依赖二进制日志（Binary Log）进行数据同步，合理管理这些日志对系统稳定性、磁盘使用和恢复能力至关重要。以下是关于主从复制日志的管理方法和最佳实践。
1. 主库二进制日志管理
主库生成的二进制日志记录了所有更改数据的SQL操作，是复制的基础。
关键配置项：
log-bin = /path/to/mysql-bin.log：启用并指定二进制日志路径。 expire_logs_days = 7：自动清理超过7天的日志（已弃用，建议使用binlog_expire_logs_seconds）。 binlog_expire_logs_seconds = 604800：保留日志7天（单位为秒），推荐替代expire_logs_days。 max_binlog_size = 1G：单个日志文件最大大小，到达后自动切换到下一个文件。可通过以下命令手动清理过期日志：
PURGE BINARY LOGS BEFORE '2025-04-01 00:00:00';-- 或按文件名清理
PURGE BINARY LOGS TO 'mysql-bin.000010';
2. 从库中继日志管理
从库通过I/O线程读取主库的二进制日志并写入中继日志（Relay Log），再由SQL线程回放。
相关配置：
relay-log = /path/to/relay-bin：指定中继日志文件名前缀。 relay_log_purge = ON：自动在SQL线程执行完后清除已使用的中继日志（默认开启）。 relay_log_recovery = ON：崩溃后从主库重新获取中继日志，保证一致性，建议在高可用环境中启用。若需手动清理中继日志，可执行：
RESET SLAVE; -- 清除复制状态和中继日志（慎用）CHANGE MASTER TO ... -- 需重新配置复制起点
3. 监控与维护建议
定期检查日志状态，避免磁盘空间耗尽或复制延迟。
查看主库二进制日志列表：SHOW BINARY LOGS; 查看从库中继日志状态：SHOW SLAVE STATUS\G，关注Relay_Log_Space和Seconds_Behind_Master。 监控磁盘使用情况，设置告警阈值。 避免在主库频繁执行大事务，否则会产生大量日志并导致从库延迟。4. 安全与备份策略
二进制日志可用于时间点恢复（PITR），应纳入备份体系。
定期备份二进制日志，尤其是变更密集期间。 结合mysqldump或Percona XtraBackup进行全量+增量恢复设计。 确保日志存储路径有足够权限和磁盘空间。基本上就这些。合理配置自动清理策略，加上定期监控，能有效控制主从复制日志的规模和风险。
