WordPressで「Error establishing a database connection（データベース接続確立エラー）」が出ると、サイトが全面停止したように見えるため、多くのWeb担当者が強い不安を感じます。売上ページや問い合わせ導線が止まると、技術的な問題以上に「いつ復旧できるか分からない」ことが怖いからです。

ただし、このエラーは闇雲に触ると長引きます。逆に、確認順序を固定すれば、非エンジニアでも「自力で直せる範囲」と「ここから先は依頼すべき範囲」を明確に切り分けられます。

この記事のゴールは、次の2つです。

  • 自力で実施できる復旧作業を、順番どおりに進められる
  • 対応不能と判断すべき基準を持ち、必要時に素早く専門家へ引き継げる

「データベース接続確立エラー」とは何か（仕組み解説）

WordPressは、ページ表示のたびにデータベース（MySQL/MariaDB）へ接続し、投稿・設定・ユーザー情報を読み出します。つまり、WordPress本体とデータベースは「毎回通信して表示を作る関係」です。

このとき接続先情報は wp-config.php の DB_NAME DB_USER DB_PASSWORD DB_HOST で管理されます。WordPress公式ドキュメントでも、この4項目が接続の中核として示されています。

したがってこのエラーは、要点を1つに絞ると次の意味です。

WordPressがデータベースに接続できていない

原因は複数ありますが、復旧作業の考え方はシンプルです。

  1. 設定値が正しいか
  2. DBサーバーが生きているか
  3. 権限や接続数など、サーバー側制限に引っかかっていないか

この順で確認すると、遠回りを防げます。

実務では、症状から初手を決めるとさらに迷いにくくなります。

症状 まず疑うポイント 最初の行動
フロントも管理画面も同じエラー DB接続情報ミス、DB停止 wp-config.php と障害情報を同時確認
一時的に出たり消えたりする DB負荷、接続上限、アクセス急増 アクセス推移とサーバー負荷を確認
移行直後に発生 接続先情報の更新漏れ 旧環境のDB名/ユーザー名残りを確認
復元直後に発生 バックアップ世代の不整合 復元元の wp-config.php とDB世代を照合

緊急時の最初の3分で確認すること

まずは調査前の「状況固定」を行います。ここを省くと、原因切り分けが崩れます。

1. /wp-admin/ も同じエラーか確認

  • トップページだけでなく https://あなたのドメイン/wp-admin/ も確認
  • フロント・管理画面の両方で同エラーなら、DB接続層の問題である可能性が高い

2. ホスティング会社の障害情報を確認

  • 障害・メンテナンス情報ページ
  • 公式X（旧Twitter）
  • コントロールパネル内のお知らせ（障害情報カテゴリ）

この確認で「自分の設定ミスではなく、サーバー側障害」と判明するケースは少なくありません。

3. アクセス急増の有無を確認

  • キャンペーン配信直後
  • メディア掲載直後
  • botアクセス急増

アクセス急増時は、DB接続上限やリソース逼迫で一時的に同エラーが出ることがあります。アクセスログ・リソース情報も同時に見ておきましょう。

加えて、復旧中は「作業ログ」を短く残してください。
例: 10:05 wp-config.php確認開始 / 10:12 DB_HOST修正 / 10:18 変化なし
この記録があるだけで、引き継ぎ時の再調査コストを大幅に減らせます。

wp-config.phpのDB情報をチェックする手順

ここが最重要です。WordPress公式の「Common WordPress errors」でも、まず wp-config.php の接続情報確認が推奨されています。

作業前の前提

  • いきなり編集せず、wp-config.php をバックアップ
  • 可能ならファイル全体を別名保存（例: wp-config.php.bak-20260427）
  • テキストエディタはプレーンテキスト対応のものを使用

4つの定数の意味

項目 意味 典型的なミス
DB_NAME 接続先DB名 移行前のDB名が残っている
DB_USER 接続ユーザー名 接頭辞付きユーザー名の不一致
DB_PASSWORD DBユーザーパスワード パスワード変更後に未反映
DB_HOST DBホスト名 localhost 前提で固定してしまう

確認例:

define( 'DB_NAME', 'example_db' );
define( 'DB_USER', 'example_user' );
define( 'DB_PASSWORD', 'example_password' );
define( 'DB_HOST', 'localhost' );

よくある発生タイミング

  • サーバー移行直後
  • DBユーザーのパスワード変更直後
  • 復元作業で古い wp-config.php を上書きした直後

文字コード・BOM混入の注意

wp-config.php は保存形式の影響を受けます。WordPressのFAQでも、UTF-8 BOM による不具合注意が明記されています。

  • 保存形式は UTF-8（BOMなし）
  • 先頭・末尾の不要な空白や改行を入れない

値が正しくても、保存形式が不適切だと別エラーを誘発して復旧が遅れます。

WP_ALLOW_REPAIRを使ったデータベース修復

接続情報が正しいのに不安定な場合、WordPress標準のDB修復機能を試せます。

手順

  1. wp-config.php に次の1行を追加（/* That's all... */ より上）
define( 'WP_ALLOW_REPAIR', true );
  1. ブラウザで https://あなたのドメイン/wp-admin/maint/repair.php にアクセス
  2. 「データベースを修復」または「データベースを修復して最適化」を実行

