このブログ、比較的重めな画像を扱うがゆえに読み込みが遅く、ときおりサーバーごと落ちることもあったので、メモリ1G×CPU2コアから脱却しつつストレージもSSDにアップグレードすることにしました。色々考えた結果、新しいサーバーは『ConoHa』にすることにしたので、思うところや作業の備忘録を書き連ねていきます。
また、今回のサーバー移転の特徴として、
という点を事前に挙げつつ、見ていきましょう。
旧サーバーにログインして「df -h」にてストレージ使用量を確認し、移転先の新サーバー選定の参考にします。
未圧縮の写真をガンガン投稿しているこのブログでも、なんと5年の更新で9GB程度しか使っていませんでした。ちなみにConoHaのSSDは原則として50GB。問題なさそうです。
やることがたくさんあり過ぎて作業履歴をそのまま掲載しても残念なことにしかならないので、ざっと箇条書きで確認していきます。
旧サーバーのWordpressファイルをディレクトリごとローカルにダウンロードします。
Terminalでそのままやってもいいし、何かSCPクライアントを使ってもいいですが、今回はSCPクライアントでダウンロードしました。
さきほど旧サーバーからダウンロードしたディレクトリを、新サーバーの/var/www/html直下にアップロードし、適宜ディレクトリ名を変更します。また、WordPressがファイル操作できるように所有者、所有グループはapacheに変更しておきます。
chown -R apache:apache /var/www/html/DirectoryName
基本的にはそのままアップロードでよいのですが、データベースの設定を変えた場合はwp-config.phpを開いて接続設定を書き換えておきます。
vim /vaw/www/html/DirectoryName/wp-config.php
-> define('DB_NAME', 'xxxxx');
-> define('DB_USER', 'xxxxx');
-> define('DB_PASSWORD', 'xxxxx');
-> define('DB_HOST', 'xxxxx');
旧サーバーにログインして、Wordpress用データベースをSQL形式のdumpとしてまとめてエクスポートを実行します。
mysqldump -u UserName -p DatabaseName > DumpFilePath
旧サーバーにてエクスポートしたdumpをscpか何かで新サーバーに送付し、新サーバーにてインポートを実行します。
mysql DatabaseName < DumpFilePath -u UserName -p
そして今回一番ハマったのがこちら。
今回はバーチャルホストを新規設定したためにドキュメントルートを明示的に記述したのですが、これによって旧サーバーのドキュメントルートと食い違いが発生し、この時点でまだサイトが開けないようになっていた模様です。
具体的には、旧サーバーでは以前Wordpressをインストールした際、「/var/www/html/wordpress」としてインストールしたものの、バーチャルホストの設定がなかったためにドキュメントルートが暗黙的に「/var/www/html」となり、設定のWordpressアドレスにて「http://takuminasuno.com/wordpress」と帳尻合わせがされることで読み込めていたようです。ちなみにWordpressアドレスと併記されるサイトアドレスは「http://takuminasuno.com」となっており、ここに差分ができていたことになります。
一方の新サーバーは、ドキュメントルートを「/var/www/html/wordpress」と明示的に書いたため、各ファイルを参照しようとすると「/var/www/html/wordpress/wordpress」を探しに行ってエラーが起きていた、というのが真相のようです。
対策としては、データベースにある情報の一括書き換えが必要でしたので、『Search and Replace for WordPress Databases Script』という専用ツールを使って「takuminasuno.com/wordpress」を「takuminasuno.com」のような感じで一括置換しつつ、古いIPアドレスも全て新しいIPアドレスに置換しました。
なお、置換だからと言ってSQL文を書いて単純置換すると、シリアライズされた文字列が残ってバグるので、手抜きせずに専用ツールを使う必要がある点は注意しましょう。
これにて一件落着。
失敗すると怖いので、DNSのAレコードを再設定してドメインを新サーバーに適用する前に、サイトが正しく動くかhostを変更して確認します。
macの場合はTerminalにて「/etc/hosts」、Windows10の場合は「C:\Windows\System32\drivers\etc\hosts」に新しいIPアドレスとURLを半角スペースで繋いで追記すれば、DNSのAレコード変更前でも新しいサーバー(IPアドレス)で正しく動くか確認できます。
このブログのドメインはお名前.comにて取得しており、お名前.comのネームサーバーをそのまま使用しているので、お名前.comの管理画面から該当ドメインのDNSレコードを再設定します。
具体的には、お名前.comにログインして「DNS」タブから「ドメインのDNS関連機能設定」を開き、該当ドメインの「DNSレコード設定を利用する」にて「登録済みAレコード」のVALUEにて新しいIPアドレスに書き換えました。
ネームサーバーの移転はなく、DNSレコードの再設定のみですので、数時間ほどで新しいサーバーを参照するように切り替わりました。これにてサーバー移転が完了です。
【注意】2018/9/20追記。今回はこの方法で新しいサーバーに切り替わった(と思われる)のですが、DNSは闇が深いようで。ネットではいわゆる浸透待ちに嘆く投稿が多くある一方、浸透待ちは都市伝説と称してネームサーバー並行稼働と切り替えを推奨する投稿も散見されますが、どちらも正しくない可能性すらあるようです。私の現時点の知識では何とも言えないので、自分で知識を持って自己責任で進めるようお願いします。
WordPressのサーバー移転についてググってみると、専用ツールを使ったり、Wordpressのインポート/エクスポート機能を使ったりなど色々な方法が見つかりますが、やはり一番シンプルなのはデータベースとファイルを落としてそのまま放り込みつつ、wp-config.phpだけを書き換える方法だと思います。
とはいえ今回は、バーチャルホスト新規設定に伴ってドキュメントルートの食い違いが意図せず起こってサイトが開けなくなるトラブルが発生したので、なかなか普段やらないサーバー作業は勉強になるなあ、と感じた次第です。
さて、サーバー移転に無事成功しましたので、サーバーの応答時間を早速計ってみました。計測はグーグル先生(PageSpeed Insights)です。
モバイル 1.9秒 ⇒ 0.24秒
パソコン 2.1秒 ⇒ 0.26秒
圧倒的ですね。サーバーを変更、というよりかは本質的にはHDDをSSDに変更したら応答時間が劇的に改善されたので、やっぱり今の時代はSSD一択だと思いました。