LNMP 環境下 MySQL Binlog 爆盤清理與禁用策略

現象與風險

現象：/usr/local/mysql/var/ 下 mysql-bin.000001 等二進制日志文件佔用 4GB+，導致磁盤空間不足，MySQL 拒絕寫入甚至崩潰。錯誤：ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.sock'（實際是磁盤滿導致 Socket 文件無法創建）。

緊急處理：清理現有 Binlog

# 1. 登錄 MySQL
mysql -u root -p

# 2. 查看當前 Binlog 列表
SHOW BINARY LOGS;

# 3. 安全清理：刪除指定文件之前的所有 Binlog（保留最新的從庫同步所需）
# 假設主從同步正常，從庫已處理到 mysql-bin.000010
PURGE BINARY LOGS TO 'mysql-bin.000010';

# 或按時間清理（保留 7 天內）
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 7 DAY);

# 4. 一鍵重置（僅限無主從同步、確認無恢復需求的單機環境）
RESET MASTER;
# 將刪除所有 Binlog，索引歸零為 mysql-bin.000001

根治方案：禁用或限制 Binlog

修改 /etc/my.cnf（或 /usr/local/mysql/etc/my.cnf）

[mysqld]
# 方案 A：完全禁用（單機、無主從、無增量備份需求）
# log-bin=mysql-bin
# binlog_format=mixed

# 方案 B：啟用但限制大小與保留天數（推薦，兼容主從/備份）
log-bin=mysql-bin
binlog_format=ROW          # ROW 格式兼容性最好，數據恢復精確
max_binlog_size=100M       # 單文件上限 100M，防止單文件過大
expire_logs_days=7         # 自動清理 7 天前的 Binlog
binlog_cache_size=4M       # 事務緩存，減少磁盤 IO
sync_binlog=1              # 每次提交刷盤，數據最安全（性能稍損，可設 100 折中）

修改後重啟：service mysqld restart 或 systemctl restart mysqld。

主從同步環境特殊注意

• 執行 PURGE BINARY LOGS 前，**務必確認所有從庫 SQL 線程已處理到目標位置** (SHOW SLAVE STATUS\G 中 Relay_Master_Log_File / Exec_Master_Log_Pos)。
• 建議在主庫設置 expire_logs_days=14，給從庫故障修復留足窗口期。
• 定期檢查 Seconds_Behind_Master=0，確保同步無延遲。

磁盤空間不足時的緊急騰挪

# 1. 臨時移動舊 Binlog 到掛載大磁盤的目錄
mkdir -p /data/mysql_binlog_archive
mv /usr/local/mysql/var/mysql-bin.00000[1-5]* /data/mysql_binlog_archive/

# 2. 創建軟鏈接指向新位置（MySQL 運行中不可移動當前寫入文件）
# 僅移動已歸檔（不再寫入）的文件

# 3. 長期解決：將 datadir 整體遷移到大磁盤分區
# 停庫 -> rsync -av /usr/local/mysql/var/ /data/mysql/ -> 修改 my.cnf datadir -> 啟庫

監控告警建議

# Zabbix / Prometheus 關鍵指標
mysql_binlog_size_bytes{instance="..."} > 10GB -> 告警
mysql_binlog_count > 1000 -> 告警
disk_usage_percent{mount="/var/lib/mysql"} > 80% -> 告警

總結

Binlog 爆盤本質是**生命周期管理缺失**。生產環境請遵循：**啟用 ROW 格式 + 限制單文件大小 + 設置過期天數 + 監控告警 + 定期主從同步校驗**。單機無備份場景可直接禁用；有主從/備份需求則必須精細化配置參數，並在架構層面規劃磁盤擴容策略。