先月、さくらレンタルサーバへの新サーバーへの移行を実施したので、忘れないうちにメモ。というかもうすっかり忘れてしまったので作業中のメモを見ながら記憶を辿ります。
概要
別に移行しないといけないという訳ではないけれど、まあ、やっておくかという事で実施。それに、Web画面のレスポンスに不満もあったので、多少なりとも速くならないかなというのもありました。
方法は、「移行ツール」というのが用意されているのでそれを使用。
ただし、いくつか制約事項あり。
私の場合はMySqlのバージョンが5.7だったので、それだとダメという事で、まずはMySqlのバージョンアップから行った。
[1]DBのバージョンアップ
↓
[2]新サーバーへの移転
DBのバージョンアップ
DBのバージョンアップは、現行のDBはそのまま維持され、現行DBを基に別のDBサーバーに新バージョンのDBを作成するイメージです。つまりやり直しは効くし、確認して問題なければアプリ側を新に切り替え。切替後に不具合が発見されたらアプリ側の接続先を戻すことで、旧DBへの切り戻しも可能です。新DB作成中も現行アプリは使用可。
注意事項は、新DBの作成後、アプリの接続先切り替えまでの間に、旧DBにアップデートが発生したら、それは新には反映されないので別途手動で旧→新への移行が必要です。もちろん、更新が頻繁にあるなら、画面を非公開にして作業すればいいけど、更新系のものがなければそもそも気にする必要はありません。
私の場合は、アクセスログと、ブログやホームページのコメント、掲示板、各画面の「いいね」がユーザートリガーのトランザクションになります。まあ、アクセスログ以外は滅多に発生しないので特に画面は閉じずに進めました。
<手順>
1.移行ツールによる新DB作成、作成後軽く確認
2.新DBの個別対応テーブル(ユーザートリガーの追加更新テーブル)のTruncate
3.アプリの接続先を新DBへ切り替え、切替後軽く確認
4.個別対応テーブルのexport、import
データベース移行対象
結構ありました。DBが11個。
WordPress
放置中の物やテスト的なのも含めてWordPressが9個。放置中の物はこの際整理しようかとも思ったけど、メンドウなので放置継続。ユーザートリガーの更新テーブルはコメントなど、WordPressにもあると思うが、ほぼほぼスパムコメントしか発生していないのでそれについては気にしないことにする。
WordPress以外
自分で作ったブログ、SNS、掲示板、コメント、いいね、アクセスログなど。DBとして3つ。(内1つはWordPressと同じDBに間借り。)
このうち、掲示板、コメント、いいね、アクセスログは、ユーザーがトリガーなので切り替え中も追加・更新の可能性あり。ただ、ほぼ追加のみ。更新は掲示板の記事の削除(ステータスの更新)のみ。
切替作業対象
接続先データベース名の変更。WordPressの設定ファイル(wp-config.php)9個、WordPress以外の設定ファイル2個。
個別対応テーブル
切替中に追加がある物は、切替後にデータを特定して対応するのが面倒なので、新テーブルを空にすることにした。この方法は追加onlyでユーザーがデータを参照しないケースのみ可能。
1.新DB作成後、新の該当テーブルをtruncate。
2.接続先の切替後、旧のテーブルをexport。
3.新へのimport前に、新へ追加されている件数など確認
4.exportデータを新テーブルにimport
注意点
auto incrementカラムとdeleteかtruncateか
auto increment項目を持つテーブルの場合注意が必要。新作成後に旧でauto incrementが採番され切替後かつimport前に新にデータが発生してauto incrementが採番されると重複してしまう。
また、auto incrementは、deleteの場合リセットされないがtruncateの場合はリセットされてしまうのでその点も注意。auto increment採番値を通常のカラムとして持つテーブルがあれば整合性が損なわれない様に注意。
尚、今回はauto incrementのあるテーブルで上記の個別対応はしていない。
更新
更新(update)については、新DB作成後から切り替えまでの間に旧に生じた更新をどうするか。また、新に切替後に生じて旧の変更を新に適用する前に新にも変更が生じるケースをどうするか。
これは、今回だと掲示板やコメントのステータス変更(削除)のみ該当するが、発生確率的に極めて低いので、作業後に発生有無を確認して発生していたら個別対処する事に。また、WordPress関連はスパムコメントしかないのでスコープ外とする。
実施時の問題点
特になし。
新サーバーへの移転
これは、移行のため切り戻しは出来ない。なにか問題があっても対策前進で対応するしかない。
<手順>
1.現行確認(.htaccessの内容、PerlやPHPのバージョンなど)
2.移行ツール実行(実行予約)
3.稼働確認
4.perlプログラムの修正
.htaccessの内容によっては制約があったため、事前に確認、またperlやphpのバージョンを控えた。
移行作業中はアクセス不可となるので土曜の夜間に実施。
実施時の問題点
perlのプログラムが動かなくなった。以前perlバージョンを試しに上げてみた時も動かなくなったので、何かあるだろうとは思っていた。
調べたら、decode_utf8のところでダメみたいなので使わないようにした。いったんencodeしてdecodeなら動いた。直ったので深く追求せず。
レスポンスの改善状況
気持ち速くなった気がする。
大体そんな感じ。
コメント