必ず実施する後処理

修復後は、追加した WP_ALLOW_REPAIR 行を削除してください。

理由は明確です。この定数を残すと、ログインなしで修復ページへアクセス可能な状態が続くためです。

復旧作業の“終わり”は、修復成功ではなく「定数削除まで完了」です。

データベースサーバ側の確認

アプリ側で直らない場合は、DBサーバー側を確認します。

1. phpMyAdmin にログインできるか

phpMyAdmin（ピーエイチピーマイアドミン：DBをブラウザから操作するツール）へ入れない場合、WordPress以前にDB接続基盤が不安定な可能性があります。

2. DBユーザー権限・接続設定

  • 対象DBに対する接続権限があるか
  • DBユーザーとDBの紐づけが正しいか
  • 接続元制限や接続上限に達していないか

3. DB実体の確認

  • 対象データベースが存在するか
  • WordPress主要テーブル（wp_options など）が存在するか
  • 破損テーブルが出ていないか

「DBはあるが主要テーブルがない」場合、接続先を間違えているか、復元元を取り違えている可能性があります。
この状態で新規インストールを重ねると復旧が複雑化するため、“足りないテーブルを手で作る”対応は避け、バックアップ世代の再確認を優先してください。

WP_ALLOW_REPAIR で直らず、phpMyAdminでも異常が確認される場合は、ホスティング側サポートまたは専門家対応を前提にしてください。

レンタルサーバ別の典型的原因と確認場所

以下は、各社公式マニュアルで確認できる範囲に限定した「まず見る場所」です。

サーバー まず確認する場所（公式導線） このサーバーで起きやすい確認ポイント
XServer サーバーパネル MySQL設定 / phpMyAdmin、障害・メンテナンス情報ページ wp-config.php のDB情報不一致、MySQLユーザー・権限設定ミス
ConoHa WING コントロールパネル WING > サイト管理 > データベース、お知らせ > 障害情報/メンテナンス情報 DBユーザーと接続先DBの紐づけ漏れ、ユーザー情報更新漏れ
さくらのレンタルサーバ サーバーコントロールパネル Webサイト/データ > データベース、サポートサイトの障害情報 コントロールパネルのログイン種別違いで設定項目が見えず、確認漏れが発生
ロリポップ！ ユーザー専用ページ サーバーの管理・設定 > データベース > 操作する、phpMyAdmin導線 DBパスワード確認漏れ、phpMyAdminログイン時の接続情報入力ミス

補足として、各社とも管理画面構成は更新されるため、現場では必ず「公式マニュアルの最新画面」を基準に進めてください。

自力対応の限界を判断する基準

次の条件に1つでも該当する場合、自力継続より「被害最小化」を優先すべきです。

  • バックアップがない状態で作業を進めようとしている
  • WP_ALLOW_REPAIR でも復旧しない
  • phpMyAdmin にも入れない
  • 復元後にマルウェア痕跡（不審管理者・不審PHPファイル等）があった
  • 24時間以上ダウンしている

この段階では、原因調査と復旧を同時並行で進める必要があります。判断が難しい場合は、障害復旧サービスのような専門対応へ早めに切り替えるほうが、結果的に停止時間と機会損失を抑えられます。

WP Axisの障害復旧は ¥49,500・成果報酬制です。費用の前に、まず「今日中に復旧見込みが立つか」で判断してください。

相談時は、次の3点を先に渡すと初動が速くなります。

  • いつから落ちたか（時刻）
  • 直前の変更内容（更新・移行・設定変更）
  • いま確認できている症状（/wp-admin/ 含む）

再発防止：このエラーを防ぐ運用設計

復旧後は、同じ事故を「運用で起こしにくくする」段階に入ります。

1. 自動バックアップを複線化

  • 日次バックアップ（ファイル＋DB）
  • 復元テストを月1回実施
  • 保存先を同一サーバー外にも持つ

2. DB接続情報の安全管理

  • wp-config.php の変更履歴を残す
  • パスワード変更時は更新手順をチェックリスト化
  • 引き継ぎ資料に「現在値の保管場所」を明記

3. 監視を「表示監視だけ」で終わらせない

  • 死活監視（HTTP 200監視）
  • DB接続失敗ログの監視
  • しきい値超過時の即時通知

4. autoload オプション肥大化の定期点検

wp_options テーブルの autoload='yes' データが過大化すると、ページ初期化時の負荷増大で不安定化しやすくなります。四半期ごとにサイズ点検し、不要オプションを整理してください。

5. 運用保守を体制化

社内で継続監視しにくい場合、復旧後の運用フェーズだけ外部化する方法も有効です。必要に応じて運用保守サービスのような定期保守を検討すると、障害の早期検知と再発防止を両立しやすくなります。

まとめ

「Error establishing a database connection」の復旧で重要なのは、技術力より順番です。

  1. 最初の3分で状況固定（/wp-admin/・障害情報・アクセス急増）
  2. wp-config.php の4項目を正確に照合
  3. 必要時のみ WP_ALLOW_REPAIR を使い、終了後に必ず削除
  4. phpMyAdmin とサーバー側設定を確認
  5. 限界ラインに達したら早めに専門家へ切替

焦って操作を増やすほど、復旧は遅れます。順番を守ること自体が、最大の障害対策です。