最初に確認すること
サーバー会社の障害情報、DBサービス、発生時刻、同一サーバーの別サイトへの影響を確認します。移行やパスワード変更の直後なら、wp-config.phpのDB名・ユーザー・ホストとの一致を優先します。値を公開チャットへ貼らないでください。
主な原因と調査先
認証失敗なら資格情報とユーザー権限、接続不能ならホストやネットワーク、上限超過なら接続数と負荷を確認します。共有サーバーでは提供者が調べる必要がある項目もあるため、ログと時刻を添えて相談します。
設定変更は控えを取って行う
現在の設定とDBを可能な範囲で保全し、一項目ずつ確認します。推測でDBユーザーを作り直したり、権限を全開放したりしないでください。接続できないこととテーブル破損は別なので、根拠なく修復ツールを実行しないようにします。
復旧後に確認する機能
公開表示だけでなく投稿保存、ログイン、製品独自テーブルへの書込みを確認します。負荷が原因なら遅い処理や接続の増加を調べ、再発を検知する監視を追加します。
移行直後の接続エラーを調べる例
旧サーバーのDBホスト名やユーザーが設定に残っていないか、新DBへのインポートが完了したか、接続元に対する権限があるかを確認します。DBの存在と認証成功は別です。複数環境がある場合は、誤って本番以外のDBへ接続していないかも確認します。
接続後に別エラーが出る場合
テーブルの接頭辞、必要な独自テーブル、文字コード、製品のDB移行を確認します。最初の接続エラーが解消しても、復元や移行全体が完了したとは限りません。
よくある質問
DB修復機能を使えば直りますか?
接続情報、サービス停止、上限超過は修復とは別の問題です。破損の根拠とバックアップを確認し、サーバー担当と適切な操作を選びます。
パスワードを変えれば安全ですか?
接続元の設定も更新する必要があります。変更は関係するサイトや定期処理へ影響するため、利用先と復旧手順を確認します。