AWS DMS を使ってみた(2) ～データ同期を徹底検証。同期には”ログ”の設定が必須！～｜AWSを使い倒せ

  • f
  • t
  • p
  • h
  • l
title_AWS_heavy_use

AWS DMSはテーブルのデータ追加／削除／変更、そしてテーブル作成までデータ同期できる

以前は、AWS DMS(Database Migration Service)のタスクを作成して、移行元データベース(DB)のMy SQLから移行先DBのRDS(Postgre SQL)へのテーブルデータの移行を行いました。前回の記事でAWS DMSが、AWSコンソールの操作だけで簡単にミスなく、そして低価格に全てのテーブルのデータ移行が行えることが分かって頂けたと思います。今回は、AWS DMSの特徴の一つであるデータ同期について、色々、検証してみたいと思います。

データ同期の仕組み(推測)

AWS DMSで移行元から移行先にDB移行を行う際、タスクの設定でマイグレーションタイプを「Migrate existing data and replicate ongoing changes」にする事で、全てのテーブルのデータ移行(テーブル作成とデータ追加)が完了した後もタスクは起動し続けます。(マイグレーションタイプが「Migrate existing data」の場合はテーブルのデータ移行後にタスク終了) そして、タスク起動中は、AWS DMSで2つのDBのデータ同期を行ってくれます。果たして、移行元DBの負荷はどの程度か？ 同期のタイミングは何時か？ などをAWS DMSのログなどから推測したいともいます。

データ同期はデータベースのログで行われるようだ

前回の記事でも記載しましたが、AWS DMSのタスクを設定した時、データ同期を行うマイグレーションタイプを選んだ際、下記のようなメッセージが表示されます。このメッセージの内容から移行元DBのMy SQLにはバイナリログが必須であることが分かります。(移行元DBがOracleの場合のメッセージは「Your source database is Oracle. Replicating ongoing changes requires supplemental logging to be turned on.」)

このことから初期データ移行後のデータ同期では、DBのバイナリログを使用していることが推測されます。DBには、「ログ」と呼ばれるテーブルの変更履歴を蓄積している領域があり、普段は使用せず、DBをある時点に戻したいときなどの障害対応として使われます。このログの保存領域は、テーブルの保存領域と分かれていることが多いため、テーブル読書きスピードには影響なさそうです。また、直近のログデータだけ参照すれば、テーブルの変更を追う事ができるため、データ同期が効率的に行えそうです。

また、DBのログに書き込まれたことでデータ同期を行っているなら、もしかしてダイレクトロードなどのログ書込みを行わないインポート処理などは、データ同期の対象外になる可能性はあります。この可能性については、また時間を確保して、検証したいと思います。

データ同期のタイミング

AWS DMSがデータ同期を行うためには、一定期間ごとに移行元DBのデータ変更が行われたかを確認する必要があります。データ確認のタイミングについては、AWS DMSの実行ログから推測できます。下記のように実行ログには、5分間隔で「[SOURCE_CAPTURE ]I: > ROTATE_EVENT (mysql_endpoint_capture.c:2685)」を出力していることから、5分間隔で移行元DBのデータ確認を行っていると思われます。

移行元DBの大規模なデータ変更のデータ同期にはある程度時間が必要

AWS DMSによるデータ同期中も移行元DBのデータ変更(追加／変更／削除)、テーブル作成などを行った場合、ほぼリアルタイムで移行先DBに反映されました。しかし、ある程度の大規模なデータ変更には時間が掛かりました。

今回、検証した内容として、移行元DBの1つのテーブルから条件指定を行い、約1,300万件を一度に削除をする内容です。移行元DBの処理自体は1分ほどで完了し、AWS DMSでも数分後に検知してくれました。しかし、移行先DBへの反映処理はじわじわと数万行単位で行っているようでした。その間、移行先DBのデータの状態は、削除前の状態を保ち、AWS DMSの約30分の処理完了後に一気に削除されました。

この間、AWS DMSのCPU使用率が100%だったことから、AWS DMSの処理性能を上げることで処理速度が改善されるかもしれません。移行元DBのデータ変更が頻繁に行われる場合には、AWS DMSの処理性能を上げた方が良いかもしれません。

移行先DBのデータ変更後もデータ同期は継続する

DB移行処理中はご法度とされる移行元DBの変更をやってみました。結果、データ同期は継続されることを確認しました。

検証内容は下記のように移行元DB、移行先DBの相互のデータを変更しあうという物です。

  1. 移行先DBのテーブルのプライマリキー項目以外のデータ項目を変更
  2. 移行元DBのテーブルのプライマリキー項目以外のデータ項目を変更 → 移行先DBに反映されるとを
  3. 移行先DBのテーブルにレコードを追加
  4. 移行元DBのテーブルに上記と同じプライマリキー項目を含むレコードを追加

最後の移行元DBのテーブルへのレコード追加でプライマリキー違反が発生して、AWS DMSのタスクが異常終了することを予想しましたが、下記のようなログが出力され、移行元DBのプライマリキー違反が起きていないレコードのみが追加されました。また、プライマリキー違反などで追加できなかった処理は、移行元DBの「attrep_apply_exceptions」テーブルを参照することで、実行されたSQL文とエラーメッセージを確認することができます。

若干のバグもある

今回、AWS DMSを様々な方法で検証しましたが、1つだけバグらしい現象がありました。移行元DBで「create table test(c1 int);」でテーブル作成し、レコード追加、そしてレコード削除を試みたところ、削除命令に失敗したようで、下記のようなエラーメッセージが出力されました。これ以降、AWS DMSは稼働し続けますが、データ同期は行われなくなってしまいました。

仕方ないのでAWS DMSを再起動しました。再起動は、AWSコンソールのAWS DMSタスクの「Stop」ボタンでタスクを停止し、「Start/Resume」ボタンでタスク起動します。「Start/Resume」ボタンをクリックした際に表示される下記ダイアログでは、「Restart」を選択することでゼロからデータ移行をやり直せます。(「Start」を選択するとタスク停止した所から再開)

結論：AWS DMSのデータ同期は行えるが、ログの確認は必要

AWS DMSのデータ同期は、移行元DBの負荷を掛けずに非常に素晴らしい働きをしてくれることが分かりました。しかし、現段階(2016.04.01時点)では、残念ながらバグのようなものがあります。このバグは、近い将来、解消されるとは思いますが、ちゃんとDB移行が完了したかをAWS DMSのログや移行先DBの「attrep_apply_exceptions」テーブルなどで確認する必要がありそうです。これらの確認の手間を行ったとしても、DB移行でAWS DMSの導入する価値は十分あると思います。

【関連記事】
  • f
  • t
  • p
  • h
  • l

RECOMMEND