翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# AWS DMS データの再同期
AWS Database Migration Service (AWS DMS) データ再同期は、ソースデータベースとターゲットデータベース間のデータ検証によって特定されたデータの不整合を自動的に修正します。この機能は既存の DMS 移行タスクの一部として機能し、タスク設定、接続設定、テーブルマッピング、変換に基づいて適切な更新が行われます。
データ再同期機能は、ターゲットデータベースのコントロールテーブルから検証失敗を読み取り、適切な修正オペレーションを実行することで動作します。不一致が検出されると、現在のデータは失敗レコードに保存されているプライマリキーを使用してソースから取得され、設定された変換を維持しながらターゲットに適用されます。詳細については、「[`awsdms_validation_failures_v2` コントロールテーブル](CHAP_Validating.md#CHAP_DataResync.Troubleshooting.v2table)」を参照してください。
動作は、移行のタイプによって異なります。フルロードのみのタスクの場合、データの再同期は、最初のロードと検証が完了した後に 1 回実行されます。変更データキャプチャ (CDC) を使用するタスクの場合、データの再同期は設定されたスケジュールに従って動作し、修正が適用されている間は、レプリケーションと検証が一時的に停止します。
CDC 再同期オペレーション中:
+ レプリケーションと検証は一時的に停止します。
+ データ再同期は、既存の検証失敗を処理します。
+ 通常のレプリケーションと検証を再開します。
+ このプロセスは、設定したスケジュールに基づき繰り返されます。
データ再同期は、それぞれの修正のオペレーションステータスを自動的に追跡し、テーブル統計を通じて詳細なメトリクスを提供します。
**前提条件**:
データ再同期機能には、次の前提条件が必要です。
+ AWS DMS エンジンバージョン 3.6.1 以降が必要です。
+ レプリケーションが継続的に行われるタスクのスケジュールとタイミングの期間を設定する必要があります。フルロードのみのタスクでは、これらの設定は必要ありません。
## 制限事項
この機能には次のような制限があります。
+ データ再同期は、ソースデータベースとして Oracle と SQL Server のみをサポートします。
+ データ再同期は、PostgreSQL および Amazon Aurora PostgreSQL 互換エンジンをターゲットデータベースとしてサポートします。
+ ソースデータベースとターゲットデータベースのすべてのテーブルにプライマリキーが必要です。検証では、プライマリキーまたは一意のキーのないテーブルはサポートされません。有効なプライマリキーまたは一意のキーがないテーブルは検証を停止され、検証の失敗は報告されません。
+ フルロードのみのタスクを実行する場合は、データ検証を有効にする必要があります。
+ データ再同期ではデータをレプリケートしないため、検証のみのタスクでは有効にできません。検証のみを指定することで、親レプリケーションタスクで再同期を有効にできます`taskID`。データ検証の詳細については、「[検証のみのタスク](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.ValidationOnly)」を参照してください。
+ タスク設定で検証のみのタスクに `ControlSchema` パラメータ設定が設定されている場合、データ再同期で正しい検証の失敗を見つけるには、レプリケーションタスクにも同じパラメータ設定が必要です。
+ CDC タスクのスケジュールとタイミングの期間の設定を行う必要があります。
+ 再同期ウィンドウ中のデータ再同期は DMS のレプリケーションレイテンシーに影響を与える可能性があります。
データ再同期 AWS DMS 中の の検証のトラブルシューティングの詳細については、[AWS DMS データ検証](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html)の[「トラブルシューティング](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting)」セクションを参照してください。
## スケジュールとタイミング
CDC を使用するタスクの場合、データ再同期が動作するタイミングと期間を設定する必要があります。これにより、通常のレプリケーションオペレーションに対する影響を防ぐことができます。以下を指定します。
+ 再同期オペレーションをいつ実行するのかを定義する cron 形式のスケジュール。
+ 再同期オペレーションがピーク使用期間に確実に及ばないようにするための最大期間。
再同期オペレーションはオフピーク時、またはソースデータベースの変更が最小限またはまったくない期間にスケジュールすることをお勧めします。
**注記**
スケジュールされた時間にデータ再同期と通常のレプリケーションを同時には実行できないため、ターゲットの適用ストリームが空になるまで待機する時間が含まれます。
## ユースケース
データ再同期機能を使用すると、ユーザーはソースシステムとターゲットシステムでのデータの不整合を調整できます。不一致のレコードを識別し、それらを同期して、分散環境全体でデータ整合性を維持します。次のユースケースは、データ再同期機能でデータ整合性の課題を解決する一般的なシナリオを示しています。
**シナリオ 1: フルロードタスク - 同じ DMS タスクを使用して再同期を実行する**
既存の DMS フルロード移行タスクでは、以下を実行できます。
+ 検証を有効にする: `Validation with data migration = true`
+ 再同期を有効にする: `Data resync = true`
**シナリオ 2: フルロードと CDC、CDC のみのタスク - 同じ DMS タスクを使用して再同期を実行する**
既存の DMS CDC 移行タスクでは、以下を実行できます。
+ 検証を有効にする: `Validation with data migration = true`
+ 再同期を有効にする: `Data resync = true`
+ 再同期スケジュールを指定する: `"ResyncSchedule": "0 0,2,4,6 * * *"`
+ 再同期時間を指定する: `MaxResyncTime": 60`
**シナリオ 3: 検証のみのタスクと組み合わせて、レプリケーションと再同期のためのフルロードおよび CDC、または CDC のみのタスク**
再同期を使用するときに別の DMS タスクで検証のみのオペレーションを実行するには、以下を行います。
+ DMS CDC タスクのみの検証を作成します。
**注記**
データ再同期中に、このタスクの ID を書き留めて指定する必要があります。
+ プライマリ CDC タスクで、検証を無効にする: `Data validation = false`
+ 再同期を有効にする: `Data resync = true`
+ 再同期スケジュールを指定する: `"ResyncSchedule": "0 0,2,4,6 * * *"`
+ 再同期時間を指定する: `MaxResyncTime": 60`
+ 検証のみの DMS CDC タスクの ID を指定します。検証のみのタスク ID は ARN の最後に追加されます。ARN の例: `arn:aws:dms:us-west-2:123456789012:task:6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI` および検証のみのタスク ID の例: `6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`
## ベストプラクティス
のデータ再同期機能を活用して AWS Database Migration Service 、レプリケーションタスクの耐久性を向上させ、一貫性を実現できます。データ再同期機能を使用するためのベストプラクティスは、次のとおりです。
+ データ再同期の一環として、不一致があるレコードは、ソースから取得し、ターゲットデータベースに適用して修正されます。再同期ウィンドウ中にソースデータベースが更新された場合、再同期では最新のレコード値を読み取りターゲットに適用します。これにより、CDC 適用イベントが失敗し、ターゲットデータベースで一時的な不整合が生じる可能性があります。これを回避するには、営業時間外またはソースデータベースの変更がゼロまたは最小限となる時間帯や期間に、再同期ウィンドウをスケジュールする必要があります。
+ ソースデータベースのアクティビティが最小限かつ、許容可能なターゲットレイテンシーのしきい値内で、再同期ウィンドウを設定します。再同期の間隔が短い場合、未処理の検証の不一致が蓄積される可能性がありますが、ウィンドウが大きい場合、検証の失敗が多数発生した際にレプリケーションレイテンシーが増加する可能性があります。検証の失敗と再同期率をモニタリングして、ソースの非アクティブ期間中に最適な再同期ウィンドウを決定します。再同期ウィンドウを設定する例を次に示します。
+ 複数の短いウィンドウ設定:
```
"ResyncSchedule": "0 0,2,4,6 * * *",
"MaxResyncTime": 60
```
+ 1 日 1 回のウィンドウ設定:
```
"ResyncSchedule": "0 0 * * *",
"MaxResyncTime": 360
```
+ 再同期ウィンドウ中に DMS のレプリケーションレイテンシーをモニタリングし、それに応じてスケジュールを調整することで急激な増加を軽減します。
+ 再同期の結果を確認するには、テーブル統計を使用するか、ターゲットデータベースで `awsdms_validation_failures_v2` テーブルをクエリします。詳細については、「[Amazon CloudWatch を使用した メトリクスのモニタリング](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.CloudWatch)」をご参照ください。
+ タスクが継続的なレプリケーションフェーズにある場合は、再同期ウィンドウ中に個々のテーブルの再ロードを開始しないでください。
+ CDC レプリケーションタスクのベストプラクティス:
+ データベース内のすべてのテーブルでロードプロセスを完了します。
+ 不一致は、進行中の検証プロセスで識別されます。
+ スケジュールされた再同期ウィンドウに従って、レプリケーションタスクは短時間停止します。
+ データ再同期は、検証プロセスで明らかになった問題を修正します。
+ レプリケーションプロセスはスケジュールに従って再開され、繰り返されます。
## データ再同期の設定と例
**データ再同期設定の設定**:
DMS でレプリケーションタスクの再同期を設定できます。以下は、タスクでのデータ再同期の設定例です。
```
"ResyncSettings": {
"EnableResync": true,
"ResyncSchedule": "0 0,2,4,6 * * *", // Run at 12AM, 2AM, 4AM, and 6AM daily
"MaxResyncTime": 60, // Run for maximum of 60 minutes, or 1 hour
"ValidationTaskId": "TASK-ID-IF-NEEDED" //Optional, used only if validation is performed as a separate Validation only task
}
```
**一般的な再同期スケジューリングパターンの例**:
+ `0 0 * * *`: 1 日 1 回、午前 0 時に実行します。
+ `0 0,12 * * *`: 1 日 2 回、午前 0 時と正午に実行します。
+ `0 0,2,4,6, * * *`: 午前 0 時から午前 6 時の間、2 時間ごとに実行します。
+ `0 1 * * 1`: 毎週月曜日の午前 1 時に実行します。
**注記**
0～6 の数字を毎日指定する必要があります。詳細については、「[クロン式のルール](#CHAP_DataResync.cron)」を参照してください。
**再同期オペレーションのモニタリング**:
テーブル統計を使用して再同期のオペレーションをモニタリングできます。以下に出力例を示します。
```
{
"TableStatistics": {
...
"ValidationFailedRecords": 1000,
...
"ResyncRowsAttempted": 1000,
"ResyncRowsSucceeded": 995,
"ResyncRowsFailed": 5,
"ResyncProgress": 99.5, // ratio of ResyncRowsSucceeded/ValidationFailedRecords
"ResyncState": "Last resync at: 2024-03-14T06:00:00Z"
}
}
```
でデータ再同期機能を設定するには AWS DMS、さまざまな再同期パラメータとそれぞれの設定を確認できます。詳細については、「[データ再同期設定](CHAP_Tasks.CustomizingTasks.TaskSettings.DataResyncSettings.md)」を参照してください。データ再同期のログ記録設定の詳細については、「[ロギングタスク設定](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md)」を参照してください。
## 検証とトラブルシューティング
**検証**:
データ評価を有効にすると、 は次の構造でターゲットデータベースに検証失敗テーブル AWS DMS を作成します。
```
CREATE TABLE awsdms_validation_failures_v2 (
"RESYNC_ID" bigint NOT NULL,
"TASK_NAME" varchar(128) NOT NULL,
"TABLE_OWNER" varchar(128) NOT NULL,
"TABLE_NAME" varchar(128) NOT NULL,
"FAILURE_TIME" timestamp NOT NULL,
"KEY_TYPE" varchar(128) NOT NULL,
"KEY" varchar(7800) NOT NULL,
"FAILURE_TYPE" varchar(128) NOT NULL,
"DETAILS" varchar(7000) NOT NULL,
"RESYNC_RESULT" varchar(128) NULL,
"RESYNC_TIME" timestamp NULL,
"RESYNC_ACTION" varchar(128) NULL
);
```
このテーブルにクエリを記述して、見つかったデータの不一致とその解決方法を把握することができます。
検証を有効にすると、 はターゲットデータベースに検証失敗テーブル AWS DMS を作成します。問題が発生した場合は、`awsdms_control.awsdms_validation_failures_v2` テーブルにクエリを実行して、見つかったデータの不一致とその解決方法を把握できます。詳細については、「[AWS DMS データ検証](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html)」の「[トラブルシューティング](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting)」セクションを参照してください。
**一般的なワークフロー**:
データ再同期の検証における標準ワークフローは次のとおりです。
**フルロードのみのタスク**:
1. データベース内のすべてのテーブルでロードプロセスを完了します。
1. 不一致は、進行中の検証プロセスで識別されます。
1. データ再同期は、検証プロセスで明らかになった問題を修正します。
1. 検証プロセスで修正を検証します。
1. 移行タスクが正常に完了します。
**CDC タスク**:
1. データベース内のすべてのテーブルでロードプロセスを完了します。
1. 不一致は、進行中の検証プロセスで識別されます。
1. スケジュールされた再同期ウィンドウに従って、レプリケーションタスクは短時間停止します。
1. データ再同期は、検証プロセスで明らかになった問題を修正します。
1. レプリケーションプロセスはスケジュールに従って再開され、繰り返されます。
再同期オペレーション中のレプリケーションタスクの停止、テーブルの再ロードと再検証など、タスクに変更が加えられると、タスクの動作と結果に影響を与える可能性があります。既知の動作変更の一部は、次のとおりです。
**再同期オペレーションの進行中にレプリケーションタスクを停止した場合**:
+ 再同期オペレーションは自動的に再開されません。あらためて再起動する必要があります。
+ その後の再同期オペレーションは、設定されたスケジュールに従って行われます。
+ 不完全な修正は、次のスケジュールされた再同期ウィンドウで試行されます。
**データベースにテーブルを再ロードする場合**:
+ 再同期オペレーションは、再ロード中のテーブルをスキップします。
+ 再ロードされたテーブルに対する以前の検証の失敗は無視されます。
+ 新しい検証は、再ロードアクションが完了した後に開始されます。
**データベースのテーブルを再検証する場合**:
+ 再同期オペレーションのすべての統計がリセットされます。
+ 再検証されたテーブルに対する以前の検証の失敗は無視されます。
**注記**
タスクを DMS バージョン 3.6.1 以降にアップグレードまたは移動する場合、`awsdms_control.awsdms_validation_failures_v1` テーブルの失敗は再同期されません。`awsdms_validation_failures_v2` テーブルの失敗のみ再同期されます。`awsdms_control.awsdms_validation_failures_v2` テーブルで失敗を再同期するには、タスクを再ロードするか、タスク内の 1 つ以上のテーブルを再ロードするか、1 つ以上のテーブルを再検証する必要があります。詳細については、以下のリンクを参照してください。
タスクを再ロードするには、[API リファレンス「`StartReplicationTask`」](https://docs.aws.amazon.com/dms/latest/APIReference/API_StartReplicationTask.html)を参照してください。
タスクで 1 つ以上のテーブルを再ロードするには、「*AWS CLI コマンドリファレンス*」の「[https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html)」を参照してください。
1 つ以上のテーブルを再検証するには、「*AWS CLI コマンドリファレンス*」の「[https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html)」セクションの `validate-only` オプションを参照してください。
.
## cron 式のルール
のレプリケーションタスク中にデータ再同期オペレーションを設定するには AWS DMS 、cron 式ルールを使用できます。このルールにより、再同期ウィンドウをカスタマイズし、ビジネスニーズに合わせてスケジュールできます。分、時、日、月、曜日など、さまざまなパラメータを使用できます。各パラメータの cron 式ルールは次のとおりです。
**分**:
+ 分の範囲は 0～59 です。
+ (`-`)、`or`/`and` を使用して範囲を指定できます。最大 10 個の項目をカンマ (`,`) で区切ることができます。
+ **例:**
+ `2-5` は `2,3,5,5` に等しくなります。
+ `1-2,3-4,5,7-10` は有効な範囲です。
+ `1,2,3,4,5,6,7,8,9,10` は有効な範囲です。
+ `1,2,3,4,5,6,7,8,9,10,11` は有効な範囲ではありません。再同期オペレーションは、10 番目の範囲項目の後にスキップされます。
+ (`*`) を使用できます。例: `*` は `0-59` に等しくなります。
+ (`/`) は、(`-`) または (`*`) と組み合わせた形でのみ使用できます。
**例:**
+ `2-7/2` は `2,4,6` に等しくなります。
+ `*/15` は `0,15,30,45` に等しくなります。
**時間**:
「**分**」と同じですが、有効な範囲は `0` から `23` です。
**日**:
+ 「**分**」と同じですが、有効な範囲は `1` から `31` です。
+ `L` の使用は再同期設定でサポートされています。これは、月の最終日として解釈されます。別の構文と組み合わせて使用しないでください。
**月**:
「**分**」と同じですが、有効な範囲は `1` から `12` です。
**曜日**:
+ 「**分**」と同じですが、有効な範囲は `0` から `6` です。
+ 曜日に文字列値を追加することはできません。