WordPress環境の移行方法(サーバ移転、環境構築)まとめ

このページは約8分で読み終わります

後で読む

  • このエントリーをはてなブックマークに追加

少し踏み込んで、WordPress環境の移行(引っ越し)作業についてご紹介します。

まずは基本的な移行方法についてご紹介しつつ、移行に伴う様々なリスクや予備知識についても触れていきます。

文字起こしをすると一見長くも見えますが、慣れるととても簡単&柔軟性があり小回りが効くのでとても便利な方法です。

最初に一番大切なことを書いておきます。

1にも2にもバックアップです。移行前のデータ、移行後のデータそれぞれを必ず反映前に取得しておきます。そうすれば何かトラブルがあっても元通りに復元できます。

WordPressの推奨動作環境

WordPressの動作には以下が必要となります。(WordPress公式のRequirementsより)

・PHP 7.2以上
・MySQL 5.6以上 または MariaDB 10.0以上
・Apache または Nginx

この他にも、環境を手配する際、個人的には以下を基準にしています。

・メモリ : 8GB (4GB以上)
・CPU : 2コア以上
・OS : Linux系 CentOS / RedHat
・PHPモジュール
 - php-mysql
 - php-gd
 - php-mbstring
 - php-mcrypt
・DBの照合順序 : utf8mb4_general_ci または utf8_generai_ciで作成

以下は補足です。

メモリ

メモリは1GB程度でもWordPressの動作は可能ですが、アクセス負荷に伴い503エラーが発生しやすく「503 Service Unavailable」「Service Temporarily Unavailable」が出る可能性が高くなります。ある程度の同時アクセス数が見込まれる場合、メモリはある程度確保しておいたほうが安心です。

PHPモジュール

PHPモジュールは上記4つのライブラリがないとWordPressは正常動作をしません。最悪php-gdライブラリはなくても問題ありませんが、WordPress上でメディアの編集が行なえない制約が伴います。

データベースの照合順序

MySQL5.3.3以上のWordPressにおいては、新規インストールの場合DBの照合順序については、4バイト文字の対応をしているutf8mb4が標準で適用されるようです。(MySQL5.3.3以前ではutf8でした)

移行先サーバのチェックリスト

以下は個人的に確認をしているWordPress移行をする前のサーバのチェック項目となります。

・移行予定のサーバ先ではWordPressは動作をするか
・MySQLが正常にインポートできるか
・(S)FTPで書き込み権限があるか
・移行先で既に他のWordPressやシステムが利用されていないか
・移行先で同じ階層にファイルやディレクトリが存在しないか

もし上記で課題が出た場合は、このページ下でご紹介する「リスク/不具合の把握と対処法」をご確認ください。

移行時に必要なサーバ情報

続いて移行に伴い、以下のサーバ接続情報を確認しておくようにします。

・データベース名
・MySQL データベースのユーザー名
・MySQL データベースのパスワード
・MySQL のホスト名
・(S)FTPのホスト名
・(S)FTPのユーザー名
・(S)FTPのパスワード

移行前の環境からはデータの取得、移行先の環境へはデータの反映が必要となるので、新旧の両環境の接続情報を確認しておくようにします。

作業手順

それではいよいよ作業を行っていきます。

移行方法にはいくつかの選択肢がありますが、ここではSearch Replace DBというツールを使った方法をご紹介します。(その他の方法も後ほどご紹介するようにします)

1. 移行前のサーバからFTP情報を取得

移行前のサーバからWordPressのFTPデータを全てダウンロードしローカル環境に保存しましょう。以下のキャプチャはMacでTransmitというFTPクライアントソフトを利用しています。

2. 移行前のサーバからMySQLダンプデータの取得

レンタルサーバの場合、予めサービスとしてphpMyAdminが設置されている場合もあります。

もしサービス提供されていない場合は、phpMyAdminの公式サイトより無償ダウンロードができますので、ダウンロード後移行前のサーバ先にアップロードをするようにしてください。

