【WordPress】古いwp-config.phpを上書きしてDB接続エラー！ターミナルから復旧した全手順

WordPressのサイトを開いたら、真っ白な画面に英語で「Error establishing a database connection」。

今回、ConoHa VPS（KUSANAGI）で運用しているサイトで、まさにこの状態になりました。原因はPCに残っていた古い wp-config.php をうっかりアップロードしたことです。

しかも、慌てて「元のファイル」に戻したつもりが、それも古いファイルだったので直らない……という二段構えのやらかしでした。

この記事では、原因の突き止め方から、ターミナル（黒い画面）を使ったデータベースの復旧まで、実際にやった手順をそのまま、初心者の方にも分かるようにまとめます。

今回の環境

同じVPSに、WordPressサイトが3つ同居している構成です。

何をしていて、何が起きたのか

もともとの作業は、テーマの functions.php などに直書きしていた楽天APIやYouTube APIのキーを、wp-config.php に移すというものでした。キーを公開フォルダ内のファイルに書いておくより、wp-config.php の定数にしたほうが安全だからです。

ここでやらかしたのが次の流れです。

サーバー上で動いていた本物の wp-config.php は、この時点で上書きされて消えています。ここから、データベース側の情報を頼りに復旧していきます。

復旧までの全体の流れ

ステップ1：他のサイトが表示されるか確認する

最初に確認したいのは、データベース（MariaDB）そのものが止まっていないかです。

同じサーバーに別のWordPressサイトがあるなら、そちらを開いてみてください。

今回は他のサイトは普通に表示されたので、原因はこのサイトの wp-config.php に絞れました。

ステップ2：KUSANAGIの wp-config.php の場所を確認する

KUSANAGIでは、wp-config.php が公開フォルダ（DocumentRoot）の1つ上の階層に置かれています。外からアクセスされにくくするための仕組みです。

ただし、WordPressは次の2か所のどちらにあっても読み込みます。

もし両方にファイルがあると、DocumentRoot側が優先されます。間違った場所にアップロードすると、意図しないファイルが読まれてしまうので要注意です。

今回はDocumentRoot側には無く、1つ上の階層の1つだけでした。

ステップ3：WP_DEBUGで本当の原因を表示させる

「Error establishing a database connection」だけでは、何が悪いのか分かりません。そこで、wp-config.php の次の行を一時的に変更します。

define( 'WP_DEBUG', true );

アップロードしてサイトを再読み込みすると、エラー画面の上に英語の警告文が出ます。今回はこう表示されました。

Access denied for user 'hirochan_sample'@'localhost' (using password: YES)

警告文の意味は、次の表で判断できます。

今回は「Access denied」なので、ユーザー名かパスワードが違うということが分かりました。

ステップ4：ターミナルでデータベースに入る

ここからは、SSHでサーバーにrootでログインして作業します。

MariaDBに入る

mysql -u root -p

「Enter password:」と聞かれますが、何も入力せずにそのままEnterでOKです。

最近のMariaDBは、rootが「サーバーにrootでログインしている人だけ通す（unix_socket認証）」設定になっていることが多く、この場合はパスワードが不要です。実際に今回の環境では、rootのパスワードそのものが無効になっていました。

確認したい場合は、次のコマンドで分かります。

mysql -e "SHOW GRANTS FOR 'root'@'localhost';"

結果に「USING ‘invalid’ OR unix_socket」と出ていれば、パスワードは無効で、ターミナルからだけ入れる設定です。/root/.my.cnf などに古いパスワードが残っていても、使われていません。

この設定の場合、実は -u root -p を付けずに、mysql だけで入れます。

次の表示に変われば、入れています。

MariaDB [(none)]>

抜けるときは exit と入力してEnterです。

ステップ5：データベースに実在するユーザーとDBを調べる

最初は「wp-config.php のパスワードに、DB側を合わせればいい」と考えて、パスワード変更を試しました。ところが、次のエラーが出ました。

ERROR 1396 (HY000) at line 1: Operation ALTER USER failed for 'hirochan_sample'@'localhost'

このエラーは、そのユーザーがデータベースに存在しないという意味です。つまり、パスワードどころかユーザー名から違っていたわけです。

wp-config.php に書かれている設定を確認

パスワード以外の設定だけを表示するコマンドです。

grep -E "DB_NAME|DB_USER|DB_HOST" /home/kusanagi/プロファイル名/wp-config.php

データベースに実際にあるユーザーとDBを確認

mysql -u root -p -e "SELECT user,host FROM mysql.user; SHOW DATABASES;"

この2つを見比べると、ズレが一目で分かりました。

サーバー移行のときに、DB名とユーザー名を新しくしていたんですね。PCに残っていたのは、その移行前の wp-config.phpでした。

ステップ6：DBユーザーのパスワードを wp-config.php に合わせる

