主库通过binlog记录数据变更，从库用中继日志回放实现复制。配置binlog_expire_logs_seconds和max_binlog_size控制日志保留与大小，启用relay_log_purge和relay_log_recovery保障从库日志安全清理与崩溃恢复。定期执行SHOW BINARY LOGS和SHOW SLAVE STATUS监控日志状态与复制延迟，结合备份策略进行PITR恢复设计，避免大事务导致日志膨胀和同步延迟。

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：单个日志文件最大大小，到达后自动切换到下一个文件。

可通过以下命令手动清理过期日志：

2. 从库中继日志管理

从库通过I/O线程读取主库的二进制日志并写入中继日志（Relay Log），再由SQL线程回放。

相关配置：

• relay-log = /path/to/relay-bin：指定中继日志文件名前缀。
• relay_log_purge = ON：自动在SQL线程执行完后清除已使用的中继日志（默认开启）。
• relay_log_recovery = ON：崩溃后从主库重新获取中继日志，保证一致性，建议在高可用环境中启用。

若需手动清理中继日志，可执行：

3. 监控与维护建议

定期检查日志状态，避免磁盘空间耗尽或复制延迟。

• 查看主库二进制日志列表：SHOW BINARY LOGS;
• 查看从库中继日志状态：SHOW SLAVE STATUS\G，关注Relay_Log_Space和Seconds_Behind_Master。
• 监控磁盘使用情况，设置告警阈值。
• 避免在主库频繁执行大事务，否则会产生大量日志并导致从库延迟。

4. 安全与备份策略

二进制日志可用于时间点恢复（PITR），应纳入备份体系。

• 定期备份二进制日志，尤其是变更密集期间。
• 结合mysqldump或Percona XtraBackup进行全量+增量恢复设计。
• 确保日志存储路径有足够权限和磁盘空间。

基本上就这些。合理配置自动清理策略，加上定期监控，能有效控制主从复制日志的规模和风险。