尝试使用AWS数据库迁移服务(DMS)的初学者

目标

    AWSのデータベース関連サービスの復習をしている。AWS Database Migration Service (DMS)を使ってDBを移行するプロセスを理解する。

2. 做过的事情 (zuò guò de

    • EC2インスタンスにWordPressを構築する。WordPressが使用するDBとして、EC2インスタンス内にMariaDBをインストールする。

 

    • EC2インスタンスにインストールしたMariaDBのデータを、RDS(MariaDB)にDMSを用いて移行する。

 

    WordPressのDB参照先設定をRDS(MariaDB)に切り替えて、問題なく動作することを確認する。

3. 亚马逊数据库迁移服务是一项数据迁移服务,在我理解中。

    オンプレミスや他社クラウドで稼働するDBをAWSへ簡単に移行させることができるツール。

4. 建筑图

dms構成図.png

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。

dms2-02a.png

[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からの接続は許可するようセキュリティグループを設定する。
dms02-3a.png

创建5.4 DMS的复制实例。

    • DMSでデータ移行を行うためのレプリケーションインスタンスを作成する。レプリケーションインスタンスが移行元DB、移行先DBの両方と接続して、移行元からデータを抜き出し移行先へ書き込む役割を担う。

 

    マネージメントコンソールにて、「DMS > レプリケーションインスタンス > レプリケーションインスタンスの作成」の画面を開き、移行元EC2インスタンス及びRDS DBインスタンスと同じVPCを選択してレプリケーションインスタンスを作成する。
dms2-04a.png

dms2-05a.png

创建5.5 DMS的源端点和目标端点。

    ソースエンドポイント(移行元DBへの接続情報)、ターゲットエンドポイント(移行先DBへの接続情報)を作成する。

5.5.1 创建源点终端

    • まずソースエンドポイントを作成する。「DMS -> エンドポイント -> エンドポイントの作成」から設定を行う。

「サーバー名」にはEC2インスタンスのプライベートIPを入力する。

「エンジン」として「MariaDB」を選択すると、MariaDBの場合に必要な入力欄が表示される(ログインID/パスワード、port番号など)

dms2-06a.png

dms2-07a.png

    作成したソースエンドポイントを選択し、「接続 > 接続テスト」を実行すると、「Failed」になってしまった。
dms2-08a.png

    • 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)
    再度接続テストを行い、成功することを確認した。
dms2-09a.png

创建目标终端点 5.5.2

    • 次にターゲットエンドポイントを作成する。「DMS -> エンドポイント -> エンドポイントの作成」から設定を行う。

「RDS DBインスタンスの選択」にチェックを入れることにより、既存のRDS DBインスタンスの中から、ターゲットにするDBインスタンスを選択することができ、それに伴いARNなどの情報も自動入力される。

dms2-10a.png

dms2-11a.png

    ソースエンドポイント同様、「接続 > 接続テスト」を実行し、接続が成功することを確認する。

创建5.6数据库迁移任务。

    • データベース移行タスクを作成する。タスクの概念としては、レプリケーションインスタンスとソース/ターゲットインスタンスを紐づけて、レプリケーションインスタンスにソースからデータを取得させ、ターゲットにデータを書き込む作業をやらせるイメージ。

 

    • 「DMS -> データベース移行タスク -> タスクの作成」から、タスクの作成を行う。

移行タイプとして、「既存のデータを移行する」「既存のデータを移行して、継続的な変更をレプリケートする」「データ変更のみをレプリケートする」の選択肢がある。データ移行中のソースDBの更新にも対応したいと思い、今回は「既存のデータを移行して、継続的な変更をレプリケートする」を選択する。
エラー時の調査ができるように、CloudWatch ログを有効化した。また、CloudWatchログを使用するにあたり、別途専用のIAM Roleを作成する必要があり、「AWS DMS タスクの CloudWatch Logs が表示されないのはなぜですか? 」を参照して対応した。
テーブルマッピングの設定を入れないとタスクが作成できないため、スキーマ、テーブルの全てをコピーするようなルールを設定した。

dms2-12a.png

dms2-13a.png

dms2-15a.png

dms2-16a.png

    タスクを開始したところ、以下のエラーとなった。
dms2-17a.png

    「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
    タスクを再実行したところ、また別のエラーで止まってしまった。
dms2-18a.png

    「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
    「エラーを伴って実行中」という微妙な状態だが、タスクは実行されるようになった。
dms2-19a.png

    この状態であれば、レプリケーションが実行されており、移行元のMariaDBへの変更が移行先にも自動反映されるはずのため、移行元の記事にコメントを追加した。
dms2-20a.png

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の接続先が変更されても、同じコンテンツが表示可能であることを確認した。
dms2-20a.png

6. 感受

    一応流れは理解することができた。本当に本番で使う時はエラーの原因調査などきちんと深堀したい。

bannerAds