ログインにあたり、データベースへのユーザ名、パスワードが必要となります。もし分からない場合には、先ほど取得したFTPデータの中にある「wp-config.php」を開いてください。すると以下のような記述箇所があります。

/** WordPress のためのデータベース名 */
define('DB_NAME', 'database_name_here');

/** MySQL データベースのユーザー名 */
define('DB_USER', 'username_here');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'password_here');

 ここに記載されている「username_here」と「password_here」がphpMyAdminでログインをする際のユーザー名、パスワードとなります。

ログインをすると以下のような画面となります。

blank

「エクスポート」タブに遷移すると、エクスポート方法に簡易と詳細がありますが、「簡易」のままで問題ありません。

フォーマットは「SQL」のまま、エンコーディングへの変換は「なし」のまま「実行」をしてください。MySQLデータをダウンロードできます。

blank

3. 移行後のサーバへFTPデータの反映

いよいよ移行後のサーバ先にデータを反映していきます。

もし既に何らかのファイルが存在する場合は、事前にバックアップを取得しておいてください。何か不具合が発生した際の切り戻し用に利用します。

移行先の(S)FTP先にログインをし、FTPデータを反映してください。この際、階層構造は移行前と必ず揃えるようにしてください。

blank

その後、サーバにアップロードしたwp-config.phpを開いてください。移行先サーバのデータベース情報を入力する必要があります。

/** WordPress のためのデータベース名 */
define('DB_NAME', 'new_database_name_here');

/** MySQL データベースのユーザー名 */
define('DB_USER', 'new_username_here');

/** MySQL データベースのパスワード */
define('DB_PASSWORD', 'new_password_here');

/** MySQL のホスト名 */
define('DB_HOST', 'new_host_name_here');

 に正しいデータベース情報を登録してください。

4. 移行後のサーバへMySQLダンプデータの反映

移行先のphpMyAdminにログインをします。

「2.」と同様にphpMyAdminがサービス側に存在しない場合には、手動でphpMyAdminをダウンロードしてきてサーバに合わせてアップロードするようにします。

blank

「インポート」タブに遷移後、「2.」で取得したMySQLダンプデータを選択します。その後、デフォルトの設定のままページ下までスクロールし、「実行」を押してください。

ダンプデータが正常にインポートされれば完了です。

blank

5. データベース内の文字列を置換

ここがポイントになります。

「1.」〜「4.」の作業で新しいサーバ先にFTPデータ、MySQLデータの反映はできましたが、データベース内部のパス構造が移行前の旧サーバ情報を参照している状態となります。

移行先の新サーバのドメインに変更をする必要がありますが、phpMyAdminからSQL文で一括変更しても一部のシリアライズ化されたデータは置換されず移行前のサーバを参照しています。

そこで登場するのがSearch Replace DBというツールとなります。

blank

ツールをダウンロードします。(※現在のリリースバージョンは3.1.0となり、2系のツールとは操作方法が異なります)

ダウンロードするには以下の利用規約への同意を3つすることで、メールアドレス入力欄が表示されます。

blank

その後「Submit」を押すと、入力したメールアドレス宛にダウンロードリンクが記載されています。

blank

現在のメールではバージョンが3.1.0、2.1.0両方のダウンロードが行なえます。2.1.0の方が1ファイルのphpファイルをアップロードするだけで楽なのですが、ここではphp7にも対応している3.1.0で紹介をします。

ダウンロードしたzipファイル「Search-Replace-DB-3-1-0-emaildownloads.zip」を解凍します。

解凍したフォルダ「Search-Replace-DB-master」を適当な名前でリネームしておき、「3.」のように移行先の(S)FTPサーバにアップロードします。

アップロードする階層はWordPressを設置したディレクトリ直下、/wp-admin/等と同じ階層化で問題ありません。

