WordPressに「データベース接続確立エラー」と表示され、管理画面にも入れない。
VPSへ接続するとMySQLが停止しており、再起動してもすぐに落ちてしまう。
この状態では、サイト運営者側からできることがほとんどありません。
データベース接続エラーは、設定情報の間違いだけでなく、
MySQLの停止、ディスク容量不足、InnoDBの不整合、権限、ソケット、サーバー障害などでも発生します。
原因を決めつけて再起動やファイル削除を繰り返すと、救出できるデータまで失うおそれがあります。
特にVPSでは、レンタルサーバー会社がMySQL内部まで復旧してくれるとは限りません。
OS、Webサーバー、PHP、WordPress、MySQL、ストレージを分けて調べ、
データを保全しながら復旧する必要があります。
よこやま良平WordPressやVPSの復旧を多数手がけてきた、よこやま良平です。わたしは再起動を繰り返す前に、障害ログと容量を確認し、データベース原本を保全してから救出方法を判断します。
- WordPressのデータベース接続エラーをVPS側から切り分ける考え方
- MySQLが起動しない時にクイックレスキューが実際に行う作業
- ディスク容量枯渇とInnoDBエラーが重なった復旧事例
- データを失う危険があるため避けたい操作
- VPS・MySQL復旧を相談する前に準備する情報
この記事では、特定サイトの情報や認証情報を伏せたうえで、
実際のVPS障害で行った復旧作業を一般化して紹介します。
危険な復旧コマンドをそのまま実行する手順ではなく、
専門家が何を確認し、どの順番でデータを守るのかをわかりやすく解説します。
こんなお悩みはありませんか？
- ある朝、サイトを開いたら真っ白画面になっていた
- 管理画面にログインできなくなって手が止まった
- 身に覚えのない記事やページが勝手に増えていた
- プラグインを更新したらサイト全体が崩れてしまった
- 以前バックアップを取ったか自分でも覚えていない
累計1,000件以上のWordPressトラブル対応の経験から、「壊れる前に備える」ためのチェックリストを1冊にまとめました。
ログイン・本体・バックアップ・サーバー・運用の5分野を、50項目で「危険度・確認方法・対処法」まで解説しています。
セキュリティプラグイン・WordPressの教科書も含めた3大特典を、
今なら無料で受け取れます。
WordPressのVPSでMySQLが起動しない時は層を分けて調べる
WordPressのVPSでデータベース接続エラーが出た時は、最初にWebサイト、
PHP、MySQL、ストレージを分けて確認することが重要です。
画面に同じエラーが表示されても、原因によって復旧方法がまったく異なるからです。
画面のエラーだけではMySQL停止と設定ミスを区別できない
WordPress公式も、データベース接続エラーには、wp-config.phpの接続情報、データベース停止、容量制限など複数の原因があると説明しています。
つまり、画面を見ただけで「パスワードが違う」「データベースが壊れた」とは断定できません。
まず外部からHTTP応答を確認し、VPSへ接続できるか、Webサーバーは動いているか、MySQLプロセスや待受ポートが存在するかを調べます。
WordPressだけでなくサーバー全体が落ちている場合は、ネットワークやOSから確認する必要があります。
- VPS・OS：SSH接続、負荷、メモリ、ファイルシステム
- Webサーバー：ApacheやNginxの稼働、HTTP応答
- PHP：実行可否、バージョン、致命的エラー
- WordPress：接続先DB、設定ファイル、サイトURL
- MySQL：プロセス、ポート、ソケット、エラーログ、データ領域
VPSではディスク使用率とMySQLエラーログを同時に見る
MySQLが停止している時は、サービス状態だけでなく、ディスク使用率とエラーログの時刻をそろえて確認します。
容量が100％に近い状態では、データファイル、ログ、PID、テンポラリファイルなどを書き込めず、起動や更新処理が失敗することがあります。
次は代表的な読み取り確認例です。環境によってサービス名、ログ、データディレクトリは異なるため、表示結果を保存してから判断します。
df -h
ps aux | grep '[m]ysqld'
du -sh /var/lib/mysql 2>/dev/null
tail -n 100 /var/log/mysqld.log
MySQLが起動しない時に実際に行うデータベース復旧作業
MySQLが通常起動できない時は、復旧より先に原本保全を行い、救出用の起動と通常運用を分けます。
クイックレスキューでは、現在の状態を壊さないことを最優先にして、次の順番で作業します。
- 障害時刻、表示エラー、MySQLエラーログ、容量を記録する
- 書き込みを止め、データベース原本と設定ファイルを保全する
- 容量を使っているファイルの役割を判定し、安全に作業領域を確保する
- 必要な場合だけ最小の強制リカバリーモードで救出起動する
- 対象データベースをSQLとして退避し、完了記録とファイルを検証する
- 救出設定を解除して通常起動し、WordPressの読み書きを確認する
データベース原本と設定を先に保全する
復旧作業では、現在のデータディレクトリだけを頼りに操作しません。
MySQLを停止できる状態なら、データファイル、ログ、インデックス、
設定ファイルを役割ごとに確認し、復元できるコピーを作ります。
コピーは作っただけでは不十分です。アーカイブの一覧を読み取れるか、
想定したファイルが含まれているか、容量やハッシュが一致するかを確認します。
サーバー内のバックアップだけでなく、可能なら別の端末やストレージへ退避します。
大きいファイルがDB本体かログかを判定する
/var/lib/mysqlが大きくても、すべてがWordPressの記事や設定とは限りません。
テーブルファイル、InnoDB共有表領域、redoログ、バイナリログ、リレーログなど、
用途の異なるファイルが同じ周辺に置かれていることがあります。
MySQLのバイナリログは、データ変更の履歴を記録し、レプリケーションや時点復旧に利用されます。
不要と決めつけてOSから直接削除すると、MySQLが管理するインデックスとの不整合や、
復旧可能な履歴の喪失につながるため、用途と構成を確認して扱います。
強制リカバリーは通常運用ではなくSQL救出のために使う
InnoDBの不整合で起動できない場合、状況に応じてinnodb_force_recoveryを使うことがあります。
これは壊れたデータベースを自動修復する設定ではなく、
通常の処理を一部止めてデータを読み出すための緊急手段です。
MySQL公式も、0より大きい値は緊急時だけ使用し、必ず1から必要最小限で試すよう警告しています。
値が高いほどデータを損傷する危険が増えるため、原本コピーなしで本番環境へ設定する作業ではありません。
MySQL公式：Forcing InnoDB Recovery
SQL退避後に救出設定を外して通常起動を確認する
救出起動できたら、WordPressが使っているデータベースを確認してSQLダンプを取得します。
ファイルサイズだけで成功とせず、コマンドの終了状態、ダンプ末尾、
テーブル一覧、別環境で読み込める可能性まで確認します。
その後、MySQLを正常停止し、強制リカバリー設定を解除して通常モードで起動します。
ログに接続受付が記録されるか、トップページと複数記事を読めるか、
管理画面で下書き保存と削除ができるかを確認して完了です。
VPSの容量枯渇とInnoDBエラーが重なった復旧事例
実際の復旧では、約15年前のWordPress・PHP・MySQL構成が動くVPSで、MySQL停止とデータベース接続エラーが発生していました。
通常の再起動では復帰せず、MySQLエラーログにはInnoDBのページチェックサム不一致と異常終了が記録されていました。
DB本体ではなく約21GBのバイナリログが容量を圧迫
調査時、約30GBの領域はほぼ100％使用され、空きはごくわずかでした。
MySQLデータディレクトリは約22GBでしたが、
用途別に確認するとWordPressの実データは数百MBで、約21GBを占めていたのは長期間蓄積したバイナリログでした。
- LinuxとWebサーバーは稼働していたが、MySQLは停止していた
- WordPressはデータベース接続エラーを表示していた
- MySQLログにInnoDBのチェックサム不一致と異常終了が残っていた
- VPSのディスク領域がほぼ100％使用されていた
- 容量の大部分はDB本体ではなく、蓄積したバイナリログだった
- 原本保全とSQL救出後、通常モードでMySQLを起動できた
古いバイナリログを整理して作業領域を確保した後、データベース原本を保全しました。
最小の強制リカバリーモードでMySQLを起動し、WordPressデータベースをSQLへ退避してから、
設定を戻して通常起動を確認しています。
結果として、データベースの再構築は不要でした。
サイト表示、ログイン画面、管理画面での更新処理も確認でき、保存領域には十分な空きを確保できました。
ただし、容量枯渇がチェックサム不一致の唯一の原因だったかは、
残存ログだけでは断定していません。
「同時に確認された事象」と「確定した原因」を分けて報告することも重要です。
MySQL復旧で再起動やファイル削除を繰り返してはいけない
MySQL復旧で最も避けたいのは、原因と保全状況がわからないまま変更を重ねることです。
一時的に起動しても、データが読めない、ログが失われる、元の状態へ戻せないという問題が残る場合があります。
- MySQLが落ちるたびに何度も起動する
ibdata1、redoログ、binlogを役割確認なしでOSから削除する- 原本コピーを作らず、唯一のデータへ直接修復を試す
- 強制リカバリー値を一気に上げ、通常運用を続ける
- 復旧作業と同時にPHP・MySQL・WordPressを更新する
- エラーログや設定ファイルを保存せず上書きする
古い環境ほど復旧とアップグレードを分ける
古いWordPressへ先に新しいPHPやMySQLを当てると、テーマやプラグイン、文字コード、SQL仕様の互換性問題が加わります。
データベース障害の原因と更新後の不具合が混ざり、復旧できたか判断しにくくなります。
まず現行構成でデータを救出し、通常起動とWordPress動作を確認します。
アップグレードや新サーバー移行は、複製環境で段階的に検証する別作業として計画する方が安全です。
WordPressのVPS・MySQL復旧で対応できる作業範囲
クイックレスキューでは、WordPressの画面だけでなく、
VPSへ接続してOS・Webサーバー・PHP・MySQL・ストレージを横断的に確認します。
「データベース接続エラー」という結果だけでなく、
なぜMySQLが止まり、どのデータを守る必要があるかまで切り分けます。
- WordPressのデータベース接続エラーの原因調査
- VPS上のMySQL停止・起動失敗・InnoDBエラーの調査
- ディスク容量枯渇、巨大ログ、権限、ソケットの切り分け
- データベース原本・設定・障害ログの保全
- 強制リカバリーを利用したSQL救出とバックアップ検証
- 通常起動への復帰とWordPressの読み書き確認
相談時はURLとサーバー情報、直前の操作を整理する
ご相談時に、対象URL、VPS会社、障害が始まった時刻、表示されたエラー、
直前の更新や設定変更、バックアップの有無をお知らせください。
SSHや管理画面へ入れなくても、わかる範囲だけで構いません。
パスワードや秘密鍵をメール本文や公開チャットへ貼り付ける必要はありません。
安全な受け渡し方法と作業範囲を確認したうえで、必要な接続情報だけを扱います。
WordPressのVPS・MySQL復旧でよくある質問
VPS上でMySQLが起動しない時によくいただく質問をまとめます。
データが重要な場合は、回答を読んで自己判断で削除せず、現在の状態を残してご相談ください。
WordPressのVPSでMySQLが起動しない時は原本保全を優先する
WordPressのデータベース接続エラーでMySQLが起動しない時は、
再起動や削除を急がず、OS・Web・PHP・WordPress・MySQL・容量を分けて確認します。
ログと原本を残しておけば、強制リカバリーによるSQL救出や通常起動への復帰など、選べる手段が増えます。
- 同じ接続エラーでも設定ミス、MySQL停止、容量枯渇、InnoDB不整合で対処が違う
- 復旧前に障害ログ、データベース原本、設定ファイルを保全する
- 大容量ファイルはDB本体・binlog・redoログなど役割を判定する
- 強制リカバリーは修復機能ではなく、SQL救出のための緊急手段
- SQL退避後は救出設定を外し、通常起動とWordPressの読み書きを確認する
- 復旧とPHP・MySQL・WordPressのアップグレードは分けて実施する
VPSのMySQL障害は、WordPress管理画面だけでは直せません。
データが必要で、エラーログにchecksum、corruption、Assertionなどが出ている場合は、
現在の状態を変える前にご相談ください。
VPSやクラウドサーバーのMySQL障害でWordPressが表示できない時は
MySQLが起動しない、InnoDBエラーが出る、VPSの容量が満杯、データベース接続エラーで管理画面にも入れない場合は、
クイックレスキューが原因調査、原本保全、SQL救出、通常起動への復帰まで対応します。
- WordPressにデータベース接続エラーが出ている
- VPSでMySQLを起動してもすぐ停止する
- InnoDB、checksum、corruptionなどのエラーがある
- ディスク容量が100％で何を消せばよいかわからない
- 古いWordPress環境から記事と設定を救出したい
- 再構築が必要か、通常起動へ戻せるか判断してほしい
- 万一復旧できない場合やマルウェア駆除できない場合は全額返金保証で安心
- 90日間再感染保証・動作保証で安心
- 初期費用・調査費用0円で安心
