MySQLが「No space left on device」で止まったとき — binlogをrmで消してはいけない

公開 2026-10-25 ／ 更新 2026-10-25 ／ 文：ランツ

先に結論

ログにこう出ていたら、ディスクが満杯です。

Error writing file '/var/run/mysqld/mysqld.pid' (Errcode: 28 - No space left on device)
Can't start server: can't create PID file: No space left on device

まず知っておくべきことは、「運用中に満杯になった」のと「満杯の状態で起動しようとした」のでは、 MySQLの振る舞いが違うということです。

手順は上から順にやります。

MySQLは即死しない

1分ごとに確認して待つ

運用中のMySQLがディスク満杯に遭遇したときの挙動は、公式マニュアルに書かれています。 想像よりずっと粘ります。

つまり、慌てて再起動する必要はありません。 空きを作れば、1分以内に自分で気づいて続行します。

公式はもう1つ、実務で効くことを書いています。 ディスク満杯を引き起こしているスレッドをkillすれば、待たされていた他のスレッドは続行できます。 全体が止まって見えても、原因は1つのクエリであることがあります。

ただし起動はできない

ここが分かれ目です。 運用中なら待ちますが、満杯の状態から起動しようとすると失敗します。 起動時にPIDファイルを書く必要があり、それすら書けないからです。

何が食っているか調べる

闇雲に消さないでください。上から順に見れば数分で分かります。

# 1. どのパーティションが満杯か
df -h

# 2. データディレクトリの中で何が大きいか
du -sh /var/lib/mysql/* | sort -rh | head -20

# 3. バイナリログの合計サイズ
du -ch /var/lib/mysql/binlog.* 2>/dev/null | tail -1

# 4. MySQLから見たバイナリログの一覧
mysql -e "SHOW BINARY LOGS;"

df と du の数字が合わないときは、削除済みだがプロセスが掴んでいるファイルがあります。 lsof +L1 で見つかります。その場合、プロセスを再起動しないと空きが戻りません。

たいていバイナリログ

「何もしていないのにディスクが埋まった」の正体は、ほぼこれです。 バイナリログは更新のたびに書かれ続け、設定しない限り自動では消えません。

正しい消し方

MySQLの文から消します。公式の構文はこうです。

PURGE BINARY LOGS { TO 'log_name' | BEFORE datetime_expr }

-- 一覧を見てから
SHOW BINARY LOGS;

-- 指定したファイルより前を消す
PURGE BINARY LOGS TO 'binlog.000123';

-- 3日より前を消す
PURGE BINARY LOGS BEFORE DATE_SUB(NOW(), INTERVAL 3 DAY);

この文が大事なのは、インデックスファイルも一緒に更新してくれるからです。 公式はこう書いています。 「削除されたログファイルはインデックスファイルのリストからも取り除かれ、 指定したログファイルがリストの先頭になります」。

rmで消してはいけない

検索すると「rm で古いバイナリログを消す」という手順が出てきます。 MySQL公式は、これをはっきり警告しています。

つまり「消して終わり」になりません。 インデックスファイルと実体がずれた状態になり、次に PURGE しようとすると失敗します。 復旧には、インデックスファイルを手で編集する作業が増えます。

レプリカがある場合

レプリケーションを組んでいるなら、バイナリログはレプリカが読むためのものです。 消す前に、まだ読まれていないかを確認する必要があります。

公式の記述は2段構えです。

バイナリログ以外

binlogを消しても足りないとき、次に疑うものです。

2行目は見落とされます。 ログファイルを rm しても、MySQLは開いたままのファイルに書き続けます。 df の空きが戻りません。退避したら FLUSH LOGS で開き直させてください。

1行目も重要です。ibdata1 は一度膨らむと縮みません。 緊急時の選択肢にはなりません。落ち着いてから、別の作業として計画してください。

二度と起こさない

空きを作って終わりにすると、また同じことが起きます。 バイナリログは放っておけば増え続けるものだからです。

公式によれば、保持期間の既定は30日です。これを短くします。

-- いまの設定を見る
SHOW VARIABLES LIKE 'binlog_expire_logs_seconds';

-- 3日にする（再起動まで有効）
SET GLOBAL binlog_expire_logs_seconds = 259200;

# 設定ファイルにも書いて、再起動後も効くようにする
[mysqld]
binlog_expire_logs_seconds = 259200

3行目が本命です。 この問題は予告なく起きるのではなく、何週間もかけてじわじわ埋まっていきます。 使用率のグラフを見ていれば、必ず事前に気づけます。

AIに任せるときの注意

判定の目安です。答えに rm でバイナリログを消す手順が出てきたら、そのまま実行しないでください。 PURGE BINARY LOGS になっていれば正しい手順です。

よくある質問

MySQLが止まったので再起動していいですか

まだ動いているなら、止めないでください。 公式によれば、運用中のMySQLは1分ごとに空きを確認して待ちます（詳しく）。 満杯のまま止めると、今度は起動できなくなります（表4）。

バイナリログを rm で消してはいけませんか

いけません。公式が「手動削除はエラーにつながる可能性がある」と明記しています（詳しく）。 インデックスファイルとずれて、次の PURGE が失敗します。 PURGE BINARY LOGS を使ってください。

すでに rm してしまいました

インデックスファイルを編集して、実際に存在するファイルだけを記載した状態にしてから、 PURGE を実行し直す必要があります（公式の記述）。 レプリカがあるなら、必要なログを消していないかも確認してください。

ログを消したのに df の空きが戻りません

MySQLがファイルを開いたまま書き続けています（表9）。 lsof +L1 で削除済みの使用中ファイルが見つかります。 テキストログなら FLUSH LOGS で開き直させてください。

ibdata1 が巨大です

一度膨らむと縮みません（表9）。 縮めるにはダンプして入れ直すしかなく、緊急時にやる作業ではありません。 まずバイナリログで空きを作ってください。

保持期間はどれくらいにすべきですか

公式は「レプリカの最大の遅延時間を考慮して設定すべき」としています（詳しく）。 既定は30日です。レプリカが無いなら短くできますが、 障害復旧にバイナリログを使う運用なら、バックアップの間隔より短くしないでください。

バイナリログを無効にしてもいいですか

レプリカもポイントインタイムリカバリも使わないなら選択肢ですが、 「最後のバックアップ以降」を復元できなくなります（表10）。 容量対策としては、保持期間を短くするのが先です。

一部のクエリだけ止まっているように見えます

公式によれば、ディスク満杯を引き起こしているスレッドをkillすれば、 待たされていた他のスレッドは続行できます（表3）。 全体が止まったように見えても、原因は1つのクエリのことがあります。

まとめ

• 運用中のMySQLは即死しない。公式によれば1分ごとに空きを確認して待ち、10分ごとに警告を書く。
• だから、まず止めない。動いたまま空きを作れば、1分以内に自動で続行する。
• 満杯のまま再起動すると起動できなくなる。PIDファイルすら書けない。一番やってはいけない順番。
• 調べる順番は df → du → SHOW BINARY LOGS。闇雲に消さない。
• たいていバイナリログ。設定しない限り自動では消えない。既定の保持期間は30日。
• rm で消してはいけない。公式が警告している。インデックスファイルとずれて次の PURGE が失敗する。
• 消すのは PURGE BINARY LOGS。インデックスファイルも一緒に更新される。
• レプリカが切断中にパージすると、再接続後に復旧できない。警告も出ない。
• ibdata1 は縮まない。緊急時の選択肢ではない。
• 再発を止めるのは binlog_expire_logs_seconds と監視。じわじわ埋まるので、必ず事前に気づける。