DMS データ検証機能を使ってみた
はじめに
DMS のデータ検証機能について使う機会があったので、備忘録です。
データ検証機能は、ソースとターゲットのデータを比較し、移行が正常にされているかを確認するための機能です。
本ブログで具体的にやることは以下です。
- ソースに FugaFuga テーブルを作成
- ターゲットに FugaFuga テーブルを作成
- データ検証タスクを作成, 実施
- ソースとターゲット間の FugaFuga テーブルの違いを発見
以下が、ソースとターゲットに作成する FugaFuga テーブルです。
mysql> select * from test_db.FugaFuga;
+-----+----------+------+-------------+
| id | name | age | prefectures |
+-----+----------+------+-------------+
| 1 | Yamada | 25 | Tokyo |
| 2 | Takayama | 35 | Kagawa |
| 3 | Suzuki | 45 | Fukuoka |
| 100 | Shima | 55 | Okinawa |
+-----+----------+------+-------------+
mysql> select * from test_db.FugaFuga;
+-----+----------+------+-------------+
| id | name | age | prefectures |
+-----+----------+------+-------------+
| 1 | Yamada | 25 | Tokyo |
| 2 | Takayama | 111 | kagawa |
| 3 | Suzuki | 45 | Fukuoka |
| 100 | Shimada | 55 | Okinawa |
+-----+----------+------+-------------+
4 rows in set (0.00 sec)
上記のテーブルでは、以下の点が違います。
データ検証機能でこれらの違いが見つけられるのか試してみます。
- id=2 の age が異なる(35 と 111)
- id=2 の prefectures の "Kagawa" が "kagawa" になっている
- id=100 の name について "Shima" が "Shimada" になっている
やってみた
前提準備
以下の構成を準備します。
作成手順は下記ブログをご参照ください。(※上記画像を見るとリソースが複数あり、骨が折れそうに見えますが、各手順は単純なものなのでぜひお試しください。)
データ検証で比較するデータベース,テーブルの作成
EC2 からソースの Aurora MySQLに接続し、比較対象のデータベースおよびテーブルを作成します。
mysql> create database test_db;
Query OK, 1 row affected (0.00 sec)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| test_db |
+--------------------+
5 rows in set (0.00 sec)
mysql> use test_db;
Database changed
mysql> create table FugaFuga (id int NOT NULL PRIMARY KEY, name varchar(10), age int, prefectures varchar(10));
Query OK, 0 rows affected (0.04 sec)
mysql> insert into FugaFuga values (1,'Yamada',25,'Tokyo');
Query OK, 1 row affected (0.01 sec)
mysql> insert into FugaFuga values (2,'Takayama',35,'Kagawa');
Query OK, 1 row affected (0.00 sec)
mysql> insert into FugaFuga values (3,'Suzuki',45,'Fukuoka');
Query OK, 1 row affected (0.01 sec)
mysql> insert into FugaFuga values (100,'Shima',55,'Okinawa');
Query OK, 1 row affected (0.01 sec)
mysql> select * from FugaFuga;
+-----+----------+------+-------------+
| id | name | age | prefectures |
+-----+----------+------+-------------+
| 1 | Yamada | 25 | Tokyo |
| 2 | Takayama | 35 | Kagawa |
| 3 | Suzuki | 45 | Fukuoka |
| 100 | Shima | 55 | Okinawa |
+-----+----------+------+-------------+
4 rows in set (0.00 sec)
ターゲットデータベースに接続し、比較対象のデータベースとテーブルを作ります。
なお、データの値は「はじめに」で述べた通り、ソースとは若干異なるようにしています。
mysql> create database test_db;
Query OK, 1 row affected (0.01 sec)
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| performance_schema |
| sys |
| test_db |
+--------------------+
5 rows in set (0.00 sec)
mysql> use test_db;
Database changed
mysql> create table FugaFuga (id int NOT NULL PRIMARY KEY, name varchar(10), age int, prefectures varchar(10));
Query OK, 0 rows affected (0.03 sec)
mysql> insert into FugaFuga values (1,'Yamada',25,'Tokyo');
Query OK, 1 row affected (0.00 sec)
mysql> insert into FugaFuga values (2,'Takayama',111,'kagawa');
Query OK, 1 row affected (0.01 sec)
mysql> insert into FugaFuga values (3,'Suzuki',45,'Fukuoka');
Query OK, 1 row affected (0.00 sec)
mysql> insert into FugaFuga values (100,'Shimada',55,'Okinawa');
Query OK, 1 row affected (0.00 sec)
mysql> select * from FugaFuga;
+-----+----------+------+-------------+
| id | name | age | prefectures |
+-----+----------+------+-------------+
| 1 | Yamada | 25 | Tokyo |
| 2 | Takayama | 111 | kagawa |
| 3 | Suzuki | 45 | Fukuoka |
| 100 | Shimada | 55 | Okinawa |
+-----+----------+------+-------------+
4 rows in set (0.00 sec)
データ検証タスクの作成 / 実施
前項にて、比較対象データの準備ができたので、データ検証タスクを作成していきます。
「タスクの作成」を選びます。
タスクの設定をしていきます。タスクモードは 「プロビジョンド」、タスクタイプは「移行のみ」を選びます。
ターゲットテーブル準備モードを「何もしない」とし、データ検証の部分では、今回は移行はせず検証のみ行いたいので「検証(データ移行なし)」を選びます。
テーブルマッピングにて比較対象のエンティティを指定します。
ソースとターゲットに作成済みの test_db データベースおよび FugaFuga テーブルを指定します。
移行前評価のチェックを外し、右下の「タスクを作成」を選びます。
タスクを設定できました。ステータスが作成中となっています。
タスクが作成され、自動で開始されています。ステータスが開始中となっています。
ステータスがロード完了となり、タスクが終了した模様です。
動作確認
前項にてタスクの実施が完了したので、ちゃんとデータ検証機能にてソースとターゲット間の違いが発見できているのか確認します。
タスクの詳細画面に移動します。すると以下の通り、「1 Table completed」とあり、Data validation の部分にて「1 Mismatched records」と表示されていることがわかります。
「1 Mismatched records」リンクをクリックすると、「テーブルの統計」の箇所に内容が表示されます。
確認すると、「検証に失敗しました」の項目で 2 を記録しており、FugaFuga テーブルの 2 つのレコードで検証が失敗していることがわかります。
なお、データ検証では、以下ドキュメントの通り、ターゲットデータベースに専用のテーブルが作成され、そこで不一致行の詳細を確認できます。
[Mismatched records] (不一致レコード) – テーブル内の一部のレコードが、ソースとターゲット間で一致しません。さまざまな理由により、不一致が発生することがあります。詳細については、ターゲットエンドポイントの awsdms_control.awsdms_validation_failures_v1 を確認してください。
ターゲットデータベースに接続し、内容を詳細を確認します。
接続すると新しいデータベース awsdms_control が作成されています。
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| awsdms_control |
| information_schema |
| mysql |
| performance_schema |
| sys |
| test_db |
+--------------------+
6 rows in set (0.00 sec)
データベースの中身を確認すると、テーブル awsdms_validation_failures_v1 が作られており、そこに今回データ検証を行った FugaFuga テーブルの不一致行の詳細が記載されていました。
mysql> use awsdms_control;
Database changed
mysql> show tables;
+-------------------------------+
| Tables_in_awsdms_control |
+-------------------------------+
| awsdms_validation_failures_v1 |
+-------------------------------+
1 row in set (0.00 sec)
mysql> select * from awsdms_validation_failures_v1;
+----------------------------+-------------+------------+-------------------------+----------+---------------------+--------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| TASK_NAME | TABLE_OWNER | TABLE_NAME | FAILURE_TIME | KEY_TYPE | KEY | FAILURE_TYPE | DETAILS |
+----------------------------+-------------+------------+-------------------------+----------+---------------------+--------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| QRMBTGXSCRGA5PAAXAH6BDBS54 | test_db | FugaFuga | 2025-09-13 04:27:15.470 | Row | {
"key": ["100"]
} | RECORD_DIFF | [[{'name': '<VALUE_PRINT_NOT_SUPPORTED>'}, {'name': '<VALUE_PRINT_NOT_SUPPORTED>'}],] |
| QRMBTGXSCRGA5PAAXAH6BDBS54 | test_db | FugaFuga | 2025-09-13 04:27:15.509 | Row | {
"key": ["2"]
} | RECORD_DIFF | [[{'age': '<VALUE_PRINT_NOT_SUPPORTED>'}, {'age': '<VALUE_PRINT_NOT_SUPPORTED>'}],[{'prefectures': '<VALUE_PRINT_NOT_SUPPORTED>'}, {'prefectures': '<VALUE_PRINT_NOT_SUPPORTED>'}],] |
+----------------------------+-------------+------------+-------------------------+----------+---------------------+--------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
2 rows in set (0.00 sec)
上記少し表示が見づらいですが、
FugaFuga テーブルのプライマリキーが 100 の行の "name" カラム、
プライマリキーが 2 の行の "age" および "prefectures" カラムにおいて不一致が発生していることが確認できます。
こちらの内容は、「はじめに」で記載したテーブルの相違点と完全に一致しますね。データ検証機能すごい。
今回の検証では、具体的な値は VALUE_PRINT_NOT_SUPPORTED となり表示されておりませんが、実際に使う際は、awsdms_validation_failures_v1 に記録される id と カラム名を参照しながら、適宜データを修正していくなどの使い方が想定されますね。
検証は以上です。
終わりに
今回は、DMS データ検証機能を触ってみました。難しそうかなと思いながらやってみたのですが、比較したいテーブルを指定し、タスクを実行するだけでデータの不一致が見つけられるので便利ですね。
ただ公式ドキュメントを読んでいると、本機能ではプライマリキーや一意のインデックスが必須であることやビューの検証はできないなど様々な制約がありました。
なので本機能で、データの完全性を担保するのではなく、本機能 + 独自のスクリプト等でデータ移行の担保をするのが良さそうですね。
制限事項については下記ドキュメントに詳細があるためご覧ください。
いずれにしてもデータ検証機能は手軽で便利で機能だと感じました。移行作業は大変なのでこういった機能をうまく使っていきたいですね。
本記事がお役に立てば幸いです。お疲れ様でした。
参考情報