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 エンドポイントの場合、AWS DMS は DBMS_CRYPTO を使用して LOB を検証します。Oracle エンドポイントで LOB を使用する場合は、Oracle エンドポイントにアクセスするために使用されるユーザーアカウントに、dbms_crypto での実行権限を付与する必要があります。これを行うには、以下のステートメントを実行します。

grant execute on sys.dbms_crypto to dms_endpoint_user;

検証中にターゲットデータベースが AWS DMS 外部で変更された場合、不整合は正確に報告されない可能性があります。これは、AWS DMS によってターゲットテーブルで検証が実行されている際に、いずれかのアプリケーションがそのテーブルにデータを書き込む場合に発生する可能性があります。

1 つまたは複数の行が検証中に継続的に変更される場合、AWS DMS はそれらの行を検証することができません。

AWS DMS が 10,000 以上の失敗または停止されたレコードを検出した場合、検証は中止されます。先に進む前に、データの根本的な問題を解決する必要があります。

AWS DMS は、ビューのデータ検証をサポートしていません。

AWS DMS は、文字置換タスク設定が使用されている場合のデータ検証をサポートしません。

AWS DMS は、Oracle LONG タイプの検証をサポートしていません。

AWS DMS は、異種移行中の Oracle Spatial タイプの検証をサポートしていません。