LinuxでMySQLが起動しない時の解決法

こんにちは、AIシステムズです。
この記事は、代表コバが現場で対応してきたLinuxサーバー運用の知見をもとに、AIを活用して構成・執筆し、弊社にて最終チェックを行ったものです。

「MySQL/MariaDBを起動しようとするとエラーで止まる」「サーバー再起動後にDBが上がってこない」「systemctl restart が失敗する」——Linuxサーバー運用で最も焦るトラブルのひとつです。原因はディスク容量・権限・設定ファイルの構文ミス・InnoDBの破損の4種類に集約されます。

• MySQLが起動しない主要原因
• ログを読んで原因を特定する方法
• ディスク容量・パーミッションの確認
• InnoDB破損からの復旧手順
• 再起動後の自動起動設定

目次

1. MySQLが起動しないときの切り分け順
2. エラーログの読み方
3. 原因別の対処
4. InnoDB破損からの復旧
5. こういうサーバーに向いている／向いていない
6. 再発防止チェックリスト

MySQLが起動しないときの切り分け順

焦って systemctl restart を繰り返す前に、次の順で原因を特定します。

1. サービスの状態詳細を確認：systemctl status mysqld -l
2. MySQLのエラーログを確認：/var/log/mysqld.log または /var/log/mysql/error.log
3. ディスク容量を確認：df -h
4. データディレクトリのパーミッションを確認：ls -ld /var/lib/mysql
5. 設定ファイルの構文確認：mysqld --validate-config

この順で見るだけで、9割のケースで原因が特定できます。

エラーログの読み方

弊社の現場でよく見る典型的なエラーメッセージと意味は次のとおりです。

• Disk is full writing：ディスク容量不足
• Can't create/write to file：パーミッションまたはディスク容量
• InnoDB: Unable to lock ./ibdata1：別のmysqldが残っている、または前回異常終了の名残
• unknown variable：my.cnfに無効なオプションが書かれている
• InnoDB: Database page corruption：InnoDBのファイル破損
• Failed to start MySQL Server だけが出るときは、別ログ（journal）に詳細

journalctl -u mysqld -n 100 --no-pager

原因別の対処

ディスク容量不足

df -h
du -sh /var/lib/mysql/* | sort -h | tail -10
du -sh /var/log/* | sort -h | tail -10

古いバイナリログや一般ログがディスクを食い潰しているケースが多いです。

mysql -e "PURGE BINARY LOGS BEFORE NOW() - INTERVAL 7 DAY;"  # MySQLが起動できるなら
# 起動できないなら手動で古いログを削除（ibdata1等は触らない）

パーミッション

sudo chown -R mysql:mysql /var/lib/mysql
sudo chmod 750 /var/lib/mysql

バックアップから戻したり、ファイル操作した直後はパーミッションが崩れがちです。

my.cnfの構文ミス

mysqld --validate-config

直前に編集した行をコメントアウトして起動を試します。innodb_buffer_pool_size を大きく取りすぎてOOMで落ちているケースも多いです。

ロック残り（PIDファイル）

sudo rm /var/run/mysqld/mysqld.pid
sudo rm /var/lib/mysql/aria_log_control  # MariaDBで異常終了後

プロセスが存在しないことを ps aux | grep mysql で確認してから削除します。

InnoDB破損からの復旧

InnoDB: Database page corruption が出る場合、最後の手段としてリカバリモードで起動します。my.cnfに次を追加。

[mysqld]
innodb_force_recovery = 1

1〜6まで段階があり、まず1で起動を試み、ダメなら数字を1ずつ上げます。起動できたら全データをmysqldumpで吸い出し、新規データディレクトリへリストアします。innodb_force_recovery のまま運用してはいけません。

mysqldump --all-databases --single-transaction --routines --triggers > rescue.sql

日次バックアップがあれば、破損したデータからの救出よりバックアップからの復元のほうが圧倒的に早く、安全です。

再起動後の自動起動設定

sudo systemctl enable mysqld
sudo systemctl is-enabled mysqld   # enabled なら自動起動

こういうサーバーに向いている／向いていない

この復旧手順は、中小企業の自社サーバーやVPSで運用しているMySQL/MariaDBサーバーに直接適用できます。マネージドDB（RDS、CloudSQL等）の場合は、これらの操作はAWS/GCPコンソール経由で完結し、運用負担は大幅に軽減されます。事業継続性が重要な場合はマネージドDBへの移行も選択肢です。

再発防止チェックリスト

• ディスク容量を監視し、80%超えでアラートを出しているか
• 日次でDBバックアップを取得し、定期的にリストア検証しているか
• my.cnfの変更前後で差分管理しているか
• バイナリログ・一般ログのローテーションを設定しているか
• 自動起動が有効になっているか

まとめ

MySQLが起動しないときは、エラーログを読まずに restart を繰り返すと状況が悪化します。journalctl + エラーログ + df -h + パーミッション確認の4点をルーチンにすれば、復旧時間が大きく短縮されます。

本記事は、代表コバが中小企業のLinuxサーバー運用の現場で対応してきた知見をもとに、AIを活用して構成・執筆し、弊社にて最終確認を行っています。サーバー保守、DB運用設計、マネージドDBへの移行支援について、具体的な状況をふまえた相談を承っています。費用感だけ知りたい方も、お気軽にご相談ください。