blank

URLを直接叩きます。ドメインが「http://example.com」とし、上記のようなフォルダの場合、下記のURLを開いてください。

http://example.com/SDR/

すると以下のような画面が表示されます。

blank

順番に見ていきます。

search/replace

replace 「移行前のドメイン」with「移行後のドメイン」として入力します。「http」や「/」は入れず、「http://example.com/」であれば「example.com」と入れてください。

1. database

databaseには自動的にWordPressのwp-config.phpファイルより情報が入力されています。(「3.」で登録した情報が正しければ動作します。)

もし何も表示されていない場合には手動入力でも動作します。

2. tables

もしサーバ内に既に他のシステム等でデータベースが利用されている場合、必ず「select_table」を選択してください。デフォルトでは該当データベース内のテーブル全てが選択されています。

今回WordPressのみで必要となる該当のテーブル行を手動選択します。(複数選択できます。)

blank

3. actions

ここまでで問題なければ「dry run」を試しに押してみてください。テスト試行が行えます。

特に大丈夫そうであれば続いて「live run」を押します。こちらが実際にドメインの置換作業をするボタンとなります。

ここまでの作業が終わったら、移行先のサイトを開いてみてください。正常に表示されていれば一先ずは反映作業は完了となります。

また最後に、必ず忘れずにアップロードした「Search Replace DB」のフォルダを削除してください。(セキュリティ上の不正改ざんのリスクとなります。)

動作確認の実施

反映後の動作確認を行います。

主なチェック項目は下記となります。

・トップページが表示されているか
・下層ページが404にならず表示されているか
・下層ページが移行前のドメイン先のままになっていないか
・管理画面にログインが行えるか
・記事作成が行えるか
・画像がアップロードできるか
・管理画面、もしくはフロントでエラーが出ていないか

下層ページが表示されない、または移行前のドメイン先に遷移してしまう場合、「5.」で行ったドメインの置換作業でミスがある可能性があります。

再度移行前、移行後のドメインを確認するようにしてください。

また互換性の問題で移行先のサーバでエラーが出ている可能性もあります。サイトの表示側はもちろん、管理画面の各ページを確認し正常に表示されているか、エラーメッセージが出ていないか等確認をしてください。

パーミッションの調節

画像を管理している「/uploads/」であったり、キャッシュプラグインを利用している場合「/cache/」ディレクトリなど、書き込み権限が必要となります。

それぞれ適切なパーミッションを変更し書き込みできるようにしておきます。

リスク/不具合の把握と対処法

数百と環境移行をする中で様々なトラブルがありました‥。ここではその中でのあるあるを書きたいと思います。

サーバ移転と一口に言っても

・サーバスペックを変更したいので、別のサーバへ移転をしたい
・ステージング環境から本番環境に反映をしたい

といった状況があります。

どちらのケースにせよ移行前の旧環境と、移行後の新環境におけるミドルウェアのモジュールやバージョン、設定の差により予期せぬトラブルになることがあります。

また、レンタルサーバ、専有サーバ、VPNサーバ、クラウドの他、イントラネット環境下など様々な環境があります。特にroot権限が持てる環境であればさほど問題にはなりませんが、レンタルサーバであったり、何らかの事情でroot権限がない、SSHが使えないといった場合が考えられます。

特に既存のサーバを利用する場合は要注意で、予め移行先の環境を確認しておくようにしましょう。

サーバ移転は当日での実施にはせず、事前に反映テストを行うと安心です。

1. phpMyAdminが利用できないケース (1)

権限不足のケースです。移行先のサーバ上でphpMyAdmin自体が利用できない、セキュリティの都合上、利用が制限をされていることがあります。その場合MySQLのダンプデータ反映にあたり、権限がある人に予めMySQLの反映方法の確認をしておくようにします。

2. phpMyAdminが利用できないケース (2)