本物の wp-config.php が消えてしまったので、正しいパスワードは分かりません。そこで逆に、今の wp-config.php に書いてあるパスワードを正として、データベース側のパスワードを変更します。

パスワードを自動で読み取る

パスワードを手でコピーするとミスしやすいので、wp-config.php から自動で読み取って、PWという入れ物に入れます。

PW=$(grep "DB_PASSWORD" /home/kusanagi/プロファイル名/wp-config.php | sed -E "s/.*DB_PASSWORD'[[:space:]]*,[[:space:]]*'([^']*)'.*/\1/")

何も表示されなければ成功です。ちゃんと読み取れたか、文字数だけを表示して確認します（パスワード自体は画面に出ません）。

echo ${#PW}

「15」のように数字が出ればOK。「0」なら読み取りに失敗しています。

DBユーザーのパスワードを変更

実在するユーザー（今回は sample_user）のパスワードを、読み取ったものに変更します。

mysql -u root -p -e "ALTER USER 'sample_user'@'localhost' IDENTIFIED BY '$PW'; FLUSH PRIVILEGES;"

パスワードを聞かれたら、ステップ4と同じように入力してEnter。何も表示されずに元の画面に戻れば成功です。

ちなみに FLUSH PRIVILEGES は「変更した権限を今すぐ反映して」という命令です。

ステップ7：wp-config.php のDB名・ユーザー名を書き換える

ファイルを開かずに、ターミナルから直接書き換えます。sed は「文字を置き換える」コマンドです。

sed -i "s/'DB_NAME', 'hirochan_sample'/'DB_NAME', 'sample_wp'/; s/'DB_USER', 'hirochan_sample'/'DB_USER', 'sample_user'/" /home/kusanagi/プロファイル名/wp-config.php

何も表示されなければ書き換え完了です。確認してみます。

grep -E "DB_NAME|DB_USER|table_prefix" /home/kusanagi/プロファイル名/wp-config.php

ここでtable_prefix（テーブル名の頭文字）も一緒に確認しているのがポイントです。古いファイルだと、ここも違っている可能性があるからです。

ステップ8：表示確認と後片付け

サイトを再読み込みして、結果を確認します。

今回は無事にサイトが表示されました。

WP_DEBUGを元に戻す

WP_DEBUGを true のままにしておくと、訪問者にも警告文が見えてしまいます。必ず false に戻しましょう。

sed -i "s/'WP_DEBUG', true/'WP_DEBUG', false/" /home/kusanagi/プロファイル名/wp-config.php

ログアウトされていたら

古い wp-config.php は、ログイン用の鍵（SALT）も昔のものです。管理画面から一度ログアウトされることがありますが、普通にログインし直せばOKです。

ステップ9：本来やりたかった作業をやり直す

最後に、もともとの目的だったAPIキーの追記をやり直します。今度は事故防止のため、PCのファイルは使わず、サーバー上のファイルを直接編集しました。

1. WinSCPで、サーバー上の wp-config.php をまずPCにダウンロード（これが本物のバックアップ）
2. サーバー上の wp-config.php をダブルクリックして直接開く
3. 「That’s all, stop editing!」の行の上に定数を追記して保存

/* APIキー */
define( 'MYSITE_RAKUTEN_APP_ID',     'ここにアプリID' );
define( 'MYSITE_RAKUTEN_ACCESS_KEY', 'ここにアクセスキー' );
define( 'MYSITE_YOUTUBE_KEYS', array(
  'ここにAPIキー1',
  'ここにAPIキー2',
) );

テーマやプラグイン側では、この定数を読み込むように書き換えておけば、キーを公開フォルダのファイルに直書きせずに済みます。

ターミナル操作でハマったところ

今回、ターミナルに慣れていないせいでつまずいたポイントもまとめておきます。

いちばん効いたのは、貼り付けたらEnterを押す前に、コマンドが1つだけか目で確認するという習慣でした。

また、スクリーンショットで相談するときは、パスワードが写っていないか必ず確認しましょう。エラー文の中にパスワードがそのまま表示されることがあります。

再発防止のために

まとめ

「Error establishing a database connection」は焦るエラーですが、順番に切り分ければ落ち着いて直せます。

1. 他のサイトが動くか見て、DB自体の問題かを切り分ける
2. WP_DEBUGで、本当のエラー内容を表示させる
3. wp-config.php の中身と、DBに実在するユーザー・DBを見比べる
4. ズレている方を合わせる
5. WP_DEBUGを戻すのを忘れない

そして何より、wp-config.php をいじる前は、サーバー上の「今動いているファイル」をバックアップする。これに尽きます。

今回はうっかりミスでしたが、おかげでターミナルからデータベースを直す方法が身につきました。同じエラーで困っている方の参考になればうれしいです。