MySQL Binlog 安全刪除指南：PURGE 語法詳解與主從環境下的最佳實踐

前言：為什麼要謹慎刪除 Binlog？

二進制日志是主從復制、時間點恢復的核心依據。隨意刪除會導致從庫斷檔、數據無法恢復。本文詳述 PURGE BINARY LOGS 正確用法，並給出生產環境標準操作流程（SOP）。

一、基礎語法與常用變體

-- 按日志文件名刪除（不含指定文件）
PURGE BINARY LOGS TO 'mysql-bin.000003';

-- 按時間點刪除（刪除指定時間之前的日志）
PURGE BINARY LOGS BEFORE '2024-01-15 10:00:00';

-- 同義詞：MASTER = BINARY
PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2008-06-22 13:00:00';

-- 動態時間：刪除 3 天前日志
PURGE MASTER LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY);

二、實戰演示：刪除前兩個 Binlog

-- 1. 查看現有日志
mysql> SHOW BINARY LOGS;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000001 | 150462942 |
| mysql-bin.000002 | 125       |
| mysql-bin.000003 | 106       |
+------------------+-----------+

-- 2. 刪除 000003 之前的日志
mysql> PURGE BINARY LOGS TO 'mysql-bin.000003';
Query OK, 0 rows affected (0.16 sec)

-- 3. 驗證結果
mysql> SHOW BINARY LOGS;
+------------------+-----------+
| Log_name         | File_size |
+------------------+-----------+
| mysql-bin.000003 | 106       |
+------------------+-----------+

三、主從環境下的黃金法則：刪除前必須確認從庫位置

鐵律： 若有活躍從庫正在讀取目標日志，PURGE 會報錯失敗；若從庫離線且其所需日志被刪，重啟後將無法復制。

標準 SOP 流程：

1. 每個從庫執行： SHOW SLAVE STATUS\G 記錄 Master_Log_File 和 Read_Master_Log_Pos
2. 主庫執行： SHOW BINARY LOGS 獲取完整日志列表
3. 判定目標日志： 所有從庫中 最早 正在讀取的日志文件 = 安全刪除界限（不含該文件）
4. 可選備份： 將待刪除日志文件備份至異地存儲
5. 執行清理： PURGE BINARY LOGS TO '目標日志文件名'

四、自動化清理策略（定時任務）

在主庫 crontab 配置：

# 每天凌晨 1 點清理 3 天前日志
0 1 * * * mysql -uroot -p'xxx' -e "PURGE MASTER LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY);"

前提： 確保所有從庫延遲 < 3 天，且有監控告警保障。

五、常見坑點提示

• expire_logs_days 參數：設置後 MySQL 啟動/刷新日志時自動清理，**但不保證實時生效**，建議配合手動/定時 PURGE 使用
• GTID 模式下：需確保刪除的日志不包含從庫所需的 GTID 事務，否則從庫報 ER_MASTER_HAS_PURGED_REQUIRED_GTIDS
• 不要手動 rm -f mysql-bin.*！會導致索引文件 mysql-bin.index 不一致，MySQL 拒絕啟動

六、總結

Binlog 清理三步走：**查從庫位置 → 定安全界線 → 執行 PURGE TO**。納入自動化運維體系，配合監控告警，才能在釋放磁碟空間與保障數據安全間取得平衡。