MySQL Binary Log 清理實務：PURGE BINARY LOGS 安全操作指南

操作前提

• 確認主從複製正常，Slave 已應用欲刪除的 binlog 事件
• 備份重要 binlog（如需時間點恢復）

標準清理流程

1. 查看當前 binlog 狀態

   SHOW MASTER STATUS;
   +------------------+----------+--------------+------------------+
   | File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
   +------------------+----------+--------------+------------------+
   | mysql-bin.000795 | 123456   |              |                  |
   +------------------+----------+--------------+------------------+

2. 確認 Slave 進度（在每個 Slave 執行）

   SHOW SLAVE STATUS\G
   Master_Log_File: mysql-bin.000790
   Read_Master_Log_Pos: 98765
   Exec_Master_Log_Pos: 98765

   確保所有 Slave 的 Exec_Master_Log_Pos 已超過將要刪除的檔案位置。

3. 執行清理（刪除 mysql-bin.000795 之前的所有 binlog）

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

4. 驗證結果

   SHOW BINARY LOGS;
   +------------------+-----------+
   | Log_name         | File_size |
   +------------------+-----------+
   | mysql-bin.000795 | 12345678  |
   | mysql-bin.000796 |  5678901  |
   +------------------+-----------+

自動化清理策略（生產建議）

1. 配置 expire_logs_days

[mysqld]
expire_logs_days = 7  -- 自動清理 7 天前的 binlog

動態生效：SET GLOBAL expire_logs_days = 7;

2. 結合備份策略

• 全量備份完成後，記錄備份時刻對應的 binlog 位置
• 僅清理「已確認全量備份包含」且「所有 Slave 已應用」之前的 binlog

注意事項

• 切勿手動刪除 /var/lib/mysql/mysql-bin.* 檔案，會導致 mysql-bin.index 索引不一致，引發啟動失誤。
• PURGE BINARY LOGS TO 會同步更新 index 檔案，保證一致性。
• 若啟用 GTID，清理前確認 gtid_purged 不會遺漏 Slave 所需事務。
• 大量清理可能觸發檔案系統鎖競爭，建議低峰期執行。