尝试使用AWS数据库迁移服务(DMS)的初学者
目标
AWSのデータベース関連サービスの復習をしている。AWS Database Migration Service (DMS)を使ってDBを移行するプロセスを理解する。
2. 做过的事情 (zuò guò de
-
EC2インスタンスにWordPressを構築する。WordPressが使用するDBとして、EC2インスタンス内にMariaDBをインストールする。
-
- EC2インスタンスにWordPressを構築する。WordPressが使用するDBとして、EC2インスタンス内にMariaDBをインストールする。
-
- EC2インスタンスにインストールしたMariaDBのデータを、RDS(MariaDB)にDMSを用いて移行する。
- WordPressのDB参照先設定をRDS(MariaDB)に切り替えて、問題なく動作することを確認する。
3. 亚马逊数据库迁移服务是一项数据迁移服务,在我理解中。
オンプレミスや他社クラウドで稼働する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。
[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
创建移行源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の設定変更を行い、バイナリログを有効化した。
[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行追加した。
# 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とした。
/** 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. 感受
一応流れは理解することができた。本当に本番で使う時はエラーの原因調査などきちんと深堀したい。

5. 实机确认流程
5.1 整体的趋势
-
EC2インスタンスにWordPressをインストール(移行元となるMariaDB 5.5をEC2インスタンス内にインストール)
-
- EC2インスタンスにWordPressをインストール(移行元となるMariaDB 5.5をEC2インスタンス内にインストール)
-
- 移行先のRDS(MariaDB 10.4)を作成
-
- DMSのレプリケーションインスタンス(データ移行を行うインスタンス)を作成
-
- DMSのソースエンドポイント(移行元への接続情報)、ターゲットエンドポイント(移行先への接続情報)を作成
-
- データベース移行タスクを作成し、データ移行を開始
- データ移行完了後、WordPressのDB接続設定を、EC2インスタンス内のMariaDBからRDS(MariaDB)へ変更
创建5.2 EC2实例并安装WordPress/MariaDB。
[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
创建移行源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の設定変更を行い、バイナリログを有効化した。
[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行追加した。
# 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とした。
/** 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. 感受
一応流れは理解することができた。本当に本番で使う時はエラーの原因調査などきちんと深堀したい。

[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
创建移行源RDS(MariaDB 10.4)。
-
移行先となるRDS(MariaDB)DBインスタンスを作成する。
- 移行先となるRDS(MariaDB)DBインスタンスを作成する。
-
- RDSのMariaDBは5.x系は既に利用不可のため、デフォルトのバージョン(10.4.13)を選択する。
- 移行元EC2インスタンスと同じVPCに起動し、同一VPCからの接続は許可するようセキュリティグループを設定する。

创建5.4 DMS的复制实例。
-
DMSでデータ移行を行うためのレプリケーションインスタンスを作成する。レプリケーションインスタンスが移行元DB、移行先DBの両方と接続して、移行元からデータを抜き出し移行先へ書き込む役割を担う。
- DMSでデータ移行を行うためのレプリケーションインスタンスを作成する。レプリケーションインスタンスが移行元DB、移行先DBの両方と接続して、移行元からデータを抜き出し移行先へ書き込む役割を担う。
- マネージメントコンソールにて、「DMS > レプリケーションインスタンス > レプリケーションインスタンスの作成」の画面を開き、移行元EC2インスタンス及びRDS DBインスタンスと同じVPCを選択してレプリケーションインスタンスを作成する。


创建5.5 DMS的源端点和目标端点。
ソースエンドポイント(移行元DBへの接続情報)、ターゲットエンドポイント(移行先DBへの接続情報)を作成する。
5.5.1 创建源点终端
-
まずソースエンドポイントを作成する。「DMS -> エンドポイント -> エンドポイントの作成」から設定を行う。
-
- まずソースエンドポイントを作成する。「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 -> エンドポイント -> エンドポイントの作成」から設定を行う。
- 次にターゲットエンドポイントを作成する。「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の設定変更を行い、バイナリログを有効化した。
[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行追加した。
# 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インスタンスに変更する。
- EC2インスタンスのWordPressのDBの参照先設定を、インスタンス内のMariaDBから、RDS(MariaDB)のDBインスタンスに変更する。
-
- 実行中のタスクの進行状況が100%であることを確認し、タスクを停止する。
- WordPressの設定を変更する。ホスト名はRDSのエンドポイントとし、接続ユーザもいったんRDSのadminとした。
/** 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の接続先が変更されても、同じコンテンツが表示可能であることを確認した。
