binlog 保留期为什么重要
MySQL 的 binlog 会按保留期自动过期删除，由 binlog_expire_logs_seconds 控制（MySQL 8.0 默认 2592000 秒，即 30 天），旧的 expire_logs_days 参数已经弃用。对 CDC 链路来说，保留期就是「允许落后多久」的硬边界：消费位点一旦落在最早 binlog 文件之前，链路就再也追不回来，只能重做全量快照。
基本信息
| 控制参数 | binlog_expire_logs_seconds，MySQL 8.0 默认 2592000 秒（30 天） |
|---|---|
| 旧参数 | expire_logs_days 已弃用，不要再依赖 |
| 安全值估算 | 约等于最长回追时长乘 2，并覆盖节假日无人值守窗口 |
| 监控建议 | 同时监控保留余量与消费位点滞后 |
典型使用场景
- 新建 CDC 链路：先确认源库保留期能否覆盖演练与故障窗口
- 故障复盘：评估位点滞后多久会撞上清理边界
- 容量权衡：保留期越长占盘越多，需要结合磁盘量平衡
- 节假日值守：无人值守窗口长，节前确认保留余量充足
- 巡检：把最早 binlog 时间与当前时间之差纳入监控
查看与调整保留期
查看与调整保留期
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds'; -- 查看当前保留期（秒）
-- 临时改为 7 天（604800 秒）
SET GLOBAL binlog_expire_logs_seconds = 604800;
-- 持久化，避免重启后回退
SET PERSIST binlog_expire_logs_seconds = 604800;
SHOW BINARY LOGS; -- 查看当前保留的日志文件与最早时间点参数与影响
| 项 | 含义 | 注意点 |
|---|---|---|
| binlog_expire_logs_seconds | 自动过期秒数 | 8.0 默认 30 天 |
| expire_logs_days | 旧参数（已弃用） | 新版本不应再使用 |
| SET GLOBAL | 临时生效 | 重启后失效 |
| SET PERSIST | 写入 mysqld-auto.cnf | 重启后仍然生效 |
| SHOW BINARY LOGS | 当前文件清单 | 可用于判断最早可用位点 |
用 SET GLOBAL 改的参数重启后会失效：要么 SET PERSIST，要么写回配置文件，否则会出现「改过但没生效」的假象，故障时才发现保留期还是旧值。
保留期太长占磁盘，太短会让 CDC 失去追平机会。安全下限的算法很朴素：最长回追时长乘以 2，再叠加节假日无人值守窗口，而不是按平时的平均延迟来定。
保留余量的观察方式很直接：用最早 binlog 文件的写入时间与当前时间相减，得到的就是「还能容忍落后多久」。把这个差值与位点滞后一起打点，比只看磁盘使用率更能提前预警。