Amazon Web Services ブログ

AWS DMS データの再同期によるデータ一貫性

本投稿は、 Suchindranath Hegde と Mahesh Kansara と Sridhar Ramasubramanian による記事 「Data consistency with AWS DMS data resync」を翻訳したものです。

この投稿では、AWS Database Migration Service の データの再同期機能について詳しく説明します。これは DMS バージョン 3.6.1 で導入された機能で、データベース移行中のデータの不整合を検出して解決するので、手動による修正が必要ありません。データの再同期 を使用することで、ソースとターゲットデータベース間のデータ検証によって特定されたデータの不整合が識別され、対処されます。ここでは、データの再同期機能を有効にする手順と、例を通じてデータの不整合を特定する方法について説明します。

データの再同期が利用可能になる前は、データの不整合に対してユーザーの介入が必要でした。例えば、フルロードと変更データキャプチャ (CDC) のタスクでテーブルの再ロードを実行したり、ターゲットのレコードを手動で更新したりする必要がありました。データの再同期は、AWS DMS が Oracle か SQL Server から PostgreSQL か Amazon Aurora PostgreSQL への移行をサポートしているすべての リージョン で利用可能です。

AWS DMS データの再同期の設定

データの再同期は、DMS データ検証で特定された不一致を読み取り、ソースから現在の値を取得し、それをターゲットに適用してターゲット上のレコードを同期することによって実行されます。フルロードのみのタスクの場合、再同期が有効になっていると、すべてのテーブルが検証された直後に実行されます。CDC タスクの場合、再同期はタスク設定を通じてスケジュールする必要があり、その時点で、タスクは CDC とデータ検証を一時停止することで書き込みの競合を最小限に抑えます。

ベストプラクティスで推奨されているように、ソースデータベースのアクティビティが少ないタイミングに、再同期ウィンドウを短時間でスケジュールすることをお勧めします。これにより、CDC が一時停止することによるレイテンシーのスパイクを最小限に抑えることができます。

データの再同期を設定するには、タスクの作成または変更時に有効にする必要があります。AWS DMS コンソールで、データの再同期の下にある再同期のスケジュールを選択します。以下のスクリーンショットに示すとおりです。

再同期スケジュールは、Cron 式を使用してデータ再同期の実行をスケジュールします。

* * * * * 
| | | | | 
| | | | | 
| | | | +---- Day of Week (0-6) 
| | | +------ Month (1-12)
| | +-------- Day of Month (1-31)
| +---------- Hour (0-23)
+------------ Minute (0-59)

例えば、以下の設定では、データの再同期を土曜日の深夜に実行するようにスケジュールしています：

"ResyncSettings": 
{
    "EnableResync": true,
    "ResyncSchedule": "0 0 * * 6", // Run Saturday at midnight 
    "MaxResyncTime": 360,  // Run for maximum of 360 minutes, or 6 hours 
    "ValidationTaskId": "" //Optional, used only if validation is performed as a separate Validation only task 
}

その他の例については、データ再同期の設定と例を参照してください。

AWS DMS はデータ再同期で PostgreSQL ターゲットエンドポイントに awsdms_validation_failures_v2 テーブルを作成します。このテーブルの構造は、以下のスクリーンショットに示されています。

このテーブルは、検証プロセス中にプライマリキーを使用してソースのデータを参照することで、ターゲットテーブルの不一致を追跡し対処するために参照されます。AWS DMS バージョン 3.6.1 以上にタスクをアップグレードまたは移行する際、アップグレード前に発生した検証の失敗は自動的に再同期されません。アップグレードによる検証の失敗に対処するには、テーブルの再ロードまたは再検証を開始する必要があります。アップグレード後に発生する新しい検証の失敗は、awsdms_validation_failures_v2 テーブルを通じて追跡され、再同期されます。

再同期実行中に、AWS DMS はタスクタイプに応じて以下の一連のステップを実行します。各ステップについて、タスクタイプに応じて以下のメッセージが CloudWatch ログに記録されます：

フルロード と CDC タスク、または CDC タスクの場合：

  1. 再同期実行のトリガー： 
    [DATA_RESYNC ]I: Data Resync Manager schedule window time matched to start resync
  2. 検証の一時停止： 
    [DATA_RESYNC ]I: Trying to STOP validation before resync process. (resync_manager.c:331)
  3. CDC の一時停止： 
    [DATA_RESYNC ]I: Data Resync Manager sending command to sorter to PAUSE applying changes to target.
  4. テーブルの再同期： 
    [RESYNC_UNLOAD ]I: Sent ctrl command for Resync Unload of table with id: 1
  5. CDC の再開： 
    [DATA_RESYNC ]I: Data Resync Manager sending command to sorter to RESUME applying changes to target
  6. 検証の再開： 
    [DATA_RESYNC ]I: Trying to RESUME validation after resync process

