現象與風險

/var/lib/mysql/ 下出現大量 mysql-bin.000001、mysql-bin.000002... 檔案，單檔可達 GB 級，總量遠超資料本身，導致 df -h 顯示磁碟 98%+ 滿載。

安全清理方式（推薦）

1. 透過 SQL 指令清理（保留從庫同步需求）

mysql -u root -p
mysql> PURGE BINARY LOGS BEFORE '2023-01-01 00:00:00';
# 或保留最近 N 天
mysql> PURGE BINARY LOGS TO 'mysql-bin.000050';

優點： 自動更新索引檔，不會損壞複寫。

2. 重設主庫（僅限無從庫/測試環境）

mysql> RESET MASTER;

刪除所有 Binlog，重新從 mysql-bin.000001 開始。**會中斷所有從庫複寫**，謹慎使用。

自動過期配置（長效機制）

# /etc/my.cnf 或 /etc/mysql/my.cnf
[mysqld]
log_bin = mysql-bin
expire_logs_days = 7          # 自動清理 7 天前的 Binlog
max_binlog_size = 100M        # 單檔上限，防止單檔過大
binlog_expire_logs_seconds = 604800  # MySQL 8.0 替代參數（秒）

修改後 systemctl restart mysqld 生效。

徹底關閉 Binlog（非複寫環境）

# /etc/my.cnf
[mysqld]
# 註解或移除以下行
# log_bin = mysql-bin
# log-bin = mysql-bin

# 或顯式關閉（MySQL 8.0+）
disable_log_bin

重啟 MySQL 後生效。警告： 關閉 Binlog 將無法進行時間點恢復（PITR）與主從複寫。

Windows 環境操作

1. 以管理員身分開啟命令提示字元
2. mysql -u root -p
3. 執行 PURGE BINARY LOGS BEFORE '2023-01-01'; 或 RESET MASTER;
4. 修改 my.ini 註解 log-bin=mysql-bin
5. 重啟服務：net stop mysql & net start mysql

緊急磁碟滿載救援

# 1. 先停止寫入流量（應用層熔斷/維護模式）
# 2. 移動舊 Binlog 到其他磁碟（軟連結回來）
mv /var/lib/mysql/mysql-bin.00000* /mnt/backup_disk/
ln -s /mnt/backup_disk/mysql-bin.000001 /var/lib/mysql/mysql-bin.000001
# ... 依序建立軟連結

# 3. 或截斷當前寫入檔（極端情況）
> /var/lib/mysql/mysql-bin.000050  # 僅清空內容，保留 inode

# 4. 執行 PURGE BINARY LOGS 釋放空間
# 5. 恢復流量

最佳實踐清單

• 生產主庫**必須開啟 Binlog**（複寫、PITR、審計依賴）
• 設定 expire_logs_days = 7（或依備份策略調整）
• 監控 disk_usage 與 binlog_count，設定告警
• 定期驗證 SHOW BINARY LOGS 與 SHOW SLAVE STATUS 一致性
• 備份策略：全量備份 + Binlog 增量 = PITR 完整鏈路