ダンプデータのサイズが大きいケースです。phpMyAdminの利用はできるものの、MySQLのダンプデータ容量が大きくインポートの際にタイムアウトになることがあります。その場合、以下を検討します。

[1] .htaccessに以下を書き加える。

php_value memory_limit 80M
php_value post_max_size 80M
php_value upload_max_filesize 80M

◯Mのサイズは適宜変更します。変更してもphpMyAdmin内のサイズが変わらない場合、Apacheの再起動が必要となります。

[2] BigDumpツールを利用する 参考URL
 大容量のMySQLデータベースを取り込むことのできるphpファイルです。

[3] Sequel Proアプリを利用する 参考URL
 これはMacかつSSH情報がある場合に限りますが、サーバ内に余計なファイルを作らず、通信も暗号化され、タイムアウトもせず大容量(数百MBでも)ファイルをインポート・エクスポートが行えます。

[4] phpMyAdminでインポートファイルを分割する
 MySQLをインポートする際、サイズが重たいことでタイムアウトするので、エクスポート時に分割をしておきます。特にデフォルトの接頭辞で書けば「wp__postmeta」「wp_posts」が重たいことがあります。phpMyAdminでその特定のテーブルを選択し、エクスポート時に「詳細 > ダンプする行」から分割してエクスポートするようにすることで回避できます。

3. phpMyAdminが利用できないケース (3)

旧環境のphpMyAdminからMySQLデータを正常にエクスポートできないケースです。上の「2」の[4]と同様に、旧環境のMySQLデータがタイムアウトで正常に取得できないことがあります。エラーも表示されないこともあるので気づきにくいですが、全ての行が正常にエクスポートできないことでサーバ移転時に不具合の原因となります。

インポート、エクスポート時にテーブルの行数が一致するか確認をするようにします。例えば「128,473」行あるはずが、移行先の環境では「42,674」行しかない、といったことがあります。

phpMyAdminは利用せず、プラグインにより解決することがあります。「WP-DB-Backup」でMySQLデータの取得が可能です。

4. FTPの書き込み権限がないケース

FTP、SFTP、FTPSいずれの場合でもそうですが、ファイルをアップロードする際、特定のディレクトリ領域先に書き込みをする権限がないことがあります。

サーバ管理者に問い合わせをし権限を付与してもらう、またはファイルを置いてもらうようにします。

5. FTP内のディレクトリ名、ファイルが衝突するケース

いざ移行先の環境に反映をしようとすると、既に同じディレクトリが存在することがあります。移行前の環境のファイル/フォルダと、移行後のファイル/フォルダで重なってしまうところがないか確認をするようにします。

重なる場合には、どちらかのファイル/フォルダ名を変更しておくようにしましょう。同名URLは共存できません。

事前にページリストを取得し、衝突が起きないように命名規則をつけましょう。URL取得にあたってはScreaming Frog SEO SpiderIntegrity Plusなどのツールがあります。

6. MySQLのテーブル名が衝突するケース

MySQLをインポートしようとする際、既に利用されているデータベースかつWordPressが使われている場合衝突する恐れがあります。

特に「wp_」はWordPressデフォルトの接頭辞となるので、移行前の環境、または開発環境において同一の名称とならないよう配慮しておく必要があります。

7. 画面が真っ白になるケース

別記事「WordPressサイト公開(環境移行)時のよくあるエラーまとめ」でも紹介しておりますが、移行先のWordPress環境が白くなるケースがあります。とりわけショートタグが利用できない設定になっている事も多いので、白くなる場合は上記URLを確認してください。

8. phpモジュールが不足しているケース

WordPressの動作にあたり、サーバにはいくつかのphpモジュールが必要となります。「php-mysql」「php-gd」「php-mbstring」「php-mcrypt」がインストールされているか確認をするようにしてください。

確認にあたり、phpの設定情報を出力するphpinfoを利用するのが便利です。以下を適当な名前(info.php)でサーバにアップロードし確認をするようにします。(確認後は該当ファイルを削除します)

