MariaDBが突然落ちた時の原因と復旧手順｜Zabbix・Webサーバ影響も含めて解説

2018.10.31

MariaDBが落ちると何が起きるのか

MariaDBは多くのシステムで「心臓部」のような役割を持っています。

Zabbix、WordPress、業務システムなどが依存しているため、MariaDBが停止すると一気に影響が広がります。

よくある症状は以下です。

・Webサイトが表示されない
・Zabbixが監視停止
・アプリケーションエラー発生
・DB接続エラーが大量発生

まずは「落ちた原因」を冷静に切り分けることが重要です。

最初に確認すべきはサービス状態

MariaDBが本当に停止しているか確認します。

systemctl status mariadb

または環境によっては

systemctl status mysqld

ここで「failed」や「inactive」になっていれば停止状態です。

まずはログを確認するのが最優先

MariaDBはログにほぼすべての原因が残ります。

確認場所はこちら。

/var/log/mariadb/mariadb.log

または

/var/log/mysql/error.log

よくあるエラー例：

InnoDB: Unable to lock ./ibdata1

→ ディスク問題やクラッシュ後のロック残り

Out of memory

→ メモリ不足

Disk full

→ ディスク容量不足

まずはここを見れば、原因の8割は特定できます。

ディスク容量不足は最も多い原因

MariaDB停止の一番多い原因はこれです。

確認コマンド：

df -h

特に注意すべきは以下の領域です。

・/var
・/var/lib/mysql
・/tmp

ログ肥大化やバックアップ失敗で簡単に埋まります。

不要ファイル削除だけで復旧するケースも多いです。

メモリ不足による強制停止

サーバのメモリが足りない場合、OSがプロセスを強制終了することがあります。

確認：

free -m

ログに以下が出ていればほぼ確定です。

Killed process xxxx (mysqld)

対策としては以下：

・swap追加
・バッファサイズ見直し
・他プロセスの停止

InnoDB破損の可能性

MariaDBが強制終了した場合、InnoDBが壊れることがあります。

典型例：

InnoDB: corruption detected

この場合は慎重に対応が必要です。

まずは起動オプションで復旧モードを試します。

innodb_force_recovery=1

※数値は状況に応じて上げていく

1 → 6 の順で段階的に試します。

データ救出優先で対応します。

PIDファイルやソケット残り問題

異常終了後によくあるパターンです。

症状：

・起動しないのにプロセスはない
・socketエラー

対応：

rm -f /var/run/mariadb/mariadb.pid
rm -f /var/lib/mysql/mysql.sock

その後再起動。

systemctl restart mariadb

権限・設定ファイルのミス

設定変更後に落ちる場合はここです。

/etc/my.cnf

よくあるミス：

・全角スペース混入
・パス誤り
・バッファサイズ過大設定
・ポート競合

特にバッファを盛りすぎると起動できません。

復旧後に必ずやるべき確認

復旧した後はそのまま使うのではなく確認が必要です。

mysqlcheck -u root -p --all-databases

またログ監視も必須です。

tail -f /var/log/mariadb/mariadb.log

再発防止のためにも、ここは必ず実施します。

まとめ

MariaDBが落ちたときは、原因の多くが以下に集約されます。

・ディスク容量不足
・メモリ不足
・InnoDB破損
・設定ミス
・強制終了後の残骸

特に重要なのは「ログ確認」です。

いきなり再インストールするのではなく、

/var/log/mariadb/

を見れば、ほぼ原因は特定できます。

DB障害はシステム全体に波及するため、日常的な監視と容量管理が再発防止の鍵になります。

コメントを残すコメントをキャンセル

このサイトはスパムを低減するために Akismet を使っています。コメントデータの処理方法の詳細はこちらをご覧ください。

ワイズリマインダー