フルロードのみのタスクの場合、検証プロセスが完了した後に再同期マネージャーがトリガーされるため、スケジュールを指定する必要はありません。

  1. 再同期実行のトリガー： 
    [DATA_RESYNC     ]I:  Data Resync Manager sending command to start up resync subtasks
  2. テーブルの再同期： 
    [TASK_MANAGER    ]I:  All tables are loaded. Validation is finished. Waiting for resync to finish...  (replicationtask.c:4953)
 [DATA_RESYNC     ]I:  Stopped Data Resync Manager, exiting thread

AWS DMS データの再同期のユースケース

AWS DMS のデータの再同期が有効なユースケースはいくつかあります。このセクションでは、2 つの例を見ていきます。

ターゲットでレコードの誤削除

最初に検討するユースケースは、ターゲット上のレコードが誤って削除された場合です。このユースケースを説明するために、REVIEWS という名前のテーブルを Oracle から PostgreSQL に移行します。フルロードが完了した後、ターゲット上の数レコードを誤って削除します。以下の例では、ターゲット上の特定のレコードを削除するために、ターゲットに対して Data Manipulation Language (DML) ステートメントを実行します：

dmsdb=> delete from dms_test.reviews where review_id=8193 ;
 DELETE 1

このシナリオでは、テーブルの再検証を試みるとデータ不整合が発生します。これは、以下のコマンドを入力するか、AWS コンソールで確認することができます：

aws dms  describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:xxxxxxxxxxxx:task:xxxxxxxxxxxx --filters Name=table-name,Values="REVIEWS"

{
    "TableStatistics": [ 
        {
            "SchemaName": "DMS_TEST",
            "TableName": "REVIEWS",
            "Inserts": 0,
            "Deletes": 0,
            "Updates": 0,
            "Ddls": 0,
            "AppliedInserts": 0,
            "AppliedDeletes": 0,
            "AppliedUpdates": 0,
            "AppliedDdls": 0,
            "FullLoadRows": 3500,
            "FullLoadCondtnlChkFailedRows": 0,
            "FullLoadErrorRows": 0,
            "FullLoadStartTime": "2025-06-03T14:24:23.062000-05:00",
            "FullLoadEndTime": "2025-06-03T14:24:25.408000-05:00",
            "FullLoadReloaded": false,
            "LastUpdateTime": "2025-06-03T14:35:12.009000-05:00",
            "TableState": "Table completed",
            "ValidationPendingRecords": 0,
 "ValidationFailedRecords": 1,
            "ValidationSuspendedRecords": 0,
 "ValidationState": "Mismatched records"
        }
    ] 
}

データの再同期が有効になっている場合、ソースをチェックし、ターゲットに再適用することでこれらの不整合が処理されます。次の例では、public.awsdms_validation_failures_v2 テーブルに反映されたレコードを確認できます。ここでは、RESYNC_ACTION が UPSERT であることから、ターゲットに再適用されたことがわかります。RESYNC_TIME は、アクションが実行されたタイムスタンプを示しています。

dmsdb=> select * from public.awsdms_validation_failures_v2 ;
-[ RECORD 1 ]-+---------------------------
 RESYNC_ID     | 1029 
 TASK_NAME     | BESR3KWW2FCLLH4AJBFSEYSNW4 
 TABLE_OWNER   | dms_test 
 TABLE_NAME    | reviews 
 FAILURE_TIME  | 2025-06-03 19:33:26.410998 
 KEY_TYPE      | Row 
 KEY           | {                         +
              |         "key":  ["8193"]  +
              | }
 FAILURE_TYPE  | MISSING_TARGET 
 DETAILS       |
 RESYNC_RESULT | SUCCESS 
 RESYNC_TIME   | 2025-06-03 19:35:06.322 
 RESYNC_ACTION | UPSERT

CDC 中にターゲットで誤って数件のレコードを削除してしまうシナリオを想像してみてください。例えば、以下の SQL コマンドでは、ターゲット上の 20 件のレコードをランダムに削除します：

dmsdb=> delete from dms_test.reviews where ctid in (select ctid from dms_test.reviews order by RANDOM() LIMIT 20);
 DELETE 20

データの再同期がこれらのレコードを処理し、ターゲットに正常に適用されたことを確認できます。

