AWS DMS データ検証 - AWS データベース移行サービス

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

AWS DMS データ検証

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

サポートされているエンドポイントの詳細については、「AWS DMS エンドポイントの使用」をご参照ください。

データの検証には、移行自体に必要な時間以外にも、さらに時間がかかります。必要な追加の時間は、移行されたデータの量によって異なります。

これらの設定の詳細については、「 データ検証タスクの設定」をご参照ください。

JSON ファイル内の ValidationSettings タスク設定の例については、タスク設定例 を参照してください。

レプリケーションタスクの統計

データ検証が有効になっている場合、 はテーブルレベルで次の統計 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 タスク設定の例については、タスク設定例 を参照してください。

データ検証情報は、コンソール、、 AWS CLIまたは AWS DMS API を使用して表示できます。

  • コンソールで、タスクを作成または変更するときにタスクの検証を選択できます。コンソールを使用してデータ検証レポートを表示するには、[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 有効な統計からデータ検証情報を収集するには、コンソールを使用してタスクを作成または変更するときに CloudWatch ログを有効にするを選択します。次に、データ検証情報を確認し、データがソースからターゲットに正確に移行されたことを確認するため、以下を行います。

  1. [Database migration tasks] (データベース移行タスク) ページでタスクを選択します。

  2. CloudWatch メトリクスタブを選択します。

  3. CloudWatch が有効な統計情報からデータ検証情報を収集するには、タスクを作成または変更するとき、[Enable CloudWatch logs] (CloudWatch ログを有効にする) コンソールを使用します。

タスク実行中のテーブル再検証

タスクの実行中に、 AWS DMS にデータ検証の実行をリクエストできます。

AWS Management Console

  1. にサインイン AWS Management Console し、https://console.aws.amazon.com/dms/v2/ で AWS DMS コンソールを開きます。

    AWS Identity and Access Management (IAM) ユーザーとしてサインインしている場合は、 にアクセスするための適切なアクセス許可があることを確認してください AWS DMS。必要なアクセス許可については、「」を参照してくださいIAM を使用するために必要なアクセス許可 AWS DMS

  2. ナビゲーションペインから [Tasks] を選択します。

  3. 再検証するテーブルを含む実行中のタスクを選択します。

  4. [テーブル統計] タブを選択します。

  5. 再検証するテーブルを選択します (一度に最大 10 個のテーブルを選択できます)。タスクがすでに実行されていない場合は、テーブルを再検証できません。

  6. [Revalidate (再検証)] を選択します。

JSON エディタを使用して検証ルールを変更する

AWS DMS コンソールの JSON エディタを使用して検証ルールをタスクに追加するには、次の手順を実行します。

  1. [Database migration tasks] (データベース移行タスク) を選択します。

  2. 移行タスクの一覧からタスクを選択します。

  3. タスクが実行中の場合には、[Actions] (アクション) ドロップダウンメニューから[Stop] (停止) を選択します。

  4. タスクが停止したら、タスクを変更するには、[Actions] (アクション) ドロップダウンメニューから[Modify] (変更) を選択します。

  5. [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}" }

検証のみのタスク

検証専用タスクを作成して、移行やデータレプリケーションを実行せずにデータをプレビューしたり検証したりできます。検証のみのタスクを作成するには、EnableValidation 設定と ValidationOnly 設定を true に設定します。ValidationOnly を有効にすると、追加の要件が適用されます。詳細については、「 データ検証タスクの設定」を参照してください。

フルロードのみの移行タイプで多くの障害がレポートされた場合、検証のみのタスクでは CDC の同等のタスクよりもはるかに速く完了します ただし、ソースエンドポイントまたはターゲットエンドポイントへの変更は、フルロードモードの障害としてレポートされることが不利な点となる可能性があります。

CDC 検証のみのタスクは、平均レイテンシーに基づいて検証を遅らせ、障害を報告する前に複数回再試行します。データ比較の大部分が障害付きで完了する場合、CDC モードの検証のみタスクは非常に遅く、不利となる可能性があります。

検証のみのタスクは、特に CDC の場合、レプリケーションタスクと同じ方向に設定する必要があります。これは、CDC 検証のみのタスクが、ソースの変更ログに基づいて変更され、再検証が必要な行を検出するためです。ターゲットがソースとして指定されている場合、ターゲットは DMS がターゲットに送信した変更についてのみ認識するため、レプリケーションエラーが検出される保証はありません。

フルロード検証のみ

AWS DMS バージョン 3.4.6 以降では、フルロード検証のみタスクは、ソーステーブルとターゲットテーブルのすべての行を 1 回のパスですばやく比較し、障害があればすぐに報告してからシャットダウンします。このモードでは障害が発生しても検証が中断されることはなく、速度が最適化されます。ただし、ソースまたはターゲットエンドポイントへの変更は失敗として報告されます。

注記

AWS DMS バージョン 3.4.6 以降では、この検証動作は、検証が有効になっている全ロード移行タスクにも適用されます。

CDC 検証のみ

CDC 検証のみのタスクでは、新たな開始時にソーステーブルとターゲットテーブル間の既存のすべての行を検証します。さらに、CDC 検証のみのタスクは継続的に実行され、継続的なレプリケーションの変更は再検証され、各パスで報告される失敗の数は制限され、不一致の行は失敗する前に再試行されます。誤検出を防ぐように最適化されています。

FailureMaxCount または TableFailureMaxCount のしきい値を超えると、テーブル (またはタスク全体) の検証が中断されます。これは、検証が有効になっている CDC またはフルロード + CDC 移行タスクにも適用されます。また、検証が有効になっている CDC タスクでは、ソースとターゲットの平均レイテンシーにより、変更された各行の再検証が遅延します。

ただし、CDC 検証のみのタスクではデータは移行されず、レイテンシーもありません。デフォルトでは、ValidationQueryCdcDelaySeconds は 180 に設定されます。レイテンシーが高い環境のアカウントではこの量を増やし、誤検出を防ぐこともできます。

検証のみのユースケース

移行またはレプリケーションタスクのデータ検証部分を別の検証のみのタスクに分割するユースケースには、次がありますが、これらに限定されません。

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

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

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

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

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

JSON ファイル内の ValidationSettings タスク設定の例については、「タスク設定例」を参照してください)。

