LoginSignup
4
1

More than 1 year has passed since last update.

@mksamba(mksamba)inKDDI株式会社

【初心者】AWS Database Migration Service (DMS) を使ってみる

Posted at

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. 構成図

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のインストール

  • 事前にVPC及びサブネット(構成図の通り)を用意しておく。
  • EC2にWordPressをインストールする手順の記事「【超初心者向け】WordPressをAmazon EC2インスタンスにインストールする」を完全にそのまま実施する。(丁寧な解説のある素晴らしい記事)

  • WordPressのインストールが完了し、記事が投稿できることを確認する。
    dms2-02a.png

  • この手順によってインストールされる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からの接続は許可するようセキュリティグループを設定する。

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 [(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

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

dms2-18a.png

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

dms2-19a.png

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

dms2-20a.png

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

dms2-20a.png

6. 所感

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

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
4
1