dmsdb=> select "TABLE_OWNER", "TABLE_NAME","RESYNC_ACTION", "FAILURE_TYPE", "RESYNC_RESULT",count(*) from public.awsdms_validation_failures_v2 group by "TABLE_OWNER", "TABLE_NAME","RESYNC_ACTION", "FAILURE_TYPE", "RESYNC_RESULT";
-[ RECORD 1 ]-+---------------
 TABLE_OWNER | dms_test 
 TABLE_NAME | reviews 
RESYNC_ACTION | UPSERT FAILURE_TYPE | MISSING_TARGET RESYNC_RESULT | SUCCESS count | 21

これまで説明したフルロードと CDC の両方のシナリオでは、データの再同期にテーブルの再検証が必要です。これにより、すべてのデータの不整合が適切に特定され、修正されます。この再検証が必要なのは、ターゲットの変更が AWS DMS によって行われたものではないためです。

テーブルエラー後の CDC タスクの再開

別のユースケースとして、移行中にテーブルがエラー状態になり、そのテーブルの変更がターゲットにレプリケートされない場合があります。この場合、タスクの実行中にテーブルを再ロードすることができます。ただし、CDC のみのタスクの場合、テーブルが失敗した時の LSN からタスクを再開する必要があります。AWS DMS タスク中に複数のテーブルがある場合、特定の時間枠から DMS タスクを開始すると、変更がターゲットに再度適用される場合があります。

Oracle から PostgreSQL に ADMIN スキーマの 5 つのテーブルを移行するシナリオを考えてみましょう。次のスクリーンショットでは、5 つのテーブルのうち 3 つがエラーで終了しています。

CloudWatch ログから、これらのテーブルが異なるタイムスタンプでエラーになったことがわかります。テーブルが異なるタイムスタンプで失敗したため、テーブルがエラーになった最も早いタイムスタンプを CDC 開始時間として使用し、これら 3 つのテーブルで CDC のみのタスクを作成する必要があります。この場合、最も早いタイムスタンプは 2025-06-05T03:40:13 です。

2025-06-05T03:40:13 [TASK_MANAGER ]W: Table 'ADMIN'.'DMST1' was errored/suspended (subtask 0 thread 1). 

 2025-06-05T03:47:53 [TASK_MANAGER ]W: Table 'ADMIN'.'DMST2' was errored/suspended (subtask 0 thread 1). 

 2025-06-05T03:52:32 [TASK_MANAGER ]W: Table 'ADMIN'.'DMST5' was errored/suspended (subtask 0 thread 1).

データの再同期中に、検出された競合が解消されたことを確認できます。以下のスクリーンショットに示されています。

dmsdb=> select * from public.awsdms_validation_failures_v2 ;
-[ RECORD 1 ]-+---------------------------
 RESYNC_ID     | 9949 
 TASK_NAME     | 6LOQBMAKQFDELB5WQB5BPG5Q74 
 TABLE_OWNER   | admin 
 TABLE_NAME    | dmst1 
 FAILURE_TIME  | 2025-06-05 05:26:58.027987 
 KEY_TYPE      | Row 
 KEY           | {                         +
              |         "key":  ["101"]   +
              | }
 FAILURE_TYPE  | MISSING_TARGET 
 DETAILS       |
 RESYNC_RESULT | SUCCESS 
 RESYNC_TIME   | 2025-06-05 05:30:06.423 
 RESYNC_ACTION | UPSERT

Conclusion

この投稿では、データの再同期について紹介し、その設定方法と、検証中にデータ再同期を使用して不整合を確認および修正できる 2 つのユースケースについて説明しました。詳細については、AWS DMS データの再同期を参照してください。

著者について

Suchindranath Hegde

Suchindranath Hegde

Suchindranath は Amazon Web Services のシニアデータ移行スペシャリストソリューションアーキテクトです。彼はお客様と協力して、AWS DMS を使用した AWS へのデータ移行に関するガイダンスと技術支援を提供しています。

Mahesh Kansara

Mahesh Kansara

Mahesh は Amazon Web Services のデータベースエンジニアリングマネージャーです。彼は開発チームやエンジニアリングチームと緊密に連携して、移行およびレプリケーションサービスを改善しています。また、お客様と協力して、データベースや分析のさまざまなプロジェクトに関するガイダンスや技術支援を行い、AWS を使用する際のソリューションの価値向上を支援しています。

Sridhar Ramasubramanian

Sridhar Ramasubramanian

Sridhar はAWS Database Migration Service チームのデータベースエンジニアです。彼はAWSのお客様のニーズにより合うように、DMS サービスの改善に取り組んでいます。