<?php
phpinfo();
?>

※これ自体はWordPressが正常に動いている場合は確認は不要です。

プラグインによる引越し作業

ここまでは「Search Replace DB」ツールを使った引越方法をご紹介してきました。

これはどんな場合でも対応できるのでお勧めの方法ですが、プラグインによる反映方法もあります。

All-in-One WP Migration

blank

All-in-One WP Migration

「All-in-One WP Migration」はユーザー評価も高く、利用者数も900,000サイト以上、更新頻度も高めな安定感のあるプラグインです。

使い方も洗練されていてとてもシンプルです。

利用手順について

プラグインをインストール、有効化します。

All-in-One WP Migration > エクスポートを開きます。すると以下のメニューが表示されます。

blank

オプションとして「高度なオプション」をクリックすると以下のメニューが表示されます。意図的に除外したいものがない限りここはこのまま何もチェックしないで問題ありません。

blank

エクスポート先からは「ファイル」を選択します。するとローカル環境にバックアップファイルがダウンロードが開始されます。

blank

ファイルを押すと以下のようになります。

blank

blank

正常にプロセスが終了すると、下記のようにダウンロードボタンが表示されます。添付画像では160MBと表示されています。

ここにはFTPデータ、MySQLデータが全て格納されています。拡張子は「.wpress」という独自の拡張子ファイルになります。

blank

移行先の空のWordPressにもAll-in-One WP Migrationをインストールし、有効化します。

All-in-One WP Migration >インポートを開きます。

先ほど取得した「example.com-20180116-033535-270.wpress」のファイルを画面内にドラッグします。

blank

すると以下のようなアラートが表示されます。

「既にあるデータベース、メディアファイル、プラグイン、テーマ全てが上書きされるけど大丈夫?次のステップへ進む前に環境のバックアップを取っておいてね」と書かれています。

問題なければPROCEEDを押します。

blank

すると復元が開始されます。ファイルの復元‥

blank

そしてデータベースの復元を行います‥

blank

しばらく待つと下記画面が表示されれば完了です。

blank

上記画面が出たら一先ず完了です。

WordPressが旧環境から、新環境先へ全てのWordPressデータが複製されています。

WordPress以外のファイルを反映

ただこのままではデータが不足している可能性があります。例えばWordPress外で管理されているcssやJavaScript、画像などは移行されません。

もし独自に「/common/css/」等を作成している場合、移行前の旧サーバからデータを取得し、移行先の環境に反映をしてください。

また「robotx.txt」「.htaccess」であったり、Googleの認証ファイル「google900b4d5e5259a86x.html」のようなファイルもアップロード対象外ですので、手動反映が必要となります。

利用時の留意点

標準のフリー版では利用に制限事項があります。

マルチサイトで有効化すると以下アラートが表示されます。

blank

マルチサイトでは別途「Multisite Extension」版の購入$199が必要です。

またインポート時に下記が表示されます。

blank

標準ではファイルアップロードサイズが512MBに制限されています。容量無制限での利用には「Unlimited Extension」版の購入$69が必要です。

それぞれ有償版の購入をするのもアリですし、状況によりSearch Replace DBツールと使い分けると選択肢も多く安心かと思います。

まとめ

要点をまとめると以下のようになります。

  • 作業前には、移行前、移行先のFTPデータ、MySQLデータのバックアップは必ず取得しておく。
  • 移行先サーバは新規となり、中身が空っぽである。またWordPressサイトも規模感が小さく(512MB以下)、かつマルチサイトを利用していない。そんな場合は「All-in-One WP Migration」プラグインを利用
  • それ以外の場合「Search Replace DB」ツールを利用

最後までお読み頂きありがとうございます!

  • このエントリーをはてなブックマークに追加
bitFlyer ビットコインを始めるなら安心・安全な取引所で