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

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 ターゲットのデータ検証」を参照してください。

ValidationState— テーブルの検証状態。このパラメータには以下の値があります。

ValidationPending— ターゲットに移行されたが、まだ検証されていないレコードの数。

ValidationSuspended— 比較 AWS DMS できないレコードの数。例えば、ソースのレコードが常に更新されている場合、 AWS DMS はソースとターゲットを比較できません。

ValidationFailed— データ検証フェーズに合格しなかったレコードの数。

コンソールで、タスクを作成または変更するときにタスクの検証を選択できます。コンソールを使用してデータ検証レポートを表示するには、[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 形式でデータ検証レポートを受信します。

ValidationSucceededRecordCount— AWS DMS 検証した 1 分あたりの行数。

ValidationAttemptedRecordCount— 検証が試行された 1 分あたりの行数。

ValidationFailedOverallCount— 検証に失敗した行数。

ValidationSuspendedOverallCount— 検証が中断された行の数。

ValidationPendingOverallCount— 検証がまだ保留中の行数。

ValidationBulkQuerySourceLatency— AWS DMS は、特に多くの変更がある場合に、フルロードまたは継続的なレプリケーション中に特定のシナリオで、データ検証を一括で実行できます。このメトリックスは、ソースエンドポイントから大量のデータを読み取るために必要なレイテンシーを示します。

ValidationBulkQueryTargetLatency— AWS DMS は、特に多くの変更がある場合に、フルロードまたは継続的なレプリケーション中に特定のシナリオで、データ検証を一括で実行できます。このメトリックスは、ターゲットエンドポイントの大量のデータを読み取るために必要なレイテンシーを示します。

ValidationItemQuerySourceLatency— 継続的なレプリケーション中、データ検証は進行中の変更を特定し、それらの変更を検証できます。このメトリックスは、変更をソースから読み取る際のレイテンシーを示します。検証中にエラーが発生した場合、検証では必要な数以上のクエリを実行できます。

ValidationItemQueryTargetLatency— 継続的なレプリケーション中、データ検証は進行中の変更を特定し、変更を行ごとに検証できます。このメトリックスは、変更をターゲットから読み取る際のレイテンシーを示します。検証中にエラーが発生した場合、検証では必要な数以上のクエリが実行される場合があります。

検証がいつ行われるかを正確に制御する — 検証クエリを使用すると、ソースエンドポイントとターゲットエンドポイントの両方に追加の負荷がかかります。そのため、最初に 1 つのタスクでデータを移行またはレプリケートして、次に別のタスクで結果を検証すると、有益な場合があります。

レプリケーションインスタンスの負荷を軽減する — データ検証を分割して独自のインスタンスで実行すると、利点が得られる場合があります。

特定の時点で一致しない行の数を迅速に取得する — 例えば、ターゲットエンドポイントへのメンテナンスウィンドウの本番環境のカットオーバーの直前または最中に、フルロード検証のみのタスクを作成すると、質問への回答を得られます。

CDC コンポーネントを使用した移行タスクで検証の失敗が予想される場合 — 例えば、Oracle の varchar2 を PostgreSQL の jsonb に移行する場合、CDC 検証は、このような失敗した行の再試行を引き続き行い、毎回レポートされる障害の数を制限します。ただし、フルロード検証のみのタスクを作成すると、より迅速に回答を得ることができます。

検証に失敗したテーブルを読み取るデータ修復スクリプトまたはユーティリティを開発する — (トラブルシューティング も参照)。フルロード検証のみのタスクでは、データ修復スクリプトが対応できるように障害を迅速にレポートします。

クエリボリューム

ソーステーブルの DML クエリのタイプ

タスクレイテンシー

レコード総数

検証設定 (PartitionSize など)

PartitionSize および ThreadCount の設定を減らして、フルロード検証中のワークロードを軽減します。これにより、データ検証が遅くなることに注意してください。

Redshift はプライマリキーを強制しませんが、 AWS DMS はプライマリキーに依存して、データ検証のためにターゲット上のレコードを一意に識別します。可能であれば、ソートキーをミラーリングするようにプライマリキーを設定し、フルロード検証クエリの実行を迅速化します。

データ検証では、テーブルにプライマリキーまたは一意のインデックスがなければなりません。

NULL PK/UK 値の検証はサポートされていません。

ターゲット PostgreSQL インスタンスのプライマリキー列の照合が「C」に設定されていない場合、プライマリキーと Oracle ではソート順が異なります。PostgreSQL と Oracle でソート順序が異なる場合、データ検証でレコードの検証に失敗します。

データ検証では、ソースデータベースとターゲットデータベースに対して追加のクエリが生成されます。両方のデータベースに、この追加の負荷を処理するための十分なリソースがあることを確認する必要があります。これは特に Redshift ターゲットに当てはまります。詳細については、「Redshift 検証パフォーマンス」を参照してください。

複数のデータベースを 1 つに統合する場合、データ検証はサポートされません。

ソースまたはターゲットの Oracle エンドポイントの場合、 は DBMS_CRYPTO AWS DMS を使用して LOBs。Oracle エンドポイントで LOB を使用する場合は、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 タイプの検証をサポートしていません。