MySQL

MySQL binlog 保留时间与清理

·6 分钟阅读·2210 字

说明 MySQL binlog 保留策略、自动清理、手动清理和主从复制场景下的风险控制

📋 目录

MySQL binlog 保留时间与清理

核心定义 binlog 是 MySQL 记录数据变更的二进制日志,常用于主从复制、增量恢复和审计。binlog 清理策略需要同时兼顾磁盘空间、主从延迟和时间点恢复能力。

1. binlog 的作用

binlog 主要用于三类场景:

  1. 主从复制:从库通过主库 binlog 拉取并重放事务。
  2. 时间点恢复:全量备份结合 binlog 恢复到指定时间点。
  3. 审计与同步:数据同步工具通过 binlog 捕获变更事件。

如果 binlog 保留时间过短,可能导致从库断点无法追上,或备份恢复无法覆盖目标时间点。

2. 查看 binlog 配置

SHOW VARIABLES LIKE 'log_bin';
SHOW VARIABLES LIKE 'binlog_format';
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';
SHOW VARIABLES LIKE 'expire_logs_days';

MySQL 8.0 推荐使用:

SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';

旧版本常见参数是:

SHOW VARIABLES LIKE 'expire_logs_days';

3. 自动保留时间配置

MySQL 8.0 推荐按秒设置保留时间:

[mysqld]
log_bin=mysql-bin
binlog_format=ROW
binlog_expire_logs_seconds=604800

604800 秒等于 7 天。

常见保留策略:

场景建议保留时间原因
普通测试环境1-3 天节省磁盘空间
普通生产环境7-14 天覆盖常见恢复窗口
强恢复要求环境14-30 天支持更长 PITR 窗口
大延迟从库环境大于最大延迟时间避免从库所需日志被清理

4. 手动清理 binlog

4.1. 按文件清理

PURGE BINARY LOGS TO 'mysql-bin.000120';

含义:删除 mysql-bin.000120 之前的 binlog,不包括该文件。

4.2. 按时间清理

PURGE BINARY LOGS BEFORE '2026-08-01 00:00:00';

含义:删除指定时间之前的 binlog。

清理前必须确认复制状态 主从环境中手动清理 binlog 前,应确认所有从库都已经执行完待清理范围,否则可能导致从库报错:主库缺少所需 binlog。

5. 主从复制场景风险

从库依赖主库 binlog 继续复制。如果从库延迟较大,而主库提前清理了对应 binlog,从库会无法继续追赶。

常见报错方向:

Could not find first log file name in binary log index file
The source has purged binary logs containing GTIDs that the replica requires

GTID 复制下,需要重点比较:

SELECT @@GLOBAL.gtid_executed;
SELECT @@GLOBAL.gtid_purged;

如果从库缺失的 GTID 已经包含在主库 gtid_purged 中,通常需要重新搭建从库或寻找仍保留日志的实例。

6. 磁盘空间排查

查看 binlog 文件:

SHOW BINARY LOGS;

在系统层查看大小:

ls -lh /var/lib/mysql/mysql-bin.*
du -sh /var/lib/mysql

如果 binlog 增长异常,应排查:

  1. 是否存在大事务。
  2. 是否存在批量更新或删除。
  3. binlog 格式是否为 ROW,导致记录大量行变更。
  4. 清理策略是否未生效。
  5. 是否有从库延迟导致不敢清理。

7. 生产建议

  • 开启 binlog 前确认磁盘容量和保留策略。
  • 保留时间必须覆盖全量备份周期和恢复窗口。
  • 主从环境清理前确认所有从库复制状态正常。
  • 对关键业务保留至少 7 天以上 binlog。
  • 配置磁盘监控,避免 binlog 打满数据盘。
  • 定期演练全量备份 + binlog 的时间点恢复。

8. 面试回答模板

标准回答 MySQL binlog 用于主从复制和时间点恢复,清理策略需要平衡磁盘空间与恢复能力。MySQL 8.0 推荐使用 binlog_expire_logs_seconds 控制自动过期,也可以通过 PURGE BINARY LOGS 手动清理。生产环境清理前必须确认从库已执行完对应日志范围,否则从库可能因为主库 binlog 被清理而无法继续复制。GTID 场景下还需要关注 gtid_executed 和 gtid_purged,如果从库缺失的 GTID 已经被主库 purged,通常需要重建从库或寻找其他日志源。


关联文档

Yanche Blog

记录云原生、Linux、数据库等技术领域的学习心得,以及日常生活的思考与感悟。

© 2026 Yanche Blog. All rights reserved.

Powered by Astro