AWS DMS データ検証 - AWS Database Migration Service

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

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 エンドポイントの使用」をご参照ください。

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

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

例を挙げてValidationSettingsJSON ファイルのタスク設定。を参照してください。タスク設定例

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

データ検証が有効になっている場合、AWS DMS はテーブルレベルで以下の統計情報を提供します。

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

    • Not enabled — 移行タスクでテーブルに対して検証が有効化されていません。

    • Pending records — テーブル内の一部のレコードが、検証を待機しています。

    • [Mismatched records] (不一致レコード) – テーブル内の一部のレコードが、ソースとターゲット間で一致しません。さまざまな理由により、不一致が発生することがあります。詳細については、ターゲットエンドポイントの 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] (検証失敗) – データの検証フェーズに合格しなかったレコードの数。

例を挙げてValidationSettingsJSON ファイルのタスク設定。を参照してください。タスク設定例

データ検証情報を表示するには、コンソールまたは 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 を使用したレプリケーション タスクの統計

アマゾンの時 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 metrics] (CloudWatch メトリクス) タブ。

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

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

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

AWS Management Console

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

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

  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 モードの検証専用タスクは非常に遅く、潜在的な欠点があります。

Full load 検証のみ

から始まるAWS DMSバージョン 3.4.6 以降では、完全ロード検証タスクでは、ソーステーブルとターゲットテーブルのすべての行を単一のパスで迅速に比較し、障害を直ちに報告してからシャットダウンします。このモードでの障害により検証が中断されることはなく、速度に合わせて最適化されています。ただし、ソースまたはターゲットエンドポイントの変更は、障害として報告されます。

注記

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

CDC 検証のみ

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

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

CDC は。検証専用タスクはデータを移行せず、レイテンシーはありません。設定設定ValidationQueryCdcDelaySecondsデフォルトで 180 にします。また、高レイテンシー環境を考慮して誤検出を防ぐための量を増やすこともできます。

検証のみのユースケース

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

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

  • レプリケーションインスタンスの負荷を軽減— データ検証を分割して独自のインスタンスで実行すると有利です。

  • 特定の時点で一致しない行の数をすばやく取得する:たとえば、メンテナンスウィンドウの生産終了の直前、またはターゲットエンドポイントへのカットオーバー中に、フルロード検証専用タスクを作成して、質問に対する回答を得ることができます。

  • CDC コンポーネントを使用した移行タスクで検証失敗が予想される場合— たとえば、Oracle を移行する場合varchar2PostgreSQL にjsonbでは、CDC 検証はこれらの失敗した行を再試行し続け、毎回報告される障害の数を制限します。ただし、全負荷検証専用タスクを作成して、より迅速な回答を得ることができます。

  • 検証失敗テーブルを読み取るデータ修復スクリプト/ユーティリティを開発しました。— (「」も参照してください。トラブルシューティング). フルロード検証専用タスクでは、データ修復スクリプトの動作の障害をすばやく報告します。

例を挙げてValidationSettingsJSON ファイルのタスク設定。を参照してください。タスク設定例).

トラブルシューティング

検証中に、AWS DMSは、ターゲットエンドポイントに新しいテーブルを作成します。awsdms_validation_failures_v1。 レコードが入力された場合ValidationSuspendedまたは、ValidationFailedState,AWS DMSは診断情報をに書き込みます。awsdms_validation_failures_v1。このテーブルをクエリすることで、検証エラーをトラブルシューティングすることができます。

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

以下に、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 形式の文字列です。

以下のクエリでは、awsdms_validation_failures_v1 テーブルに対してクエリを実行して、タスクのすべての失敗を表示します。タスク名は、タスクの外部リソース ID である必要があります。タスクの外部リソース ID は、タスク ARN の最後の値です。たとえば、ARN 値が arn: aws: dms: us-west-2:5599: task の場合: VFPFKH4FJR3FTYKK2RYSI の場合、タスクの外部リソース ID は VFPFKH4FJR3FTYKKK2RYSI となります。

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

制約事項

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

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

    • 型が VARCHAR または CHAR であるプライマリキー列の場合、長さは 1024 未満にする必要があります。

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

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

  • データ検証では、ソースデータベースとターゲットデータベースに対して追加のクエリが生成されます。両方のデータベースに、この追加の負荷を処理するための十分なリソースがあることを確認する必要があります。

  • 移行でカスタマイズされたフィルタリングを使用する場合や、複数のデータベースを 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 は、ビューのデータ検証をサポートしていません。