蓝易云 - MySQL自动删除binlog日志

下面是一份生产可用、逻辑严谨、可直接照做的《MySQL 自动删除 binlog 日志完整方案》。内容按原理 → 风险 → 配置 → 验证 → 生产建议展开，不绕弯、不玄学，只讲真实可控的做法。

一、先说清楚：binlog 是什么？为什么一定要自动清理？ 🧠

binlog（二进制日志）记录的是 MySQL 中所有可能导致数据变更的操作，核心用途包括：

• 主从复制

• 数据恢复（基于时间点）

• 审计与问题回溯

但现实很残酷：

binlog 不会自动“无限智能增长”，磁盘是会被打爆的🔴

一旦磁盘写满，后果通常是：

• 数据库直接不可写

• 服务雪崩

• 容器 / 云盘异常

所以：自动删除 binlog 不是优化，是必需品。

二、binlog 自动删除的底层原理（必须理解）

MySQL 本身内置了 binlog 自动清理机制，核心控制参数只有一个：

binlog_expire_logs_seconds

其逻辑是：

当前时间 - binlog 创建时间 > 过期阈值 ↓ 自动清理

📌 注意一个关键点（非常重要）：

MySQL 只会删除“不再被复制线程需要”的 binlog🔴

三、强烈不推荐的做法（先排雷）

❌ 手动 rm binlog 文件

rm mysql-bin.000123

这是灾难级操作，原因如下：

• MySQL并不知道文件被删

• 主从复制会直接中断

• binlog index 会失效

👉生产环境严禁使用 rm 删除 binlog🔴

四、官方 & 正确方案一：自动过期清理（推荐）

1️⃣ 查看当前 binlog 过期配置

SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';

解释：

• 查看当前自动清理周期（单位：秒）

• 若值为0，表示不会自动删除

2️⃣ 设置 binlog 自动删除（在线生效）

示例：保留 7 天 binlog

SET GLOBAL binlog_expire_logs_seconds = 604800;

解释逐条说明：

• SET GLOBAL：即时生效，无需重启

• 604800= 7 × 24 × 3600

• 只影响新生成的 binlog

📌 这是MySQL 8.0+ 的标准做法🔴

3️⃣ 永久生效（写入配置文件）

在my.cnf中添加：

[mysqld] binlog_expire_logs_seconds = 604800

解释：

• 防止重启后配置丢失

• 属于生产环境必做项

五、方案二：旧版本 MySQL 的兼容方案

如果你使用的是较老版本（如 5.7），常见的是：

expire_logs_days = 7

对比说明表：

六、手动安全清理（应急用）

当磁盘已经告急，可使用MySQL 内置命令：

PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;

解释：

• 由 MySQL 自己判断可删除范围

• 不破坏复制结构

• 比 rm 安全 100 倍 🔴

⚠️ 指定 binlog 文件名清理（谨慎）

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

含义：

• 删除000456 之前的所有 binlog

• 常用于主从已确认同步完成后

七、binlog 自动清理的完整工作流程（流程图）

写入 binlog ↓ binlog 达到过期时间 ↓ MySQL 检查复制位点 ↓ 确认不再需要 ↓ 安全删除

八、生产环境推荐参数组合（实话实说）

🔴 单机 / 无主从

binlog_expire_logs_seconds = 259200

• 保留 3 天

• 防止误操作无恢复空间

🔴 主从 / 云数据库

binlog_expire_logs_seconds = 604800

• 保留 7 天

• 覆盖复制延迟、运维窗口

🔴 高写入 / 高并发场景

• 缩短保留时间

• 同时监控磁盘水位

• 禁止无限增长

九、常见误区总结（非常重要）

十、核心结论（直击重点）

• binlog必须自动清理 🔴

• 使用 MySQL 官方机制，不是脚本乱删

• 设置 + 验证 + 监控，三者缺一不可

• binlog 问题，不是技术难，是态度问题

如果你愿意，下一步我可以直接帮你：

• 🔍 设计binlog + 备份 + 恢复完整策略

• 🛡️ 针对主从 / 高防节点 / 容器环境定制方案

• 📊 给你一套磁盘 & binlog 预警阈值模型

这种基础问题，解决一次，就不该再出事故。