WordPressの本番データベースをローカル環境にコピーする
WordPressの本番環境のデータベース(DB)をエクスポートし、ローカル環境に反映する手順の備忘録。ローカル環境にはLocal(LocalWP)、DBのインポートやURLの置換にはWP-CLIを想定。
前提条件
- 本番サーバーにSSH接続できる
- 本番環境とローカル環境でWordPressのテーマ・プラグインが揃っている
- 通常のシングルサイト構成(マルチサイトは対象外)
本番環境のDBをエクスポート
本番サーバーにSSH接続でWordPressのインストールディレクトリに移動し、以下のコマンドでDBをエクスポートする。
WP-CLIの場合、WordPressのDB接続情報を自動的に取得してエクスポートするため、DBのユーザー名やパスワードを指定する必要はないが、MySQLを直接使用する場合は接続情報を指定する必要がある。
wp db export ../production.sql
mysqldump --single-transaction -u DB_USER -p DB_NAME > ../production.sql
※エクスポートしたSQLファイルはユーザー情報など機密情報を含む可能性があるため、出力先に注意する。また、作業後は不要なファイルを削除する。
SQLファイルをローカルにダウンロード
ローカルPCのターミナルから scp コマンドを実行し、エクスポートしたSQLファイルをダウンロードする。
scp user@example.com:/path/to/production.sql ./
user@example.com:SSH接続先/path/to/production.sql:本番サーバー上のSQLファイル./:ローカルの保存先(カレントディレクトリ)
SSH接続にポート指定や秘密鍵が必要な場合は、-P や-i オプションを使用する。
ローカル環境にDBをインポート
ローカル環境でも、必要に応じて現在のローカルDBをバックアップしておく(wp db export local-backup.sql / mysqldump --single-transaction -u DB_USER -p DB_NAME > local-backup.sql など)。
次に、本番環境から取得したSQLファイルをインポートする。
wp db import /path/to/production.sql
なお、wp db import は既存のテーブルをすべて削除するコマンドではなく本番環境に存在しないテーブルがローカルに残る場合がある。完全にDBを揃えたい場合は、事前にwp db reset を実行してローカルDBを初期化しておく。(wp db reset は接続先のDBを初期化するため、実行先を十分確認すること。)
mysql -u DB_USER -p DB_NAME < production.sql
URLをローカル環境用に置換
本番DBには本番サイトのURLが保存されているため、ローカル環境のURLに置換する。
WordPressのDBにはシリアライズされたデータも含まれるため、単純なSQLの文字列置換ではなく、WP-CLIのsearch-replaceを使用する。
まず、--dry-runで置換対象を確認する。
wp search-replace "https://example.com" "http://example.local" --skip-columns=guid --dry-run
問題がなければ、実際に置換する。
wp search-replace "https://example.com" "http://example.local" --skip-columns=guid
主なオプション:
--dry-run:DBを書き換えず、置換対象を確認する--skip-columns=guid:投稿のguidカラムを置換対象から除外する--all-tables-with-prefix:WordPressのテーブル接頭辞に一致するすべてのテーブルを対象にする
wp search-replaceはPHPのシリアライズデータにも対応しており、文字列長などを適切に更新できる。
なお、プラグインなどが作成した独自テーブルは標準の置換対象に含まれない場合がある。必要に応じて--all-tables-with-prefixを指定する。
置換後、以下のコマンドでサイトURLを確認する。
wp option get home
wp option get siteurl
どちらもローカル環境のURLになっていればOK。
※WP_HOMEやWP_SITEURLをwp-config.phpなどで定義している場合は、そちらの設定も確認する。
ローカル環境の動作確認
DBのインポートとURL置換が完了したら、ローカルサイトにアクセスして動作を確認するが、本番DBをインポートすると、WordPressのユーザー情報やプラグイン設定も本番環境のものになる。ログインには基本的に本番環境のユーザー情報を使用する。
必要であれば、WP-CLIでパスワードを変更できる。
wp user update USER_ID --user_pass='NEW_PASSWORD'
また、メール送信・外部API・決済サービスなどの設定もDBに保存されている場合、本番環境のものが引き継がれる場合がある。ローカル環境から本番向けのメール送信や外部サービスへの処理が実行されないよう、必要に応じて無効化・設定変更しておく。
画像などのファイルの同期
DBだけをコピーしても、投稿内の画像ファイルなどはローカル環境に存在しない。ついでに画像も揃えたい場合は、本番サーバーのwp-content/uploads/をローカルにコピーする。
rsyncを使用すると、差分のみを転送できるため、2回目以降の同期にも便利。
ローカルPCのターミナルから実行する。
rsync -avz user@example.com:/path/to/wp-content/uploads/ /path/to/local/wp-content/uploads/
- 転送元:本番環境の
wp-content/uploads/ - 転送先:ローカル環境の
wp-content/uploads/
末尾の/はディレクトリの中身をコピーする指定。
ローカル側にだけ存在するファイルは削除されない。
本番環境と完全に一致させたい場合は--deleteオプションも使用できるが、ローカル側のファイルが削除されるため注意すること。
なお、テーマやプラグインが独自のディレクトリにファイルを保存している場合は、それらも必要に応じて同期する。
注意点
- 本番DBにはユーザー情報などの個人情報や、プラグインが保存したAPIキーなどの機密情報が含まれる場合がある。ローカル環境でこれらの情報が不要な場合は、インポート後にダミーデータへの置換や削除を行う。
- なお、機密情報をローカル環境に持ち込むこと自体を避けたい場合は、本番側で匿名化したDBを用意してからエクスポートする必要がある。
- また、WordPressにはユーザー情報以外にも、コメント投稿者のメールアドレス、問い合わせフォームの送信履歴、ECサイトの注文情報などが保存される場合がある。これらの情報も必要に応じてダミーデータに置換するか削除することが望ましい。
LocalWPのWP-CLIで不具合が出る
DB接続エラーが出る場合
LocalWPのWP-CLIでDB接続エラーが出る場合、wp-config.phpに以下のようにDBホストを明示的に指定することで解決することがある。ポート番号はDatabaseタブで確認できる。
define( 'DB_HOST', '127.0.0.1:Port' );
search-replaceのdry-run結果がおかしい場合
上手くいっていない場合、特にwp_optionsテーブルのhomeやsiteurlの値が正しく置換されていないことがあるので、dry-run時に注意して確認する。
正常に置換されていない場合、手元ではURLを囲む引用符をシングルクオート→ダブルクオートに変更したところ正常に置換できた。
別解:別途DBを作成して切り替える方法
既存のDBに直接インポートする代わりに、新しいDBを作成してSQLファイルをインポートし、WordPressの接続先を切り替える方法もある。
この方法なら既存のDBを残しておけるため、問題が発生した場合も接続先を戻すだけで切り戻しができる。特にローカルから本番環境へDBを反映する場合に有効。
手順は以下のとおり。
- 新しいDBを作成する
- 新しいDBにSQLファイルをインポートする
wp-config.phpのDB接続先を変更する- 動作確認し、問題があれば元のDBに戻す
DBの作成とインポートは、MySQLコマンドなどで行う。
mysql -u DB_USER -p -e "CREATE DATABASE wordpress_new CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;"
mysql -u DB_USER -p wordpress_new < production.sql
新しいDBに接続できるよう、DBユーザーの権限も確認しておく。
DBの切り替えは、wp-config.phpのDB_NAMEを変更する。WP-CLIからも変更できる。
wp config set DB_NAME wordpress_new
なお、DBの切り替えだけでは、切替後に発生した投稿・注文・問い合わせなどの更新データは元のDBに反映されない。また、テーマ・プラグインやアップロードファイルも切り戻しの対象にはならないので注意が必要。