AWS Database Migration Service (AWS DMS) の CDC レプリケーションを使ってみた

はじめに

AWS Database Migration Service (AWS DMS) の CDC レプリケーション機能を利用して EC2 MySQL から RDS MySQL へデータベースの継続的な移行を検証してみました。

検証準備

• ソースデータベースは EC2 を Amazon Linux2 で起動し、MySQL 8.0系をインストールして用意します。

CDC レプリケーションを利用する場合、ソースデータベース側の mysql パラメータとしては下記設定が必要です。

server_id → 1以上
log-bin → ファイルパスを指定
binlog_format → ROW
expire_logs_days → 1以上
binlog_checksum → NONE
binlog_row_image → FULL

参考 : https://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Source.MySQL.html

• RDS MySQL は MySQL 8.0系で起動しておきます。
• データの書き込みは mysqlslap で対応します。

mysqlslap は MySQL 公式の負荷エミュレーションクライアントです。
mysql-community-client-8.0 の rpm パッケージに同梱されています。
EC2内で下記コマンドを発行し、データベースとテーブル、ランダムデータを作成しておきます。

test_1 というデータベースが作成され、mysqlslap が作成するテーブルに、100000行が INSERT されます。また、--no-drop を指定する事で、負荷エミュレーションが終了してもデータベースとテーブル、データを保持します。

参考 : https://dev.mysql.com/doc/refman/5.6/ja/mysqlslap.html

• DMS レプリケーションインスタンスの作成

「レプリケーションインスタンスの作成」をクリック。
レプリケーションインスタンスの名前を入力する。

インスタンスクラス、エンジンバージョン、マルチ AZ項目をそれぞれ選択する。

Storage サイズを入力。Network type、VPC、レプリケーションサブネットグループを選択する。
Advanced settingsを開き、アベイラビリティーゾーン、セキュリティグループを選択する。
必要に応じて、メンテナンス、タグ項目を入力する。最後に「レプリケーションインスタンスの作成」をクリックする。

• DMS エンドポイントの作成 (ソースエンドポイント)

「エンドポイントの作成」をクリックする。

ソースエンドポイントを選択する。

エンドポイント識別子、ソースエンジンを入力する。
エンドポイントデータベースへのアクセスは今回適切な値を手動で入力する。

VPC、レプリケーションインスタンスを選択し、「テストの実行」をクリックする。
ステータスが successful となった事を確認し、「エンドポイントの作成」をクリックする。

• DMS エンドポイントの作成 (ターゲットエンドポイント)

ターゲットエンドポイントを選択する。「RDS DB インスタンスの選択」にチェックをする。

「RDS DB インスタンスの選択」にチェックを入れた場合、ある程度入力が省かれるが、パスワードなどは入力が必要。

VPC、レプリケーションインスタンスを選択し、「テストの実行」をクリックする。
ステータスが successful となった事を確認し、「エンドポイントの作成」をクリックする。

• データ移行タスクの作成

「データ移行タスクの作成」をクリックする。

タスク識別子、レプリケーションインスタンスを入力、選択する。
移行タイプから「既存のデータを移行して、継続的な変更をレプリケートする」を選択する。

編集モードは「ウィザード」を選択する。
「ソーストランザクションのカスタム CDC 停止モード」→「カスタム CDC 停止モードを無効にする」
「ターゲットテーブル準備モード」→「何もしない」
「フルロードの完了後にタスクを停止する」→「停止しない」
「レプリケーションに LOB 列を含める」→「制限付き LOB モード」
「最大 LOB サイズ (KB)」→「32」

テーブルマッピングの編集モードは「ウィザード」を選択する。
選択ルールでは適切なルールを設定する。下記例では、プレフィックスに test_ と付くデータベースのみレプリケーションを行う設定です。

移行タスクのスタートアップ設定で「後で手動で行う」を選択し、「タスクの作成」をクリックする。

検証

• データベース移行の開始 (フルロード)

データベース移行タスクのステータスが「準備完了」となる事を確認する。

対象のタスクを選択し、「アクション」から「再起動/再開」をクリックする。

対象のタスクのステータスが「ロード完了、レプリケーション進行中」となればレプリケーション成功となる。

ソースデータベースとターゲットデータベースの同テーブルに対して CHECKSUM TABLE 文を発行して差分を確認します。

Checksum の値が同じである為、正常に移行できた事がわかりました。

• データベース移行の開始 (CDC レプリケーション)

ここからが本番です。フルロードが終了した状態で、ソースデータベースに更新をかけて行きたいと思います。
再度、mysqlslap で下記コマンドを発行します。

mysqlslap の仕様上、既存のデータベースに更新をかける事ができません。そこで別名のデータベースを定義し、初回と同様のレコード数を INSERT してみます。
新たに test_2 というスキーマが追加された事がわかります。追加されたと同時に、挿入数も上昇している事がわかります。うまく CDC レプリケーションが動いていますね。

CDC レプリケーション中は「CloudWatchメトリクス」タブから CDC 関連の負荷状況を確認できます。ソースデータベースが稼働する EC2 のリソース状況や、ターゲットデータベースである RDS のリソース状況も別途 CloudWatchメトリクスで確認しておきたいですね。

フルロード時と同様に、ソースデータベースとターゲットデータベースの同テーブルに対して CHECKSUM TABLE 文を発行して差分を確認します。

CDC レプリケーションにおいても、Checksum の値が同じである為、正常に移行できた事がわかりました。

まとめ

AWS DMS は2016年頃にGAされたサービスとなり、現在に至るまで様々なアップデートが走ってます。UIなども前と比べてとても使いやすくなっています。データベース移行に特化した移行ツールとして、マイグレーション計画に欠かせないサービスだと思います。

また、今回検証した AWS DMS の CDC レプリケーション機能を使う事で、データベース移行に伴うサービス断を最小限にする事ができます。データベースの移行をご検討の方は是非ご相談ください。