WordPressのデータベースを修復するときはWP_ALLOW_REPAIRを一時的に使う

WordPressのデータベース修復機能を使うなら、先にバックアップと復元方法を確認します。次に、wp-config.phpでWP_ALLOW_REPAIRを一時的に有効にし、修復画面で必要な処理だけを選びます。作業後は、同じ定数を必ず削除します。

この機能は、壊れたテーブルを確認し、修復を試みるためのものです。データベース名、利用者名、パスワード、ホスト名の誤りや、停止したデータベースサーバーを直す機能ではありません。データベースへ接続できない場合は、修復へ進む前に接続情報とサーバーの状態を確認します。

修復を始める前にデータベースの控えを確保する

修復処理は、データベースのテーブルへ変更を加えます。現在のデータベースを保存できるなら、修復前に保存します。既存のバックアップしかない場合は、その取得日時、対象のデータベース、復元方法を確認します。

WordPress Codexのバックアップ案内は、WordPressサイトの保存対象をデータベースとファイルに分けています。投稿や設定を戻すためのデータベースと、テーマやプラグイン、画像を含むファイルは、同じものではありません。今回の作業前には少なくとも、修復対象のデータベースを戻せるかを確かめます。

データベースを保存できず、復元方法も分からない状態では、修復ボタンを先に押しません。サーバーまたはデータベースを管理する人へ、表示されたエラー、対象サイト、発生時刻、直前の変更を渡します。作業を依頼しても、バックアップの保管場所と、復元を決める人は明確にしておきます。

wp-config.phpで修復機能を一時的に有効にする

wp-config.phpを編集できる状態にし、編集前のファイルを安全な場所へ保存します。次の一行を、WordPress本体を読み込む行より前に追加します。標準のwp-config.phpなら、/* That's all, stop editing! Happy blogging. */という行より前です。

define( 'WP_ALLOW_REPAIR', true );

追加後、次のURLを開きます。example.comの部分は、自分のサイトのURLへ置き換えます。

http://example.com/wp-admin/maint/repair.php

この画面には、「Repair Database」と「Repair and Optimize Database」という二つの処理があります。ボタン名が似ていても、目的は同じではありません。

修復と修復・最適化は処理が違う

WordPressのrepair.phpは、対象テーブルへCHECK TABLEを実行します。問題が報告されたテーブルには、REPAIR TABLEで修復を試みます。

「Repair and Optimize Database」を選ぶと、修復に加えて、状態を確認したテーブルへANALYZE TABLEとOPTIMIZE TABLEを実行します。WordPressの画面は、最適化に時間がかかり、その間はデータベースがロックされると説明しています。

表示不良を直したいという理由だけで、修復と最適化をまとめて選ぶ必要はありません。目的がテーブルの修復なら、先に修復だけを行います。最適化は、作業時間と公開中の処理への影響を確認してから別に判断します。

修復画面はログインなしで開く

WP_ALLOW_REPAIRを有効にすると、WordPressへログインしていない利用者も修復画面を開けます。WordPress Codexのwp-config.phpに関する説明は、データベースが壊れるとログインできないことがあるため、認証を必要としないと説明しています。

ログインできない状態でも使えることと、公開したままでよいことは別です。URLを知られても問題がない機能ではありません。WP_ALLOW_REPAIRを有効にする時間を作業中だけに絞り、画面を開いたまま放置しません。

作業が終わったら、wp-config.phpから次の一行を削除します。

define( 'WP_ALLOW_REPAIR', true );

削除後に修復画面をもう一度開き、修復ボタンが表示されず、定数を追加する案内へ戻ったことを確認します。修復した人と、wp-config.phpを元へ戻した人が違う場合は、削除確認まで担当を決めます。

修復結果とサイトの復旧を分けて確認する

修復画面に表示されたテーブル名とエラー文は、そのまま記録します。修復できない問題が残った場合は、同じ処理を繰り返す前に、記録をデータベース管理者またはWordPressのサポートへ渡します。

修復処理が終わったことだけで、サイト全体が復旧したとは判断しません。公開ページ、管理画面、投稿の表示、更新処理を分けて確認します。プラグインが独自に作ったテーブルや、標準と異なるデータベース構成は、修復画面の対象と結果を個別に調べます。

最初にすることは、修復ボタンを押すことではありません。修復対象のデータベースと戻せるバックアップを確認してください。そのうえでWP_ALLOW_REPAIRを有効にし、必要な処理だけを実行して、最後に定数を削除します。