1. 目的
- AWSのデータベース関連サービスの復習をしている。AWS Database Migration Service (DMS)を使ってDBを移行するプロセスを理解する。
2. やったこと
- EC2インスタンスにWordPressを構築する。WordPressが使用するDBとして、EC2インスタンス内にMariaDBをインストールする。
- EC2インスタンスにインストールしたMariaDBのデータを、RDS(MariaDB)にDMSを用いて移行する。
- WordPressのDB参照先設定をRDS(MariaDB)に切り替えて、問題なく動作することを確認する。
3. AWS Database Migration Service とは(自分の理解)
- オンプレミスや他社クラウドで稼働するDBをAWSへ簡単に移行させることができるツール。
4. 構成図
5. 実機確認手順
5.1 全体の流れ
- EC2インスタンスにWordPressをインストール(移行元となるMariaDB 5.5をEC2インスタンス内にインストール)
- 移行先のRDS(MariaDB 10.4)を作成
- DMSのレプリケーションインスタンス(データ移行を行うインスタンス)を作成
- DMSのソースエンドポイント(移行元への接続情報)、ターゲットエンドポイント(移行先への接続情報)を作成
- データベース移行タスクを作成し、データ移行を開始
- データ移行完了後、WordPressのDB接続設定を、EC2インスタンス内のMariaDBからRDS(MariaDB)へ変更
5.2 EC2インスタンスの作成とWordPress/MariaDBのインストール
-
事前にVPC及びサブネット(構成図の通り)を用意しておく。
-
EC2にWordPressをインストールする手順の記事「【超初心者向け】WordPressをAmazon EC2インスタンスにインストールする」を完全にそのまま実施する。(丁寧な解説のある素晴らしい記事)
-
この手順によってインストールされるMariaDBのバージョンは5.5.68となる。
[ec2-user@ip-10-0-1-76 ~]$ rpm -qa | grep -i mariadb
mariadb-libs-5.5.68-1.amzn2.x86_64
mariadb-server-5.5.68-1.amzn2.x86_64
mariadb-5.5.68-1.amzn2.x86_64
5.3 移行先のRDS(MariaDB 10.4)の作成
- 移行先となるRDS(MariaDB)DBインスタンスを作成する。
- RDSのMariaDBは5.x系は既に利用不可のため、デフォルトのバージョン(10.4.13)を選択する。
- 移行元EC2インスタンスと同じVPCに起動し、同一VPCからの接続は許可するようセキュリティグループを設定する。
5.4 DMSのレプリケーションインスタンスの作成
- DMSでデータ移行を行うためのレプリケーションインスタンスを作成する。レプリケーションインスタンスが移行元DB、移行先DBの両方と接続して、移行元からデータを抜き出し移行先へ書き込む役割を担う。
- マネージメントコンソールにて、「DMS > レプリケーションインスタンス > レプリケーションインスタンスの作成」の画面を開き、移行元EC2インスタンス及びRDS DBインスタンスと同じVPCを選択してレプリケーションインスタンスを作成する。
5.5 DMSのソースエンドポイント、ターゲットエンドポイントの作成
- ソースエンドポイント(移行元DBへの接続情報)、ターゲットエンドポイント(移行先DBへの接続情報)を作成する。
5.5.1 ソースエンドポイントの作成
- まずソースエンドポイントを作成する。「DMS -> エンドポイント -> エンドポイントの作成」から設定を行う。
- 「サーバー名」にはEC2インスタンスのプライベートIPを入力する。
- 「エンジン」として「MariaDB」を選択すると、MariaDBの場合に必要な入力欄が表示される(ログインID/パスワード、port番号など)
- 作成したソースエンドポイントを選択し、「接続 > 接続テスト」を実行すると、「Failed」になってしまった。
- MariaDBが外部からのroot接続を拒否する設定になっていたため、以下の設定変更を行った。
- 設定方法は「外部のホストから接続できるようにする方法」を参考にさせて頂いた。
MariaDB [(none)]> select user, host from mysql.user;
+----------------+-----------+
| user | host |
+----------------+-----------+
| root | 127.0.0.1 |
| root | ::1 |
| root | localhost |
| wordpress-user | localhost |
+----------------+-----------+
4 rows in set (0.00 sec)
MariaDB [(none)]> grant all privileges on *.* to root@"%" identified by '[PASSWORD]' with grant option;
Query OK, 0 rows affected (0.00 sec)
MariaDB [(none)]> select user, host from mysql.user;
+----------------+-----------+
| user | host |
+----------------+-----------+
| root | % |
| root | 127.0.0.1 |
| root | ::1 |
| root | localhost |
| wordpress-user | localhost |
+----------------+-----------+
5 rows in set (0.00 sec)
- 再度接続テストを行い、成功することを確認した。
5.5.2 ターゲットエンドポイントの作成
- 次にターゲットエンドポイントを作成する。「DMS -> エンドポイント -> エンドポイントの作成」から設定を行う。
- 「RDS DBインスタンスの選択」にチェックを入れることにより、既存のRDS DBインスタンスの中から、ターゲットにするDBインスタンスを選択することができ、それに伴いARNなどの情報も自動入力される。
- ソースエンドポイント同様、「接続 > 接続テスト」を実行し、接続が成功することを確認する。
5.6 データベース移行タスクの作成
- データベース移行タスクを作成する。タスクの概念としては、レプリケーションインスタンスとソース/ターゲットインスタンスを紐づけて、レプリケーションインスタンスにソースからデータを取得させ、ターゲットにデータを書き込む作業をやらせるイメージ。
- 「DMS -> データベース移行タスク -> タスクの作成」から、タスクの作成を行う。
- 移行タイプとして、「既存のデータを移行する」「既存のデータを移行して、継続的な変更をレプリケートする」「データ変更のみをレプリケートする」の選択肢がある。データ移行中のソースDBの更新にも対応したいと思い、今回は「既存のデータを移行して、継続的な変更をレプリケートする」を選択する。
- エラー時の調査ができるように、CloudWatch ログを有効化した。また、CloudWatchログを使用するにあたり、別途専用のIAM Roleを作成する必要があり、「AWS DMS タスクの CloudWatch Logs が表示されないのはなぜですか? 」を参照して対応した。
- テーブルマッピングの設定を入れないとタスクが作成できないため、スキーマ、テーブルの全てをコピーするようなルールを設定した。
- タスクを開始したところ、以下のエラーとなった。
- 「Binary Logging must be enabled」となっているため、「MySQLのバイナリログを活用しリストア&リカバリで障害時でもDB完全復旧可能な体制を整える。」を参照し、EC2インスタンス内のMariaDBの設定変更を行い、バイナリログを有効化した。
/etc/my.cnf
[mysqld]
# 以下のBinary log 記載を追記
# Binary log
server-id=1
log-bin=/var/log/mysql/bin_log/mysql-bin-log
log_bin_index=/var/log/mysql/bin_log/bin.list
max_binlog_size=256M
expire_logs_days=2
[ec2-user@ip-10-0-1-76 ~]$ mkdir -p /var/log/mysql/bin_log
[ec2-user@ip-10-0-1-76 ~]$ sudo chown -R mysql:mysql /var/log/mysql/bin_log
[ec2-user@ip-10-0-1-76 ~]$ systemctl restart mariadb
- タスクを再実行したところ、また別のエラーで止まってしまった。
- 「Binary Logging must use ROW Format」ということで、DMSのドキュメント「Using a MySQL-compatible database as a source for AWS DMS 」に従い、さらに設定を2行追加した。
/etc/my.cnf
# Binary log
server-id=1
log-bin=/var/log/mysql/bin_log/mysql-bin-log
log_bin_index=/var/log/mysql/bin_log/bin.list
max_binlog_size=256M
expire_logs_days=2
binlog_format=ROW
binlog_checksum=NONE
- 「エラーを伴って実行中」という微妙な状態だが、タスクは実行されるようになった。
- この状態であれば、レプリケーションが実行されており、移行元のMariaDBへの変更が移行先にも自動反映されるはずのため、移行元の記事にコメントを追加した。
5.7 WordPressのデータベース設定の切替
- EC2インスタンスのWordPressのDBの参照先設定を、インスタンス内のMariaDBから、RDS(MariaDB)のDBインスタンスに変更する。
- 実行中のタスクの進行状況が100%であることを確認し、タスクを停止する。
- WordPressの設定を変更する。ホスト名はRDSのエンドポイントとし、接続ユーザもいったんRDSのadminとした。
/var/www/html/blog/wp-config.php
/** MySQL database username */
define( 'DB_USER', 'admin' );
/** MySQL database password */
define( 'DB_PASSWORD', '[password]' );
/** MySQL hostname */
define( 'DB_HOST', 'mksamba-mariadb.xxxxxxxxxxxx.ap-northeast-1.rds.amazonaws.com' );
[ec2-user@ip-10-0-1-76 blog]$ sudo systemctl restart httpd
[ec2-user@ip-10-0-1-76 blog]$ sudo systemctl stop mariadb
- DBの接続先が変更されても、同じコンテンツが表示可能であることを確認した。
6. 所感
- 一応流れは理解することができた。本当に本番で使う時はエラーの原因調査などきちんと深堀したい。