翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS DMS データ検証 **Topics** + [レプリケーションタスクの統計](#CHAP_Validating.TaskStatistics) + [Amazon CloudWatch を使用したレプリケーション タスクの統計](#CHAP_Validating.TaskStatistics.CloudWatch) + [タスク実行中のテーブル再検証](#CHAP_Validating.Revalidating) + [JSON エディタを使用して検証ルールを変更する](#CHAP_Validating.JSONEditor) + [検証のみのタスク](#CHAP_Validating.ValidationOnly) + [トラブルシューティング](#CHAP_Validating.Troubleshooting) + [Redshift 検証パフォーマンス](#CHAP_Validating.Redshift) + [の拡張データ検証 AWS Database Migration Service](#CHAP_Validating_Enhanced) + [制限事項](#CHAP_Validating.Limitations) + [Amazon S3 ターゲットのデータ検証](CHAP_Validating_S3.md) + [AWS DMS データの再同期](CHAP_Validating.DataResync.md) AWS DMS は、データの検証をサポートして、データがソースからターゲットに正確に移行されたことを確認します。有効な場合、テーブルに対して全ロードが実行された後で、検証がすぐに開始します。検証では、CDC が有効なタスクの増分変更が発生したときに比較されます。 データ検証中、 はソースの各行をターゲットの対応する行 AWS DMS と比較し、行に同じデータが含まれていることを確認し、不一致があれば報告します。これを実現するには、データを取得するための AWS DMS 適切なクエリを実行します。これらのクエリは、ソースとターゲットで追加リソースと、追加ネットワークリソースを消費します。 CDC のみのタスクで検証が有効になっている場合、新しいデータの検証を開始する前に、テーブル内のすべての既存データが検証されます。 データ検証は、 がソースエンドポイントとして AWS DMS サポートしている場合、次のソースデータベースと連携します。 + Oracle + PostgreSQL 互換データベース（PostgreSQL または Aurora PostgreSQL、Aurora Serverless for PostgreSQL） + MySQL 互換データベース (MySQL または MariaDB、Aurora MySQL、Aurora Serverless for MySQL) + Microsoft SQL Server + IBM Db2 LUW データ検証は、 がターゲットエンドポイントとして AWS DMS サポートしている場合、次のターゲットデータベースで機能します。 + Oracle + PostgreSQL 互換データベース（PostgreSQL または Aurora PostgreSQL、Aurora Serverless for PostgreSQL） + MySQL 互換データベース (MySQL または MariaDB、Aurora MySQL、Aurora Serverless for MySQL) + Microsoft SQL Server + IBM Db2 LUW + Amazon Redshift + Amazon S3。Amazon S3 ターゲットデータの検証については、「[Amazon S3 ターゲットのデータ検証](CHAP_Validating_S3.md)」を参照してください。 サポートされているエンドポイントの詳細については、「[DMS AWS エンドポイントの使用](CHAP_Endpoints.md)」をご参照ください。 データの検証には、移行自体に必要な時間以外にも、さらに時間がかかります。必要な追加の時間は、移行されたデータの量によって異なります。 これらの設定の詳細については、「[データ検証タスクの設定](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md)」をご参照ください。 JSON ファイル内の `ValidationSettings` タスク設定の例については、[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example) を参照してください。 ## レプリケーションタスクの統計 データ検証が有効になっている場合、 はテーブルレベルで次の統計 AWS DMS を提供します。 + **[ValidationState]** (検証状態) — テーブルの検証状態。このパラメータには以下の値があります。 + **Not enabled** — 移行タスクでテーブルに対して検証が有効化されていません。 + **Pending records** — テーブル内の一部のレコードが、検証を待機しています。 + **[Mismatched records]** (不一致レコード) – テーブル内の一部のレコードが、ソースとターゲット間で一致しません。さまざまな理由により、不一致が発生することがあります。詳細については、ターゲットエンドポイントの `awsdms_control.awsdms_validation_failures_v1` を確認してください。 + **Suspended records** – テーブル内に検証できないレコードがあります。 + **No primary key** – テーブルにプライマリキーがないため、検証できません。 + **[Table error]** (テーブルエラー)– テーブルがエラー状態で一部のデータが移行されなかったため、テーブルは検証されませんでした。 + **[Validated]** (検証済み) – テーブル内のすべての行が検証されます。テーブルが更新された場合、ステータスは [Validated] から変わる可能性があります。 + **Error** – 予期しないエラーが発生したため、テーブルを検証できません。 + **[Pending validation]** (検証保留中) — テーブルは検証を待っています。 + **[Preparing table]** (テーブルの準備) — 移行タスクで有効になっているテーブルの検証を準備します。 + **[Pending revalidation]** (保留中の再検証) —テーブルが更新された後で、テーブル内のすべての行が検証を保留します。 + **ValidationPending** – ターゲットに移行されたが、まだ検証されていないレコードの数。 + **ValidationSuspended** — 比較 AWS DMS できないレコードの数。たとえば、ソースのレコードが常に更新されている場合、 AWS DMS はソースとターゲットを比較できません。 + **[ValidationFailed]** (検証失敗) – データの検証フェーズに合格しなかったレコードの数。 JSON ファイル内の `ValidationSettings` タスク設定の例については、[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example) を参照してください。 コンソール、、または AWS DMS API を使用して AWS CLI、データ検証情報を表示できます。 + コンソールで、タスクを作成または変更するときにタスクの検証を選択できます。コンソールを使用してデータ検証レポートを表示するには、[**Tasks**] ページでタスクを選択し、詳細セクションの [**Table statistics**] タブを選択します。 + CLI を使用して、タスク作成時または変更時にデータ検証を開始する場合は、`EnableValidation` パラメータを `true` に設定します。以下の例では、タスクを作成し、データ検証を有効にします。 ``` create-replication-task --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}' --replication-instance-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q --source-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CSZAEFQURFYMM --target-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CGPP7MF6WT4JQ --migration-type full-load-and-cdc --table-mappings '{"rules": [{"rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": {"schema-name": "data_types", "table-name": "%"}, "rule-action": "include"}]}' ``` `describe-table-statistics` コマンドを使用して、JSON 形式でデータ検証レポートを受け取ります。以下のコマンドでは、データ検証レポートを表示します。 ``` aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q ``` このレポートは以下の例のようになります。 ``` { "ReplicationTaskArn": "arn:aws:dms:us-west-2:5731014:task:VFPFTYKK2RYSI", "TableStatistics": [ { "ValidationPendingRecords": 2, "Inserts": 25, "ValidationState": "Pending records", "ValidationSuspendedRecords": 0, "LastUpdateTime": 1510181065.349, "FullLoadErrorRows": 0, "FullLoadCondtnlChkFailedRows": 0, "Ddls": 0, "TableName": "t_binary", "ValidationFailedRecords": 0, "Updates": 0, "FullLoadRows": 10, "TableState": "Table completed", "SchemaName": "d_types_s_sqlserver", "Deletes": 0 } } ``` + AWS DMS API を使用して、**CreateReplicationTask** アクションを使用してタスクを作成し、 `EnableValidation`パラメータを **true** に設定して、タスクによって移行されたデータを検証します。**DescribeTableStatistics** アクションを使用して、JSON 形式でデータ検証レポートを受け取ります。 ## Amazon CloudWatch を使用したレプリケーション タスクの統計 Amazon CloudWatch が有効になっている場合、 は次のレプリケーションタスク統計 AWS DMS を提供します。 + **ValidationSucceededRecordCount** — が AWS DMS 検証した 1 分あたりの行数。 + **ValidationAttemptedRecordCount** - 検証が試行された行の 1 分あたりの数。 + **ValidationFailedOverallCount** - 検証が失敗した行の数。 + **ValidationSuspendedOverallCount** - 検証が停止された行の数。 + **ValidationPendingOverallCount** - 検証がまだ保留中の行の数。 + **ValidationBulkQuerySourceLatency** — AWS DMS は、特に多くの変更がある場合、全ロードまたは継続的レプリケーション中の特定のシナリオで、データ検証を一括実行できます。このメトリックスは、ソースエンドポイントから大量のデータを読み取るために必要なレイテンシーを示します。 + **ValidationBulkQueryTargetLatency** — AWS DMS は、特に多くの変更がある場合、ロードまたは継続的レプリケーション中の特定のシナリオで、データ検証を一括実行できます。このメトリックスは、ターゲットエンドポイントの大量のデータを読み取るために必要なレイテンシーを示します。 + **ValidationItemQuerySourceLatency** - 継続的レプリケーションでは、データ検証によって継続的変更を識別し、それらの変更を検証できます。このメトリックスは、変更をソースから読み取る際のレイテンシーを示します。検証中にエラーが発生した場合、検証では必要な数以上のクエリを実行できます。 + **ValidationItemQueryTargetLatency** - 継続的レプリケーションでは、データ検証によって継続的変更を識別し、それらの変更を行ごとに検証できます。このメトリックスは、変更をターゲットから読み取る際のレイテンシーを示します。検証中にエラーが発生した場合、検証では必要な数以上のクエリが実行される場合があります。 CloudWatch が有効な統計情報からデータ検証情報を収集するには、タスクを作成または変更するとき、**[Enable CloudWatch logs]** (CloudWatch ログを有効にする) コンソールを使用します。次に、データ検証情報を確認し、データがソースからターゲットに正確に移行されたことを確認するため、以下を行います。 1. **[Database migration tasks]** (データベース移行タスク) ページでタスクを選択します。 1. **[CloudWatch metrics]** (CloudWatch メトリクス) タブ。 1. CloudWatch が有効な統計情報からデータ検証情報を収集するには、タスクを作成または変更するとき、**[Enable CloudWatch logs]** (CloudWatch ログを有効にする) コンソールを使用します。 ## タスク実行中のテーブル再検証 タスクの実行中に、 AWS DMS にデータ検証の実行をリクエストできます。 ### AWS マネジメントコンソール 1. にサインイン AWS マネジメントコンソール し、[https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) で AWS DMS コンソールを開きます。 AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合は、 にアクセスするための適切なアクセス許可があることを確認してください AWS DMS。必要なアクセス許可については、「」を参照してください[を使用するために必要な IAM アクセス許可 AWS DMS](security-iam.md#CHAP_Security.IAMPermissions)。 1. ナビゲーションペインから [**Tasks**] を選択します。 1. 再検証するテーブルを含む実行中のタスクを選択します。 1. [**テーブル統計**] タブを選択します。 1. 再検証するテーブルを選択します (一度に最大 10 個のテーブルを選択できます)。タスクがすでに実行されていない場合は、テーブルを再検証できません。 1. [**Revalidate (再検証)**] を選択します。 ## JSON エディタを使用して検証ルールを変更する AWS DMS コンソールの JSON エディタを使用してタスクに検証ルールを追加するには、次の手順を実行します。 1. **[Database migration tasks]** (データベース移行タスク) を選択します。 1. 移行タスクの一覧からタスクを選択します。 1. タスクが実行中の場合には、**[Actions]** (アクション) ドロップダウンメニューから**[Stop]** (停止) を選択します。 1. タスクが停止したら、タスクを変更するには、**[Actions]** (アクション) ドロップダウンメニューから**[Modify]** (変更) を選択します。 1. **[Table mappings]** (テーブルマッピング) セクションで、**[JSON editor]** (JSON エディター) を選択し、検証ルールをテーブルマッピングに追加します。 たとえば、次の検証ルールを追加して、ソースで置換関数を実行できます。この場合、検証ルールがヌルバイトを検出すると、それをスペースとして検証します。 ``` { "rule-type": "validation", "rule-id": "1", "rule-name": "1", "rule-target": "column", "object-locator": { "schema-name": "Test-Schema", "table-name": "Test-Table", "column-name": "Test-Column" }, "rule-action": "override-validation-function", "source-function": "REPLACE(${column-name}, chr(0), chr(32))", "target-function": "${column-name}" } ``` **注記** 列がプライマリキーの一部である場合、`override-validation-function` は有効になりません。 ## 検証のみのタスク 検証専用タスクを作成して、移行やデータレプリケーションを実行せずにデータをプレビューしたり検証したりできます。検証のみのタスクを作成するには、`EnableValidation` 設定と `ValidationOnly` 設定を `true` に設定します。`ValidationOnly` を有効にすると、追加の要件が適用されます。詳細については、「[データ検証タスクの設定](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md)」を参照してください。 フルロードのみの移行タイプで多くの障害がレポートされた場合、検証のみのタスクでは CDC の同等のタスクよりもはるかに速く完了します ただし、ソースエンドポイントまたはターゲットエンドポイントへの変更は、フルロードモードの障害としてレポートされることが不利な点となる可能性があります。 CDC 検証のみのタスクは、平均レイテンシーに基づいて検証を遅らせ、障害を報告する前に複数回再試行します。データ比較の大部分が障害付きで完了する場合、CDC モードの検証のみタスクは非常に遅く、不利となる可能性があります。 検証のみのタスクは、特に CDC の場合、レプリケーションタスクと同じ方向に設定する必要があります。これは、CDC 検証のみのタスクが、ソースの変更ログに基づいて変更され、再検証が必要な行を検出するためです。ターゲットがソースとして指定されている場合、ターゲットは DMS がターゲットに送信した変更についてのみ認識するため、レプリケーションエラーが検出される保証はありません。 ### フルロード検証のみ AWS DMS バージョン 3.4.6 以降では、全ロード検証のみのタスクは、ソーステーブルとターゲットテーブルのすべての行を 1 回のパスですばやく比較し、障害があればすぐに報告してからシャットダウンします。このモードでは障害が発生しても検証が中断されることはなく、速度が最適化されます。ただし、ソースまたはターゲットエンドポイントへの変更は失敗として報告されます。 **注記** AWS DMS バージョン 3.4.6 以降では、この検証動作は、検証が有効になっている全ロード移行タスクにも適用されます。 ### CDC 検証のみ CDC 検証のみのタスクでは、新たな開始時にソーステーブルとターゲットテーブル間の既存のすべての行を検証します。さらに、CDC 検証のみのタスクは継続的に実行され、継続的なレプリケーションの変更は再検証され、各パスで報告される失敗の数は制限され、不一致の行は失敗する前に再試行されます。誤検出を防ぐように最適化されています。 ` FailureMaxCount` または `TableFailureMaxCount` のしきい値を超えると、テーブル (またはタスク全体) の検証が中断されます。これは、検証が有効になっている CDC またはフルロード \$1 CDC 移行タスクにも適用されます。また、検証が有効になっている CDC タスクでは、ソースとターゲットの平均レイテンシーにより、変更された各行の再検証が遅延します。 ただし、CDC **検証のみのタスクではデータは移行されず、レイテンシーもありません。デフォルトでは、`ValidationQueryCdcDelaySeconds` は 180 に設定されます。レイテンシーが高い環境のアカウントではこの量を増やし、誤検出を防ぐこともできます。 ### 検証のみのユースケース 移行またはレプリケーションタスクのデータ検証部分を別の**検証のみのタスクに分割するユースケースには、次がありますが、これらに限定されません。 + **検証がいつ行われるかを正確に制御する — 検証クエリを使用すると、ソースエンドポイントとターゲットエンドポイントの両方に追加の負荷がかかります。そのため、最初に 1 つのタスクでデータを移行またはレプリケートして、次に別のタスクで結果を検証すると、有益な場合があります。 + **レプリケーションインスタンスの負荷を軽減する — データ検証を分割して独自のインスタンスで実行すると、利点が得られる場合があります。 + **特定の時点で一致しない行の数を迅速に取得する — 例えば、ターゲットエンドポイントへのメンテナンスウィンドウの本番環境のカットオーバーの直前または最中に、フルロード検証のみのタスクを作成すると、質問への回答を得られます。 + **CDC コンポーネントを使用した移行タスクで検証の失敗が予想される場合 — 例えば、Oracle の `varchar2` を PostgreSQL の `jsonb` に移行する場合、CDC 検証は、このような失敗した行の再試行を引き続き行い、毎回レポートされる障害の数を制限します。ただし、フルロード検証のみのタスクを作成すると、より迅速に回答を得ることができます。 + **検証に失敗したテーブルを読み取るデータ修復スクリプトまたはユーティリティを開発する — ([トラブルシューティング](#CHAP_Validating.Troubleshooting) も参照)。フルロード検証のみのタスクでは、データ修復スクリプトが対応できるように障害を迅速にレポートします。 JSON ファイル内の `ValidationSettings` タスク設定の例については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」を参照してください)。 ## トラブルシューティング 検証中、 はターゲットエンドポイント に新しいテーブル AWS DMS を作成します`awsdms_control.awsdms_validation_failures_v1`。レコードが *ValidationSuspended* または *ValidationFailed* 状態になると、 は診断情報を に AWS DMS 書き込みます`awsdms_control.awsdms_validation_failures_v1`。このテーブルをクエリすることで、検証エラーをトラブルシューティングすることができます。 ターゲット上でテーブルが作成されるデフォルトスキーマの変更については、「[制御テーブルタスク設定](CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.md)」をご参照ください。 以下に、`awsdms_control.awsdms_validation_failures_v1` テーブルの説明を示します。 | [列名] | データ型 | 説明 | | --- | --- | --- | | `TASK_NAME` | `VARCHAR(128) NOT NULL` | AWS DMS タスク識別子。 | | TABLE\$1OWNER | VARCHAR(128) NOT NULL | テーブルのスキーマ (所有者)。 | | `TABLE_NAME` | VARCHAR(128) NOT NULL | テーブル名。 | | FAILURE\$1TIME | DATETIME(3) NOT NULL | イベントが失敗した時刻。 | | KEY\$1TYPE | VARCHAR(128) NOT NULL | 将来の使用のために予約済み (値は常に [Row](行)) | | KEY | TEXT NOT NULL | これは行レコードタイプのプライマリキーです。 | | FAILURE\$1TYPE | VARCHAR(128) NOT NULL | 検証エラーの重大度。`RECORD_DIFF`、`MISSING_SOURCE`、`MISSING_TARGET`、または `TABLE_WARNING` のいずれかになります。 | | DETAILS | VARCHAR(8000) NOT NULL | 所与のキーと一致しないすべてのソース/ターゲット列の値を含む JSON 形式の文字列です。 | 以下のサンプルクエリでは、MySQL ターゲットが `awsdms_control.awsdms_validation_failures_v1` テーブルに対してクエリを実行して、タスクのすべての失敗を表示します。スキーマ名とクエリ構文は、ターゲットのエンジンバージョンによって異なることに注意してください。タスク名は、タスクの外部リソース ID である必要があります。タスクの外部リソース ID は、タスク ARN の最後の値です。たとえば、ARN 値が arn:aws:dms:us-west-2:5599:task: VFPFKH4FJR3FTYKK2RYSI のタスクの場合、タスクの外部リソース ID は VFPFKH4FJR3FTYKK2RYSI となります。 ``` select * from awsdms_validation_failures_v1 where TASK_NAME = 'VFPFKH4FJR3FTYKK2RYSI' TASK_NAME VFPFKH4FJR3FTYKK2RYSI TABLE_OWNER DB2PERF TABLE_NAME PERFTEST FAILURE_TIME 2020-06-11 21:58:44 KEY_TYPE Row KEY {"key": ["3451491"]} FAILURE_TYPE RECORD_DIFF DETAILS [[{'MYREAL': '+1.10106036e-01'}, {'MYREAL': '+1.10106044e-01'}],] ``` `DETAILS` フィールドを参照し、一致しない列を特定します。失敗したレコードのプライマリ キーを入手したら、ソース エンドポイントとターゲット エンドポイントをクエリし、レコードの不一致部分を確認できます。 ### `awsdms_validation_failures_v2` コントロールテーブル 検証中、 AWS DMS バージョン 3.6.1 以降では、DMS は PostgreSQL ターゲットエンドポイント に新しいテーブルを作成します`awsdms_validation_failures_v2`。このテーブルは、データ検証が有効になっているすべての DMS タスクの失敗で構成されます。`awsdms_validation_failures_v2` テーブルを作成するときは、検証と再同期が有効になっているタスクではエラーが発生する可能性があるため、テーブルを削除または切り捨てないでください。`awsdms_validation_failures_v2` テーブルには自動増分プライマリキー機能があります。このテーブルは、データの再同期機能をサポートする新しい列で構成されます。具体的には次の 2 つです。 `RESYNC_RESULT` **値**: `SUCCESS` または `FAILURE`。 **`RESYNC_TIME`** ミリ秒精度のタイムスタンプ。この失敗でデータの再同期が試行されない場合、デフォルト値は `NULL` です。 **`RESYNC_ACTION`** **値**: `UPSERT` または `DELETE`。 `RESYNC_ID` 自動増分が有効になっているプライマリキー列。 `awsdms_validation_failures_v2` テーブルでは、インデックスが `TASK_NAME`、`TABLE_OWNER`、`TABLE_NAME`、`FAILURE_TYPE`、および `FAILURE_TIME` 列に追加され、ターゲットデータベースで特定のテーブルに関する失敗の読み取りが効率的に行われます。以下は、`awsdms_validation_failures_v2` テーブルを作成するための create ステートメントの例です。 ``` CREATE TABLE public.awsdms_validation_failures_v2 ( "RESYNC_ID" int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) 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, CONSTRAINT awsdms_validation_failures_v2_pkey PRIMARY KEY ("RESYNC_ID") ); ``` ## Redshift 検証パフォーマンス Amazon Redshift は、いくつかの点 (列指向ストレージ、MPP、データ圧縮、その他の要因など) でリレーショナルデータベースとは異なります。これらの違いにより、Redshift はリレーショナルデータベースとは異なるパフォーマンスプロファイルを持ちます。 フルロードレプリケーションフェーズでは、検証で範囲クエリを使用し、データサイズは `PartitionSize` 設定によって決まります。これらの範囲ベースのクエリは、ソーステーブルからすべてのレコードを選択します。 継続的なレプリケーションの場合、クエリは範囲ベースのフェッチと個別レコードのフェッチを切り替えます。クエリタイプは、次のような複数の要因に基づいて動的に決定されます。 + クエリボリューム + ソーステーブルの DML クエリのタイプ + タスクレイテンシー + レコード総数 + 検証設定 (`PartitionSize` など) 検証クエリにより、Amazon Redshift クラスターに追加の負荷がかかる場合があります。上記の要因はユースケースによって異なるため、検証クエリのパフォーマンスを確認してクラスターとテーブルを相応に調整する必要があります。パフォーマンスの問題を軽減するためのオプションには、次のようなものがあります。 + `PartitionSize` および `ThreadCount` の設定を減らして、フルロード検証中のワークロードを軽減します。これにより、データ検証が遅くなることに注意してください。 + Redshift はプライマリキーを強制しませんが、 AWS DMS はプライマリキーに依存して、データ検証のためにターゲット上のレコードを一意に識別します。可能であれば、ソートキーをミラーリングするようにプライマリキーを設定し、フルロード検証クエリの実行を迅速化します。 ## の拡張データ検証 AWS Database Migration Service AWS Database Migration Service は、データベース移行のデータ検証パフォーマンスを強化し、処理時間を大幅に短縮して大規模なデータセットを検証できるようにします。この拡張データ検証は、フルロードとCDC 移行タスクによるフルロードの両方で、レプリケーションエンジンのバージョン 3.5.4 で利用可能になりました。この機能強化では現在、Oracle から PostgreSQL、SQL Server から PostgreSQL、Oracle から Oracle、SQL Server から SQL Server への移行パスがサポートされており、今後のリリースで追加の移行パスが予定されています。 ### 前提条件 + *Oracle:* Oracle エンドポイントにアクセスするユーザーアカウントに `SYS.DBMS_CRYPTO` に対する `EXECUTE` アクセス許可を付与します。 ``` GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_endpoint_user; ``` + PostgreSQL データベースに `pgcrypto` 拡張機能をインストールします。 セルフマネージド PostgreSQL インスタンスの場合は、`contrib` モジュールライブラリをインストールして拡張機能を作成する必要があります。 + `contrib` モジュールライブラリをインストールします。例えば、Amazon Linux および PostgreSQL 15 を使用する Amazon EC2 インスタンスの場合: ``` sudo dnf install postgresql15-contrib ``` + `pgcrypto` エクステンションを作成します。 ``` CREATE EXTENSION IF NOT EXISTS pgcrypto; ``` + Amazon RDS for PostgreSQL インスタンスの場合、 AWS DMS エンドポイントの SSL モードを設定します。 + デフォルトでは、Amazon RDS は SSL 接続を強制します。Amazon RDS for PostgreSQL インスタンスの AWS DMS エンドポイントを作成するときは、「SSL モード」オプション =「必須」を使用します。 + [SSL モード] オプション = [なし] を使用する場合は、RDS パラメータグループで `rds.force_ssl` パラメータを 0 に設定します。 + PostgreSQL 12 および 13 の場合は、`BIT_XOR` 集計を作成します。 ``` CREATE OR REPLACE AGGREGATE BIT_XOR(IN v bit) (SFUNC = bitxor, STYPE = bit); ``` ### データ検証の制限の強化 この拡張データ検証機能には、次の制限があります。 + データベースエンドポイントの要件: この改善は、次の条件を満たすデータベースエンドポイントでのみ有効になります。 + AWS Secrets Manager を使用して認証情報を保存します。 + Microsoft SQL Server では、Kerberos 認証もサポートされています。 + データベースバージョンのサポート: + PostgreSQL 12 以上 + Oracle 12.1 以降 + 2019 年以前の Microsoft SQL Server バージョンでは、NCHAR および NVARCHAR データ型での検証はサポートされていません。 ## 制限事項 + データ検証では、テーブルにプライマリキーまたは一意のインデックスがなければなりません。 + プライマリキー列の型を `CLOB`、`BLOB`、`BINARY`、または `BYTE` に設定することはできません。 + 型が `VARCHAR` または `CHAR` であるプライマリキー列の場合、長さは 1024 未満にする必要があります。データ型の長さを指定する必要があります。無制限のデータ型をデータ検証のプライマリキーとして使用することはできません。 + `NOVALIDATE` 句を使用して作成された Oracle キーは、プライマリ キーまたは一意のインデックスと見なされ*ません*。 + プライマリキーがなく一意キーのみを持つ Oracle テーブルの場合、一意制約のある列にも `NOT NULL` 制約が必要です。 + NULL PK/UK 値の検証はサポートされていません。 + ターゲット PostgreSQL インスタンスのプライマリキー列の照合が「C」に設定されていない場合、プライマリキーと Oracle ではソート順が異なります。PostgreSQL と Oracle でソート順序が異なる場合、データ検証でレコードの検証に失敗します。 + データ検証では、ソースデータベースとターゲットデータベースに対して追加のクエリが生成されます。両方のデータベースに、この追加の負荷を処理するための十分なリソースがあることを確認する必要があります。これは特に Redshift ターゲットに当てはまります。詳細については、「[Redshift 検証パフォーマンス](#CHAP_Validating.Redshift)」を参照してください。 + 複数のデータベースを 1 つに統合する場合、データ検証はサポートされません。 + ソースまたはターゲット Oracle エンドポイントの場合、 は AWS DMS を使用します`DBMS_CRYPTO`。Oracle エンドポイントでデータ検証を使用する場合は、Oracle エンドポイントにアクセスするために使用されるユーザーアカウントに、`dbms_crypto` での実行権限を付与する必要があります。これを行うには、以下のステートメントを実行します。 ``` grant execute on sys.dbms_crypto to dms_endpoint_user; ``` + 検証 AWS DMS 中にターゲットデータベースが の外部で変更された場合、不一致は正確に報告されない可能性があります。この結果は、アプリケーションの 1 つがターゲットテーブルにデータを書き込み、 AWS DMS が同じテーブルで検証を実行している場合に発生する可能性があります。 + 検証中に 1 つ以上の行が継続的に変更されている場合、 AWS DMS はそれらの行を検証できません。 + が 10,000 件を超える失敗したレコードまたは中断されたレコード AWS DMS を検出すると、検証が停止します。先に進む前に、データの根本的な問題を解決する必要があります。 + AWS DMS はビューのデータ検証をサポートしていません。 + AWS DMS は、文字置換タスク設定を使用する場合のデータ検証をサポートしていません。 + AWS DMS は Oracle LONG タイプの検証をサポートしていません。 + AWS DMS は、異種移行中の Oracle Spatial タイプの検証をサポートしていません。 + データ検証では、テーブルマッピングにデータマスキング変換が存在するテーブルの列は無視されます。 + PK/UK 列のデータマスキング変換ルールがある場合、データ検証はテーブル全体をスキップします。検証状態では、このようなテーブルに対してプライマリキーなしと表示されます。 + データ検証は Amazon Aurora PostgreSQL Limitless では機能しません。Limitless Database でテーブルを検証しようとすると、これらのテーブルで「プライマリキーなし」が検証状態に表示されます。 S3 ターゲット検証を使用する際の制限については、「[ターゲットの S3 の検証を使用する場合の制限](CHAP_Validating_S3.md#CHAP_Validating_S3_limitations)」を参照してください。 # Amazon S3 ターゲットのデータ検証 AWS DMS は、Amazon S3 ターゲットでレプリケートされたデータの検証をサポートしています。 AWS DMS はレプリケートされたデータをフラットファイルとして Amazon S3 に保存するため、[Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html) `CREATE TABLE AS SELECT` (CTAS) クエリを使用してデータを検証します。 Amazon S3 に保存されているデータに対するクエリは、多大なコンピューティングが必要となるため、したがって、 は変更データキャプチャ (CDC) 中に Amazon S3 データの検証を 1 日 1 回、UTC 午前 0 時 (00:00) に AWS DMS 実行します。が AWS DMS 実行する各日次検証は、*間隔検証*と呼ばれます。間隔の検証中に、 は過去 24 時間ターゲット Amazon S3 バケットに移行されたすべての変更レコード AWS DMS を検証します。間隔検証の制限の詳細については、「[ターゲットの S3 の検証を使用する場合の制限](#CHAP_Validating_S3_limitations)」を参照してください。 Amazon S3 のターゲット検証では Amazon Athena を使用するため、追加料金が適用されます。詳細については、[Amazon Athena 料金](https://aws.amazon.com/athena/pricing/) を参照してください。 **注記** S3 ターゲットの検証には、 AWS DMS バージョン 3.5.0 以降が必要です。 **Topics** + [前提条件](#CHAP_Validating_S3_prerequisites) + [アクセス許可](#CHAP_Validating_S3_permissions) + [制限事項](#CHAP_Validating_S3_limitations) + [検証のみのタスク](#CHAP_Validating_S3_only) ## S3 ターゲット検証の前提条件 S3 ターゲット検証を使用する前に、次の設定とアクセス許可を確認します。 + エンドポイントの [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html) の `DataFormat` 値を `parquet` に設定します。詳細については、「[S3 の parquet 設定](CHAP_Target.S3.md#CHAP_Target.S3.EndpointSettings.Parquet)」を参照してください。 + 移行タスクの作成に使用するユーザーアカウントに割り当てられたロールに、適切なアクセス許可のセットが付与されていることを確認します。次の「[アクセス許可](#CHAP_Validating_S3_permissions)」を参照してください。 継続的なレプリケーション (CDC) を使用するタスクの場合は、次の設定を確認します。 + 補足ログを有効にすると、CDC データに完全な記録を残せます。補足ロギングを有効にする方法については、このガイドの「[トラブルシューティングと診断サポートレイテンシーのトラブルシューティング](CHAP_Troubleshooting.md)」セクションの「[Oracle ソース エンドポイントにサプリメンタル ログを自動的に追加する](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Oracle.AutoSupplLogging)」を参照してください。 + ターゲットエンドポイントの `TimestampColumnName` パラメータを設定します。タイムスタンプ列名には制限はありません。詳細については、[[S3Settings]](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html) (S3設定)をご参照ください。 + ターゲットでの日付ベースのフォルダ分割を設定します。詳細については、「[日付ベースのフォルダパーティション分割を使用する](CHAP_Target.S3.md#CHAP_Target.S3.DatePartitioning)」を参照してください。 ## ターゲットの S3 の検証を使用するためのアクセス許可 ターゲットの S3 の検証を使用するためのアクセス許可を設定するには、移行タスクの作成に使用するユーザーアカウントに割り当てられたロールに、次のとおりのアクセス許可のセットが付与されていることを確認します。サンプル値は実際の値に置き換えます。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:CreateWorkGroup" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:CreateDatabase", "glue:DeleteDatabase", "glue:GetDatabase", "glue:GetTables", "glue:CreateTable", "glue:DeleteTable", "glue:GetTable" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": "*" } ] } ``` ------ ## ターゲットの S3 の検証を使用する場合の制限 ターゲットの S3 の検証を使用する場合に適用される追加の制限は、次のとおりです。すべての検証に適用される制限については、「[制限事項](CHAP_Validating.md#CHAP_Validating.Limitations)」を参照してください。 + `DatePartitionSequence` 値には Day コンポーネントが必要です。ターゲットの S3 の検証は、`YYYYMM` 形式をサポートしていません。 + CDC 中に間隔検証を実行すると、`awsdms_validation_failures_v1` テーブルに誤った検証エラーが表示されることがあります。これらのエラーは、間隔の検証中に到着した変更を翌日のパーティションフォルダ AWS DMS に移行するために発生します。このような変更は通常、当日のパーティションフォルダに書き込まれます。このような誤ったエラーは、動的ソースデータベースから Amazon S3 などの静的ターゲットへのレプリケーションの検証の制限です。このような誤ったエラーを調べるには、検証期間の終わり (UTC 00:00) 付近のレコードを確認します。エラーは通常、この時間帯に表示されます。 誤ったエラーの数を最小限に抑えるには、タスクの `CDCLatencySource` が低く設定されていることを確認します。レイテンシーのモニタリングの詳細については、「[レプリケーションタスクのメトリクス](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task)」を参照してください。 + `failed` または `stopped` の状態のタスクは前日の変更を検証しません。予期しない障害による検証エラーを最小限に抑えるには、テーブルマッピング、ソースエンドポイント、ターゲットエンドポイントに同じ検証のみのタスクを個別に作成します。データ検証の詳細については、「[S3 ターゲット検証での検証のみのタスクの使用](#CHAP_Validating_S3_only)」を参照してください。 + テーブル統計の **[検証ステータス]** 列には、最新の間隔検証の状態が反映されます。そのため、不一致のあるテーブルが翌日の間隔検証後に検証済みとして表示される可能性があります。ターゲットの Amazon S3 バケット内の `s3_validation_failures folder` フォルダを調べて、1 日以上前に発生した不一致がないかを確認します。 + S3 Validation は、Amazon Athena のバケットテーブル機能を使用します。これにより、S3 検証はターゲットのテーブルデータのバケットコピーを作成できます。つまり、テーブルデータのコピーは、DMS 検証の内部パーティショニングに一致するサブセットに分割されます。Athena バケットテーブルには、100,000 バケットの制限があります。この制限を超える S3 検証が検証を試みるテーブルは、検証に失敗します。S3 Validation が作成を試みるバケットの数は、次と等しくなります。 ``` (#records in the table) / (validation partition size setting) ``` この制限を回避するには、S3 Validation によって作成されたバケット数が 100,000 未満になるように、検証パーティションサイズ設定を大きくします。バケット化の詳細については、「*Amazon Athena ユーザーガイド*」の「[パーティショニングとバケット化を使用する](https://docs.aws.amazon.com/athena/latest/ug/ctas-partitioning-and-bucketing.html)」を参照してください。 + テーブル名にはアンダースコア以外の特殊文字を含めることはできません。 S3 Validation は、テーブル名の特殊文字 (アンダースコア以外) をサポートしていない Amazon Athena を使用します。詳細については、「*Amazon Athena ユーザーガイド*」の「[CREATE TABLE](https://docs.aws.amazon.com/athena/latest/ug/create-table.html)」を参照してください。 + AWS Lake Formation が管理する Amazon S3 ターゲットで AWS DMS データ検証機能を使用すると、検証プロセスは失敗します。これにより、データ整合性の問題が生じる可能性があります。 ## S3 ターゲット検証での検証のみのタスクの使用 **検証のみのタスクでは、移行は実行せず、移行されるデータの検証を実行します。 検証のみのタスクは、移行タスクが停止しても実行され続け、 AWS DMS が 00:00 UTC 間隔の検証ウィンドウを見逃さないようにします。 Amazon S3 ターゲットエンドポイントで検証のみのタスクを使用する場合、次の制限があります。 + 検証のみの設定が有効になっているフルロードタスクの Amazon S3 検証はサポートされています。ただし、その他のエンドポイントのフルロードタスクや検証のみのタスクとは動作が異なります。S3 をターゲットとして使用する場合、このようなタイプのタスクは S3 ターゲットのフルロードデータのみを検証し、CDC 移行の一環として移行されたデータは検証されません。この機能は、フルロードのみのタスクが作成したデータを検証する場合にのみ使用します。アクティブな CDC タスクが実行されているターゲットでこのモードを使用してデータを検証しても、効果的な検証は行われません。 + 検証のみのタスクは、最後の間隔検証期間 (UTC 00:00) 以降の変更のみを検証します。検証のみのタスクでは、前日のフルロードデータや CDC データは検証されません。 # 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` です。 + 曜日に文字列値を追加することはできません。