症状

MySQLのバイナリログ（binlog）がディスク容量を圧迫し、ディスクフルまたは空き容量不足が発生する。

結論：まずこれを確認

  1. SHOW BINARY LOGS; でバイナリログのサイズと数を確認する
  2. レプリケーション使用中なら SHOW SLAVE STATUS; でスレーブの読み取り位置を確認する
  3. 不要なログを PURGE BINARY LOGS で削除する

トラブルシューティングフロー

    flowchart TD
    A[ディスク容量不足を検知] --> B{バイナリログが原因?}
    B -->|Yes| C{レプリケーション使用中?}
    B -->|No| Z[他の原因を調査]
    C -->|Yes| D[スレーブの読み取り位置を確認]
    C -->|No| E[expire_logs_days設定を確認]
    D --> F{スレーブが遅延している?}
    F -->|Yes| G[スレーブ遅延を解消]
    F -->|No| H[安全にPURGE可能]
    E --> I[保持期間を設定]
    G --> H
    I --> H
    H --> J[PURGE BINARY LOGSを実行]

よくある原因

  • expire_logs_days / binlog_expire_logs_seconds が未設定 — バイナリログが自動削除されない
  • レプリケーションスレーブの遅延 — スレーブが読み終わるまでログを保持し続ける
  • 大量のDML実行 — INSERT/UPDATE/DELETEが多いとログが急速に肥大化する
  • binlog_format=ROW での大規模更新 — 行単位で記録されるためログサイズが増大する
  • 長期間のメンテナンス放置 — 定期的なログ削除が行われていない
  • バックアップツールがログを保持 — mysqlbinlogやバックアップソフトがログを参照中

確認手順

ステップ1: バイナリログの状態を確認する

    mysql -u root -p -e "SHOW BINARY LOGS;"

🔍 チェックポイント: ログファイルの数と各ファイルのサイズを確認する。合計サイズがディスク使用量と一致するか確認する。

ステップ2: 現在のバイナリログ設定を確認する

    mysql -u root -p -e "SHOW VARIABLES LIKE '%binlog%';"
mysql -u root -p -e "SHOW VARIABLES LIKE 'expire_logs%';"

🔍 チェックポイント: expire_logs_days または binlog_expire_logs_seconds が 0 の場合、自動削除が無効になっている。

ステップ3: レプリケーション状態を確認する（使用中の場合）

    mysql -u root -p -e "SHOW SLAVE STATUS\G"

🔍 チェックポイント: Relay_Master_Log_File と Exec_Master_Log_Pos でスレーブがどのログまで読んでいるか確認する。

ステップ4: 削除可能なログを特定する

    mysql -u root -p -e "SHOW MASTER STATUS;"

🔍 チェックポイント: 現在書き込み中のログファイル名を確認する。これより古いログが削除候補。

ステップ5: バイナリログを削除する

    # 特定の日時より前のログを削除
mysql -u root -p -e "PURGE BINARY LOGS BEFORE '2026-01-10 00:00:00';"

# または特定のファイルより前を削除
mysql -u root -p -e "PURGE BINARY LOGS TO 'mysql-bin.000100';"

🔍 チェックポイント: 削除後に SHOW BINARY LOGS; で残りのログを確認する。

ステップ6: 自動削除を設定する

    # my.cnf に追加（7日で自動削除）
# expire_logs_days = 7

# MySQL 8.0以降の場合
mysql -u root -p -e "SET GLOBAL binlog_expire_logs_seconds = 604800;"

🔍 チェックポイント: 設定変更後、SHOW VARIABLES LIKE 'expire_logs%'; で反映を確認する。

NG行動（やってはいけないこと）

  • バイナリログファイルを直接 rm で削除する — MySQLのインデックスと不整合が起きてレプリケーションが壊れる可能性がある
  • レプリケーションスレーブの読み取り位置を確認せずにPURGEする — スレーブが必要なログを削除するとレプリケーションが停止する
  • binlog を無効化する（log_bin=OFF） — ポイントインタイムリカバリができなくなる
  • expire_logs_days を極端に短く設定する — 障害発生時のリカバリに必要なログが失われる

よくある質問（FAQ）

Q1: PURGE中にMySQLを再起動しても大丈夫？

A: PURGE操作は即座に完了するため、通常は再起動の必要はない。ただし、削除中に再起動するとインデックスファイルが不整合になる可能性がある。

Q2: バイナリログを完全に無効化するには？

A: my.cnf で skip-log-bin または disable-log-bin を設定する。ただしレプリケーションとポイントインタイムリカバリが使用できなくなる。

Q3: どのくらいの保持期間が適切？

A: 環境による。レプリケーション遅延の最大許容時間＋バックアップ間隔を考慮する。一般的には3〜14日程度。

関連するエラー・症状

準備中

解決しない場合

  • MySQL公式ドキュメント: The Binary Log
  • 確認すべきログ: MySQLエラーログ（/var/log/mysql/error.log または datadir 配下）
  • 次に調べるキーワード: mysql binlog purge safe, mysql replication lag, mysql disk full recovery