WordPress「Error establishing a database connection」の修正方法

何が起きているか

WordPressサイトを開くと、ホームページの代わりに一行だけ表示されます：Error establishing a database connection。/wp-adminの管理パネルも同じ状態です。WordPressはMySQLに接続できていません — ただし、原因は設定ファイルのタイプミスからデータベースエンジンのクラッシュまで、6種類のいずれかである可能性があります。

以下の手順を順番に進めてください。ほとんどのサイトはStep 2までに復旧します。

Step 1 — wp-config.phpの認証情報を確認する

これが原因である確率は約70%です。誰かがデータベースのパスワードを変更したか、サイトを新しいサーバーに移行したか、ステージング環境にクローンしてwp-config.phpの認証情報を更新しなかったケースです。

nano /var/www/html/wp-config.php

以下の4行を探してください：

define( 'DB_NAME',     'your_database_name' );
define( 'DB_USER',     'your_db_user' );
define( 'DB_PASSWORD', 'your_db_password' );
define( 'DB_HOST',     'localhost' );

推測で判断せず、シェルから直接認証情報をテストしてください：

mysql -u your_db_user -p -h localhost your_database_name

MySQLがログインを拒否した場合、認証情報が間違っています。MySQLの内容に合わせてwp-config.phpを更新するか、MySQLユーザーのパスワードをリセットしてください：

mysql -u root -p
ALTER USER 'your_db_user'@'localhost' IDENTIFIED BY 'new_password';
FLUSH PRIVILEGES;

その後、wp-config.phpのDB_PASSWORDを同じ新しいパスワードに設定してください。

Step 2 — MySQLが実際に動作しているか確認する

認証情報が正しくてもエラーが続く場合、MySQLがダウンしている可能性があります。

# Ubuntu/Debian
systemctl status mysql

# CentOS/RHEL
systemctl status mysqld

停止している場合は起動してください：

systemctl start mysql
# MariaDBの場合
systemctl start mariadb

起動を拒否する場合は、他の操作をする前にログを確認してください：

journalctl -u mysql -n 50 --no-pager
# または
tail -n 100 /var/log/mysql/error.log

よく見られる起動失敗の原因は3つあります：ディスク容量不足（MySQLは一時ファイルの書き込みに空き容量が必要）、InnoDBクラッシュリカバリが必要（「InnoDB: Database was not shut down normally」というメッセージを探す）、またはibdata1ファイルの破損です。ログにどれかが示されているはずです — まずそれを修正してください。

Step 3 — データベースとユーザーの存在を確認する

MySQLにログインできたら、データベースとユーザーの両方が実際に存在するか確認してください。当たり前に思えるかもしれませんが、移行の失敗や誤ったDROPによってどちらかが消えることがあります。

mysql -u root -p

-- データベースの存在確認
SHOW DATABASES LIKE 'your_database_name';

-- 正しいホストでユーザーが存在するか確認
SELECT user, host FROM mysql.user WHERE user = 'your_db_user';

-- そのデータベースに対してユーザーが権限を持っているか確認
SHOW GRANTS FOR 'your_db_user'@'localhost';

ユーザーは存在するが権限がない場合、それが問題です：

GRANT ALL PRIVILEGES ON your_database_name.* TO 'your_db_user'@'localhost';
FLUSH PRIVILEGES;

データベース自体が消えている場合は、バックアップから復元してください — WordPressはゼロからデータベースを作成することはできません。

Step 4 — DB_HOSTの値を確認する

環境によっては、localhostが正しく解決されないことがあります。Docker環境、マネージドクラウドデータベース（Amazon RDS、PlanetScale）、MySQLがTCPポートではなくソケットでリッスンしているcPanelホストなどでよく発生します。

-- ソケットパスを確認
SHOW VARIABLES LIKE 'socket';
-- 一般的な出力例: /var/run/mysqld/mysqld.sock

wp-config.phpのDB_HOSTを以下のいずれかに変更してみてください：

// ソケットではなくTCPを強制する
define( 'DB_HOST', '127.0.0.1' );

// 明示的なソケットパス
define( 'DB_HOST', 'localhost:/var/run/mysqld/mysqld.sock' );

// リモートホスト（別のDBサーバーまたはDockerコンテナ）
define( 'DB_HOST', '10.0.0.5' );

Step 5 — 破損したテーブルを修復する

特殊なケースとして：WordPressはMySQLに正常に接続できているのに、フロントページにはエラーが表示され、/wp-adminは読み込まれる（または別のデータベースエラーが表示される）ことがあります。WordPressテーブルの破損が原因であることがほとんどです。

wp-config.phpに一時的に以下の1行を追加してください：

define( 'WP_ALLOW_REPAIR', true );

次に、ブラウザで以下のURLを開いてください：

https://yoursite.com/wp-admin/maint/repair.php

「Repair Database」をクリックして完了を待ってください。完了したら、WP_ALLOW_REPAIRの行をすぐに削除してください — ログインなしで誰でも修復を実行できてしまう、実際のセキュリティリスクになります。

コマンドラインを好む場合も同じ結果が得られます：

mysqlcheck -u root -p --repair your_database_name

Step 6 — max_connectionsとディスク容量を確認する

アクセスの多いサイトはこの問題に直面することがあります。MySQLには同時接続数の上限があります（デフォルト：151）。この上限に達すると、新しい接続はWordPressと同じエラーで失敗します。

mysql -u root -p -e "SHOW STATUS LIKE 'Max_used_connections';"
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections';"

Max_used_connectionsがmax_connectionsと同じ値であれば、上限に達しています。再起動なしでその場で上限を増やせます：

mysql -u root -p -e "SET GLOBAL max_connections = 300;"

再起動後も設定を維持するには、/etc/mysql/mysql.conf.d/mysqld.cnfを編集してください：

[mysqld]
max_connections = 300

ついでにディスク容量も確認してください。パーティションが満杯になると、MySQLは黙って書き込みを拒否し、WordPressはそれを接続障害として解釈します：

df -h

90%を超えているパーティションがあれば、次に進む前に調査する価値があります。

確認

修正を適用した後、実際に機能しているか確認してください：

• ホームページをリロードして、サイトが正常に表示されることを確認する。
• /wp-adminを開いてログインし、ダッシュボードが読み込まれることを確認する。
• 簡単なPHP接続テストを実行する：

<?php
$link = mysqli_connect('localhost', 'your_db_user', 'your_db_password', 'your_database_name');
if (!$link) {
    echo 'Connect failed: ' . mysqli_connect_error();
} else {
    echo 'Connected successfully';
    mysqli_close($link);
}

これをtest-db.phpとしてWebルートに保存し、ブラウザでアクセスしたら、すぐに削除してください。本番サーバーに生の接続テストファイルを置いたままにしないでください。

学んだ教訓

• WordPressサイトを移行する場合は、データベースをインポートする前にwp-config.phpの認証情報を更新してください — エラーが出てからではなく。
• このエラーはユーザーがサイトにアクセスするまで完全に無音です。基本的な死活監視（UptimeRobotには無料プランがあります。またはcronジョブで5分ごとにホームページをpingする）があれば、数時間後ではなく数秒で検知できます。
• MySQLの自動バックアップがあれば、テーブル破損のインシデントが10分の復元作業で済みます。なければ、手動修復に何時間もかかることがあります。
• 共有ホスティングを使用していてこの手順が効果ない場合は、ホスティング会社に連絡してください。顧客への通知なしにデータベース接続数を制限したり、認証情報をローテーションすることが日常的に行われています。