トラブルシューティング

検証中、 はターゲットエンドポイントに新しいテーブル AWS DMS を作成します: awsdms_control.awsdms_validation_failures_v1。レコードが ValidationSuspendedまたは ValidationFailed状態になると、 は診断情報を に AWS DMS 書き込みますawsdms_control.awsdms_validation_failures_v1。このテーブルをクエリすることで、検証エラーをトラブルシューティングすることができます。

ターゲット上でテーブルが作成されるデフォルトスキーマの変更については、「制御テーブルタスク設定」をご参照ください。

以下に、awsdms_control.awsdms_validation_failures_v1 テーブルの説明を示します。

列名 データ型 説明

TASK_NAME

VARCHAR(128) NOT NULL

AWS DMS タスク識別子。

TABLE_OWNER VARCHAR(128) NOT NULL

テーブルのスキーマ (所有者)。

TABLE_NAME

VARCHAR(128) NOT NULL

テーブル名。

FAILURE_TIME DATETIME(3) NOT NULL

イベントが失敗した時刻。

KEY_TYPE VARCHAR(128) NOT NULL

将来の使用のために予約済み (値は常に [Row](行))

KEY TEXT NOT NULL

これは行レコードタイプのプライマリキーです。

FAILURE_TYPE VARCHAR(128) NOT NULL

検証エラーの重大度。RECORD_DIFF または MISSING_SOURCEMISSING_TARGET のいずれかになります。

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 フィールドを参照し、一致しない列を特定します。失敗したレコードのプライマリ キーを入手したら、ソース エンドポイントとターゲット エンドポイントをクエリし、レコードの不一致部分を確認できます。

Redshift 検証パフォーマンス

Amazon Redshift は、いくつかの点 (列指向ストレージ、MPP、データ圧縮、その他の要因など) でリレーショナルデータベースとは異なります。これらの違いにより、Redshift はリレーショナルデータベースとは異なるパフォーマンスプロファイルを持ちます。

フルロードレプリケーションフェーズでは、検証で範囲クエリを使用し、データサイズは PartitionSize 設定によって決まります。これらの範囲ベースのクエリは、ソーステーブルからすべてのレコードを選択します。

継続的なレプリケーションの場合、クエリは範囲ベースのフェッチと個別レコードのフェッチを切り替えます。クエリタイプは、次のような複数の要因に基づいて動的に決定されます。

  • クエリボリューム

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

  • タスクレイテンシー

  • レコード総数

  • 検証設定 (PartitionSize など)

検証クエリにより、Amazon Redshift クラスターに追加の負荷がかかる場合があります。上記の要因はユースケースによって異なるため、検証クエリのパフォーマンスを確認してクラスターとテーブルを相応に調整する必要があります。パフォーマンスの問題を軽減するためのオプションには、次のようなものがあります。

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

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

制限事項

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

    • プライマリキー列の型を CLOBBLOB、または BYTE に設定することはできません。

    • 型が VARCHAR または CHAR であるプライマリキー列の場合、長さは 1024 未満にする必要があります。データ型の長さを指定する必要があります。無制限のデータ型をデータ検証のプライマリキーとして使用することはできません。

    • NOVALIDATE 句を使用して作成された Oracle キーは、プライマリ キーまたは一意のインデックスと見なされません

    • プライマリキーがなく一意キーのみを持つ Oracle テーブルの場合、一意制約のある列にも NOT NULL 制約が必要です。

  • 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 タイプの検証をサポートしていません。

S3 ターゲット検証を使用する際の制限については、「ターゲットの S3 の検証を使用する場合の制限」を参照してください。