実際にDatabase Migration Service(以下、DMS)を使った移行を行ってみます。慣れ親しんだWordPressで試してみました。
想定される背景
次のようなシーンを想定しています。
メディアサイトを専用サーバー上でWordPressで運営していた。ところが、アクセス数が伸びてきたため表示が遅くなってきており、このままではサイトの表示ができなくなりそう。。。そこでスペック調整がかんたんなAWSへ移行を決めました。
希望としては、常時アクセスがあるメディアのため、できる限りメンテナンスタイムは発生させたくない。
通常のアプローチ
通常のアプローチでは大まかには以下の流れになります。
- 移行先でWordPressをインストール
- 事前に移行元のWordPressのファイルをコピーしておく
- 移行元のWordPressをメンテナンスのため停止します ※ メンテ開始
- 移行元のWordPressのデータベースのダンプを取得 ※ 5分〜
- 移行先へダンプをコピーしデータベースのリストア ※ 10分〜
- 移行先へ差分ファイルのコピー ※ 12分〜
- DNSのAレコード変更 ※ 15分〜経過
WordPressのデータが極めて小さい想定で、スムーズに進んで15分程度、実際には余裕をみて30分程度で計画します。データ量が多ければ数時間かかります。 DMSを利用することで、DNS切り替えまでにかかる15分〜数時間のメンテナンス時間をなくせます。
DMSを使ったアプローチ
実際に、DMSを使ったアプローチを紹介します。 前提条件としては以下を想定しています。
- 移行元と移行先のWordPressおよびMySQLのバージョンは同一に揃えておきます
- 移行先のWordPressはEC2の1台構成
移行元のWordPress
移行元サーバーのTOPページがこちらです。
今回はこのサイトを移行させます。
ステップ1：AWS側にサーバーを用意する
まずは移行先となるAWSでWordPressを動作させる環境を準備しておきます。
こちらの手順を利用して、ec2インスタンスを作成します。
WordPressで使用するmysqlのバージョンは過去サーバーに合わせるため、移行元になるサーバーでバージョンを確認します。
<移行元サーバーで実施> $ mysql -V mysql Ver 14.14 Distrib 5.6.41, for Linux (x86_64) using EditLine wrapper
5.6.41でした。移行先のamazon linux2では何もレポジトリを追加していない場合にはmariaDBが入りますので、レポジトリを追加します。
<移行先サーバーで実施> # wget http://dev.mysql.com/get/mysql-community-release-el7-5.noarch.rpm # rpm -Uvh mysql-community-release-el7-5.noarch.rpm
5系の公式レポジトリを追加しました。listで項目が追加されているか確認します。
<移行先サーバーで実施> $ yum list available | grep "mysql" ~~~~~~~~~~~~~~~~~ mysql-community-client.i686 5.6.41-2.el7 mysql56-community ~~~~~~~~~~~~~~~~~ mysql-community-server.x86_64 5.6.41-2.el7 mysql56-community ~~~~~~~~~~~~~~~~~
5.6.41ですので、移行元と同じです。確認できたので、インストール。
<移行先サーバーで実施> # yum install -y mysql mysql-server
こちらでインストールが完了しました。が、DMSで移行できるデータは完全なコピーデータではなく、テーブル情報などはコピーされません。
そのため、一度完全なテーブル定義とDBの定義を移行しておきます。
<移行先サーバーで実施> # mysql -uroot -p mysql> create database DB_NAME; mysql> exit # mysqldump -u USER_NAME -p -h xxx.xxx.xxx.xxx(移行元IP) DB_NAME -d > output # mysql -u USER_NAME -p DB_NAME < output
こちらでテーブル定義などの移行が完了しました。
DMSの設定を行っていきます。
ステップ２：DMSの作成
DMSを作成して、DBを移行します。
作成画面はデフォルトを設定。インスタンスクラスは規模に合わせて設定しますが、今回はテスト用のデータですので、規模の小さいt2.microを選択しました。
こちらで移行元、移行先のデータを入力します。
今回はaws以外のサーバー→EC2インスタンスですので、両方サーバー名にはIPアドレスを入力、外部から接続を許可したユーザー、
パスワードを入力して接続テストを行い、接続が問題無い旨確認を取りました。
もし、ここで接続に問題がある場合には、正しくAWSからアクセスができるようにしているかを確認してください。
接続の確認ができたら、実際に移動させるデータの設定を行います。
今回は１度だけDBのデータをそのまま全移動させますが、前述の通り、DROPしてしまうと移行したテーブル情報などが抜けてしまうため、DROPではなくTRUNCATEを選択します。
尚、新規データは別にするなどデータの形を変えて入れたい場合には、画面下部の設定からマッピングの設定を入れて対応が可能です。
こちらで作成すると、データの移動が開始されます。
こちらのロードが１００％になっていれば完了です。今回はほぼ入れたばかりのWordPressのデータですので、即時で終了しました。
ここでうまくいかない場合
ユーザーにDBなどの権限が正しく付与されているかを確認してください。
移行先のDBが作れない、操作できない場合などエラーになります。
ステップ３：移行元からwordpressのファイル群をコピーする
こちらでDBのデータはコピーされましたが、添付画像などのデータはディレクトリの中に配置されているためまだ移動されません。
今回はrsyncを使いデータをコピーします。
<移行先サーバーで実施> rsync -avz root@xxx.xxx.xxx.xxx(移行元のIP):/var/www/html/ /var/www/html/
こちらでファイルの移動も完了しました。実際の移行の場合にはドメインの登録を行っていると思うので、
hostsの書き換えなどで参照先IPを変更して参照し、問題が無いか確認して下さい。
画面表示してみた結果がこちらです。
問題ないことが確認できました。
ステップ４：継続的にDBの中身をコピーする
上記の操作を行い、動作に問題無いことが確認できたら、データの移動を継続的に行うように設定(レプリケーション)し、移行前のサーバーと移行後のサーバーを常時同じものにしましょう。
この操作を行うことで、どちらのサーバーにアクセスが来ても同じデータが表示されるようになります。尚、ファイルはこれで行えないので注意が必要です。
DMSを使ってmysqlでレプリケーションを行う場合には、MySQL バイナリログが必要になります。
デフォルトでは生成されないため、以下を設定してください。
<移行先、移行元サーバーで実施> $ mkdir /var/log/mysql $ chown -R mysql:mysql /var/log/mysql $ vim /etc/my.cnf 以下を追記 ~~~~~~~~~~~~~~~~~~~ # Binary log log_bin="/var/log/mysql/bin.log" ~~~~~~~~~~~~~~~~~~~
フォーマットはROWでなければならないため、mysqlも設定します。
$ mysql -uroot mysql> SET GLOBAL binlog_format = 'ROW';
こちらを設定した後、先程と同じようにタスクの新規作成を行い、移行タイプを「継続的な変更をレプリケーション」を選択します。
設定を完了すると、レプリケーション進行中のステータスが表示され、データのリアルタイムの複製が行われます。
こちらで設定完了ですが、DMSではUTF8MB4が非対応となっています。
WordPressをUTF8MB4で動かしていて、下記エラーが出た場合にはUTF8などに変更してから利用してください。
"[SOURCE_CAPTURE ]E: Column ‘<column name>' uses an unsupported character set [120112] A field data conversion failed. (mysql_endpoint_capture.c:2154)
レプリケーションの確認
DMSでレプリケーションすると、旧サーバーの記事への書き込みは新サーバーに即時反映されます。
データの更新は新サイトでも可能なため、新規投稿や設定の変更もできます。
しかし、旧サイトで変更があった場合にそのデータで新サイトのデータも更新されます。
そのため、旧サイトでの新規投稿が起きた場合は、新サイトの新規投稿への上書きになるため注意する必要があります。
尚、旧サイトが新サイトの影響を受けることはありません。
ex)新サーバーのデザイン変更をした場合には以下のように新サイトのみが変更されます。
新サーバー
旧サーバー
ステップ５：DNSの切り替えと後処理
後はDNSを切り替えれば移行完了です。
DNSの切り替えのため、移行元サーバーへアクセスされてしまう時間がありますので、DNSの変更が浸透する5分程度は2台のサーバーへアクセスされてしまうのは許容しましょう。
DMSマシンの停止と移行元サーバーの停止
移行が完了し、アクセスが移行先サーバーに移ったら作業はほぼ完了、後は移行時に使用したDMSの削除と、移行前のサーバーを停止してしまいましょう。
移行前のサーバーの停止はそれぞれ違うため割愛します。
DMSの破棄は、レプリケーションインスタンスより、削除を選択すれば可能です。
おわりに
DBのすべてのデータのダンプを取得して切り替えるよりも手順は増えますが、その分ダウンタイムや編集できない時間をほぼなくして移行ができました。
旧サイトの変更が新サイトへ送られるため、新サイトへの新規投稿などには気をつけないといけませんが、
新サイトの検証などを行う間旧サイトのデータを常時受け付けますので、再ロードの手間無くすこともできます。
データの移行を行う際には使用してみたらいかがでしょうか。
