MySQL Binlog 安全清理策略：從自動過期到主從環境下的精準 Purge

為什麼要管理 Binlog

開啟 log_bin 後，MySQL 會在數據目錄持續生成 mysql-bin.XXXXXX 文件。若不加控制，將佔滿磁盤導致實例掛起，甚至引發主從同步中斷。生產環境必須建立「自動過期 + 手動精準清理」的雙重保障機制。

場景一：單實例、無主從、不依賴 Binlog 恢復

直接關閉 Binlog 功能：

# /etc/my.cnf
# 注釋或刪除以下行
# log-bin=mysql-bin
# 重啟生效

場景二：單實例、需保留 Binlog 用於時間點恢復 (PITR)

配置自動過期清理（單位：天）：

[mysqld]
expire_logs_days = 7   # 僅保留最近 7 天，舊文件自動刪除
# MySQL 8.0+ 推薦使用
binlog_expire_logs_seconds = 604800

配合 max_binlog_size (默認 1GB) 控制單文件大小，防止單文件過大難以傳輸解析。

場景三：緊急清空所有 Binlog（謹慎！不可逆）

RESET MASTER;

警告：此命令會刪除所有 Binlog 並重置索引至 mysql-bin.000001，會導致現有從庫同步中斷，嚴禁在有從庫的主庫執行。

場景四：主從架構下的精準清理（核心技能）

核心原則：只能刪除「所有從庫已同步」的 Binlog。

步驟 1：在從庫確認同步位點

SHOW SLAVE STATUS\G
# 關鍵字段
Master_Log_File: mysql-bin.000009
Read_Master_Log_Pos: 123456

步驟 2：在主庫按文件名清理

-- 刪除 mysql-bin.000009 之前的所有文件 (保留 000009 及之後)
PURGE MASTER LOGS TO 'mysql-bin.000009';

步驟 3：或按時間點清理

-- 刪除 2024-11-18 00:00:00 之前的所有文件
PURGE MASTER LOGS BEFORE '2024-11-18 00:00:00';

最佳實踐清單

總結

Binlog 管理的核心是「知曉從庫同步進度，再精準清理」。建立 expire_logs_days 自動保護線，掌握 PURGE MASTER LOGS TO/BEFORE 手動手術刀，才能在磁盤空間與數據安全之間游刃有餘。