慌ててwp-config.phpを書き換える前に、原因を順番に切り分けるのが近道よ。①サーバー側の障害や一時停止、②wp-config.phpの接続情報の照合、③ユーザー権限とテーブルの状態、の順に確認するの。
あら、いらっしゃい、のりお。……まあ、その顔。真っ青じゃない。何かあったの？
サチエさん、大変なんです。会社のWordPressを開いたら、白い画面に「データベース接続確立エラー」って出て。英語で「Error establishing a database connection」とも書いてあって、管理画面にも入れないんです。記事、消えちゃったんでしょうか……。
落ち着きなさい。記事が消えたわけじゃないわ。いいこと教えてあげるから、私の話をよく聞いてちょうだい。
「データベース接続確立エラー」って、そもそも何なの？
あのね、このエラーは、WordPressが「データベースにつながっていない」って言っているだけなのよ。データベースはね、連絡がつかない男と同じ。返事がないからって、存在しないわけじゃないの。
WordPressは、ページを表示するたびにデータベースへ接続して、投稿、固定ページ、設定、ユーザー情報を読み出しているの。データベースは一般にMySQLとかMariaDBという、本体プログラムとは別の仕組み。その本体が無事でも、接続が失敗すれば、サイト全体も管理画面も表示できなくなるのよ。
トップページだけ崩れている症状と違うのは、ここ。このエラーが出ている間は、原則としてサイト全体が同じ画面になるわ。裏を返せば、接続さえ回復すれば、記事データそのものは無事なケースが大半。だから「消えた」じゃなくて「つながっていない」と捉えること。これが第一歩よ。
発生のきっかけとして多いのは、サーバー移転、ドメインやSSLの設定変更、データベースのパスワード変更、プラン変更やメンテナンスの直後。心当たりがあるなら、その作業で変わった情報から確認すると効率的よ。逆に、本当に何もしていないのに突然出た場合は、サーバー側の障害、負荷、容量上限を先に疑うの。あとね、エラーが出た日時と直前の作業は、今のうちにメモしておきなさい。後でサーバー会社に問い合わせるとき、必ず役に立つから。
そして結論を先に言っておくわね。慌ててファイルを書き換える前に、原因を順番に切り分けることが近道なの。順番は3段階。①サーバー側の障害や一時的な停止じゃないか、②wp-config.phpの接続情報がサーバー側と一致しているか、③ユーザー権限やテーブルの状態に問題がないか。公式のサポート文書でも、まずwp-config.phpの情報の誤り、次にホスト側の問題を確認するよう案内されているわ。
で、原因って、だいたい何なんですか？
大きく4つよ。順番に並べてあげるから、よく聞いて。
主な原因は大きく4つ
1. wp-config.phpの接続情報の不一致
一番多いのがこれ。WordPressは、wp-config.phpに書かれた接続情報でデータベースにログインするのよ。データベース名、ユーザー名、パスワード、ホスト名のうち、どれか1つでもサーバー側の実際の情報と違えば接続できないの。移転前の古い情報を残していたり、パスワードを変えたのにファイル側を更新し忘れていたりが典型ね。
2. サーバー側の障害・停止・容量上限
設定が正しくても、データベースサーバー自体が止まっていたらつながらないわ。データベースのサイズが上限に達して停止することもあるし、アクセス集中の一時的な過負荷で、短時間だけ出て自然に回復することもあるの。
3. データベースユーザーの権限不足
ユーザーは存在しても、対象のデータベースに対する権限が付いていなければ失敗するのよ。移転先でデータベースとユーザーを別々に作ったときに起こりやすくて、作っただけじゃ不十分。紐付けと権限付与まで完了しているか確認が必要よ。
4. テーブルの破損などデータベース側の不整合
ただしね、いきなり修復から入っちゃダメ。1から3を先に否定してから進むのが安全なの。順番を飛ばすと、原因が分からないまま状態を変えてしまって、復旧が遠のくわ。
分かりました！ じゃあ、すぐwp-config.phpを書き換えてきます！
待ちなさい。できない男ほど、すぐ手を動かすのよね。書き換える前に、やることがあるの。
作業前に必ずやること
いいこと教えてあげる。wp-config.phpを編集する前に、必ず今のファイルをダウンロードして控えを残すこと。コントロールパネルにバックアップ機能があるなら、ファイルとデータベースのバックアップが取れるかも確認なさい。公式ドキュメントでも、設定変更の前にはバックアップと復元方法の確認が前提とされているわ。控えがあれば、編集で悪化しても元に戻せるの。
それと、編集にはテキストエディタを使うこと。ワープロソフトはダメよ。余分な書式が紛れ込むと、接続以前に構文エラーになるわ。あと、編集対象はwp-config.php本体。見本のwp-config-sample.phpじゃないわよ。サンプル側を直しても、何も反映されないからね。
切り分けの順番は、さっき言った3段階よ。①サーバーの障害や一時的な停止じゃないか、②wp-config.phpの接続情報がサーバー側と一致しているか、③ユーザー権限やテーブルの状態に問題がないか。この順番で進めるのが近道なの。
手順1：サーバー障害と一時的なエラーかを先に確認する
まず、利用中のサーバー事業者の障害情報とメンテナンス情報を確認なさい。自分のサーバーが対象になっていたら、利用者側では直せない。復旧を待つのが正解よ。この確認を省いて設定をいじると、無事だった設定まで壊しかねないわ。
あわせて、5分から10分ほど置いて再読み込みして、自然に戻るかも見なさい。短時間で回復するなら一時的な負荷の可能性が高くて、設定変更は不要。何度も再発するなら、発生時刻を記録してサーバー会社へ相談よ。パネルに入れる場合は、データベースが稼働中か、ディスク容量やデータベース容量が上限に達していないかも見ておきなさい。
障害じゃなかったです。それでも直りません……。
じゃあ本命よ。接続情報の照合。落ち着いて、1文字ずつ見るのよ。
手順2：wp-config.phpの接続情報を照合する
FTPソフトかサーバーのファイルマネージャーでサイトに接続して、wp-config.phpを開きなさい。置き場所はWordPressのルートディレクトリ。wp-adminやwp-contentと同じ階層にあるわ。
確認するのは、ファイルの前半にあるこの4つよ。
- DB_NAME：データベース名
- DB_USER：データベースのユーザー名
- DB_PASSWORD：そのユーザーのパスワード
- DB_HOST：データベースのホスト名
書き方は、define( 'DB_NAME', '実際の値'); の形ね。サーバーのコントロールパネルで表示される現在の正しい値と、1文字ずつ照合なさい。特に見落としやすいのは、前後の不要な空白、全角文字の混入、シングルクォートの欠け、似た文字列の取り違え。値を直すときは、クォートで囲まれた内側の文字列だけを置き換えて、defineの構造自体は触らないこと。
DB_HOSTでつまずく子が多いのだけど、あの子は多くの環境でlocalhost。でも、全部がそうとは限らないわ。事業者によっては専用のホスト名やIPアドレスを指定したり、localhost:3307みたいにポート番号付きで書いたり、Unixソケットのパスを指定したりする場合があるの。移転直後に旧サーバーのホスト名が残っていると、この項目だけでエラーになる。不明な場合は推測で書き換えちゃダメ。契約中のサーバーのマニュアルや管理画面の案内を正としなさい。
パスワードも大事よ。サーバー側でパスワードを変更したら、wp-config.phpのDB_PASSWORDも同じ新しい値に更新しないと接続できないの。逆に、ファイル側だけ先に変えてもダメ。大事なのは、サーバー側の実パスワードとファイルの記述が一致していること。どちらが正か分からなくなったら、サーバー側でパスワードを再設定して、その値を正確にファイルへ反映させる。この順番でそろえ直すのが確実よ。パスワードに記号が含まれているときは、コピー時の欠けや引用符との混同にも注意なさい。
4つとも照合しました。でも、まだ直らなくて……。
あら、しぶといわね。じゃあ次。WordPressを通さずに、データベースへ直接入れるかどうか、試してみなさい。
手順3：phpMyAdminで接続できるか試し、権限を確認する
サーバーの管理画面からphpMyAdminを開いて、wp-config.phpと同じデータベース名、ユーザー名、パスワードでログインできるか確認なさい。
ログインできない場合は、WordPress本体じゃなく、認証情報か権限かサーバー側の問題である可能性が高まるわ。管理画面で、そのユーザーが対象データベースに紐付いているか、必要な権限が付与されているか確認なさい。権限の付け直しやユーザーの再作成をしたら、最終的な値でwp-config.phpも更新して、両側を一致させるのよ。
逆にphpMyAdminに入れて、対象データベース内にwp_で始まるような接頭辞付きのテーブル群が見える場合は、接続情報自体は概ね正しいと考えられるわ。その場合は、この先の修復やサーバー負荷を疑うの。ただし、この段階で安易にインポートや削除はしちゃダメ。ここでは確認が目的なの。
phpMyAdminには入れて、テーブルも見えました。でもエラーは続いてます。
なら、最後の切り札よ。データベースの修復。ただし、約束を守れる人だけが使っていいの。
手順4：データベースの修復を試す
接続情報も権限も正しく、サーバーも稼働しているのにエラーが続く、あるいはテーブルが利用できない旨の表示が出る場合に使う、WordPress標準の修復機能よ。
やり方はこう。wp-config.phpの「編集が必要なのはここまでです」といった案内文より前に、この1行を追加して保存なさい。
define( 'WP_ALLOW_REPAIR', true);それから、ブラウザで自分のサイトの/wp-admin/maint/repair.phpにアクセスするの。表示された画面で「データベースの修復」を実行して、結果を確認なさい。「修復と最適化」も選べるけど、まずは修復で回復するかを見るのが分かりやすい進め方よ。
よく聞いて、ここ大事よ。この修復機能はね、有効な間はログインしていなくてもアクセスできる仕組みなの。だから作業が終わったら、追加した行は必ず削除するか、falseに変更すること。残したままにすると、第三者が修復画面にアクセスできる状態になって、セキュリティ上の問題になるわ。必要なときだけ有効化して、解決したら無効化。これが公式にも明記されている約束よ。修復で直らない場合や、対象テーブルが修復に対応していない場合は、無理に繰り返さず、バックアップからの復元やサーバー会社への相談へ進みなさい。
直りました……！ でも、また同じことになりそうで怖いです。
いい心がけよ。直ったあとにも、気をつけることがあるの。最後まで聞きなさい。
つまずきポイントと注意点
あるわよ、聞きなさい。第一に、テーブル接頭辞の$table_prefixの不一致は、このエラーの主因とは分けて考えること。接頭辞が違うと接続とは別の問題になりやすいから、先にいじると切り分けが混乱するわ。第二に、一度に何箇所も変更しないこと。1つ直して確認、を繰り返さないと、どれが効いたのか分からなくなるの。第三に、直ったように見えても、管理画面に入れるか、投稿が表示されるか、更新ができるかまで確認すること。
それとね、wp-config.phpにもホスト側にも問題が見当たらない場合は、改ざんの可能性も排除できないの。見覚えのないファイルやユーザーが増えているなど不審な点がある場合は、復旧作業と並行せず、まずサーバー会社や専門家へ相談なさい。
もし今度、どうやっても直らなかったら……？
そのときはね、無理に作業を広げ続けないこと。切り替える勇気も、仕事のうちよ。
直らない場合の次善策
ここまで確認しても直らない場合は、作業を広げ続けるより切り替えた方が安全よ。選択肢は3つ。
1つ目は、正常だった時点のバックアップから、ファイルとデータベースを同じ時点の組み合わせで復元すること。片方だけ戻すと不整合の原因になるわ。2つ目は、サーバー会社への問い合わせ。エラーが出始めた日時、対象URL、直前の作業、障害情報の確認結果、4項目を照合済みかどうか、phpMyAdminに入れたかどうかを伝えると調査が進みやすくなるの。パスワードそのものを文面に書く必要はないわ。3つ目は、制作会社や専門家への依頼。売上や問い合わせに直結するサイト、バックアップの有無自体が分からない場合、改ざんが疑われる場合は、自己対応を続けるリスクの方が大きいわ。
そして復旧後の話。再発を防ぐには、移転、パスワード変更、プラン変更といった接続情報に関わる作業の手順を決めておくこと。サーバー側を変更したらwp-config.phpも同じ機会に更新して、動作確認までを1セットにすること。変更前後のファイルの控えを日付付きで残すこと。バックアップが定期的に取れているか確認すること。この3点だけでも、再発時の復旧は大きく楽になるわ。
よくある質問
このエラーが出ると、記事のデータは消えてしまったのですか。
消えたわけじゃないわ。WordPressがデータベースにつながっていないだけなの。接続さえ回復すれば、記事データそのものは無事なケースが大半よ。
DB_HOST は localhost と書けば合っていますか。
多くの環境では localhost だけれど、全部がそうとは限らないわ。事業者によっては、専用のホスト名やIPアドレス、ポート番号付きの書き方、Unixソケットのパスを指定する場合があるの。不明なら推測で書き換えず、契約中のサーバーのマニュアルや管理画面の案内を正としなさい。
修復のために追加した WP_ALLOW_REPAIR は、そのまま残してもいいですか。
残してはダメよ。有効な間は、ログインしていなくても修復画面にアクセスできてしまうの。作業が終わったら、追加した行を削除するか、false に変更なさい。
ありがとうございます、サチエさん。すっきりしました。順番なんですね、全部。
そうよ。慌てて書き換える前に、順番に切り分ける。それが、できない男との違いよ。……今度はエラーが出る前に、バックアップの相談にいらっしゃい。
まとめ
- 「データベース接続確立エラー」は、WordPressがデータベースにつながらない状態を示すエラーで、記事データが消えたことと同義ではない
- 直し方は順番が要点：まずサーバーの障害情報と一時的な負荷を確認し、次にwp-config.phpのDB_NAME、DB_USER、DB_PASSWORD、DB_HOSTをサーバー側の正しい値と照合する
- 照合で直らなければ、phpMyAdminで接続可否とユーザー権限を確認し、その後にWordPress標準の修復機能（WP_ALLOW_REPAIR）を、作業後すぐ無効化する前提で試す
- 編集前には必ずwp-config.phpの控えを取り、変更は1つずつ行って確認する。一度に複数箇所を変えない
- 直らない場合は、ファイルとデータベースを同じ時点のバックアップでそろえて復元するか、確認結果をそろえてサーバー会社や専門家へ相談する
- 再発防止には、サーバー側の変更とwp-config.phpの更新・動作確認を1セットにし、変更前後の控えを日付付きで残し、定期バックアップを確認する
