エラー処理タスクの設定 - AWS Database Migration Service

エラー処理タスクの設定

次の設定を使用して、レプリケーションタスクのエラー処理の動作を設定できます。タスク設定ファイルを使用してタスク設定を設定する方法については、「タスク設定例」をご参照ください。

  • DataErrorPolicy – レコードレベルでデータ処理に関連するエラーが発生した場合に、AWS DMS が実行するアクションを決定します。データ処理エラーの例には、変換エラー、変換時のエラー、および不良データが含まれます。デフォルトは LOG_ERROR です。

    • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。DataErrorEscalationCount プロパティのエラーカウンターは増分されます。したがって、テーブルにエラー数の制限を設定している場合、このエラーはその制限に向かってカウントされます。

    • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。

    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。

    • STOP_TASK – タスクが停止し、手動での介入が必要になります。

  • DataTruncationErrorPolicy – データが切り捨てられたときに AWS DMS が実行するアクションを決定します。デフォルトは LOG_ERROR です。

    • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。DataErrorEscalationCount プロパティのエラーカウンターは増分されます。したがって、テーブルにエラー数の制限を設定している場合、このエラーはその制限に向かってカウントされます。

    • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。

    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。

    • STOP_TASK – タスクが停止し、手動での介入が必要になります。

  • DataErrorEscalationPolicy – エラーが最大数(DataErrorEscalationCount パラメータで設定)に達したときに AWS DMS が実行するアクションを決定します。デフォルトは SUSPEND_TABLE です。

    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。

    • STOP_TASK – タスクが停止し、手動での介入が必要になります。

  • DataErrorEscalationCount – 特定のレコードで、データに許可されるエラーの最大数を設定します。この数に到達すると、エラーレコードがあるテーブルのデータは、DataErrorEscalationPolicy で設定されているポリシーに従って処理されます。デフォルトは 0 です。

  • EventErrorPolicy – タスク関連イベントの送信中にエラーが発生した場合に AWS DMS が実行するアクションを決定します。指定できる値は次のとおりです。

    • IGNORE – タスクは続行され、そのイベントに関連付けられたデータはすべて無視されます。

    • STOP_TASK – タスクが停止し、手動での介入が必要になります。

  • TableErrorPolicy – 特定のテーブルのデータまたはメタデータの処理中にエラーが発生した場合に、AWS DMS が実行するアクションを決定します。このエラーは一般のテーブルデータにのみ適用され、特定のレコードに関連するエラーではありません。デフォルトは SUSPEND_TABLE です。

    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。

    • STOP_TASK – タスクが停止し、手動での介入が必要になります。

  • TableErrorEscalationPolicy – エラーが最大数(TableErrorEscalationCount パラメータで設定)に達したときに AWS DMS が実行するアクションを決定します。デフォルトで、唯一のユーザー設定は STOP_TASK です。この設定では、タスクが停止し手動での介入が必要になります。

  • TableErrorEscalationCount – 特定のテーブルで、一般データまたはメタデータに許可されるエラーの最大数。この数に到達すると、このテーブルのデータは、TableErrorEscalationPolicy で設定されたポリシーに従って処理されます。デフォルトは 0 です。

  • RecoverableErrorCount – 環境エラーが発生したときに、タスクの再開を試みる最大回数。システムが再起動を試みる回数が指定の回数に達すると、タスクが停止し、手動での介入が必要になります。デフォルト値は -1 です。

    この値を -1 に設定すると、DMS が再試行する回数は、返されるエラータイプに応じて次のように異なります。

    • 実行中の状態、回復可能なエラー: 接続が失われたり、ターゲット適用の失敗などの回復可能なエラーが発生した場合、DMS はタスクを 9 回再試行します。

    • 開始状態、回復可能なエラー: DMS はタスクを 6 回再試行します。

    • 実行中の状態、DMS によって処理される致命的なエラー: DMS はタスクを 6 回再試行します。

    • 実行中の状態、DMS によって処理されない致命的なエラー: DMS はタスクを再試行しません。

    • 上記以外: AWS DMS はタスクを無期限に再試行します。

    タスクの再開を試行しない場合には、この値を 0 に設定します。

    RecoverableErrorCountRecoverableErrorInterval は、DMS タスクが十分な間隔で十分な再試行を行って適切に復旧が行える値に設定することをお勧めします。致命的なエラーが発生した場合、DMS はほとんどのシナリオで再起動の試行を停止します。

  • RecoverableErrorInterval – タスクの再開を試みてから次に再開を試みるまで AWS DMS が待機する時間 (秒)。デフォルトは 5 です。

  • RecoverableErrorThrottling – 有効にすると、タスクの再起動を試みる間隔が RecoverableErrorInterval の値に基づいて徐々に増加します。例えば、RecoverableErrorInterval が 5 秒に設定されている場合、次の再試行は 10 秒後、次は 20 秒後、次は 20 秒後、その次は 40 秒後に行われます。デフォルトは true です。

  • RecoverableErrorThrottlingMaxRecoverableErrorThrottling が有効な場合に、タスクの再開を試みてから次に再開を試みるまで AWS DMS が待機する最大時間数 (秒)。デフォルトは 1800 です。

  • RecoverableErrorStopRetryAfterThrottlingMax — デフォルト値は true に設定されており、DMS は、AWS DMS が復旧試行間で待機する最大秒数が経過した後、RecoverableErrorStopRetryAfterThrottlingMax に従ってタスクの再開を停止します。false に設定した場合、DMS は、AWS DMS が復旧試行間で待機する最大秒数が経過した後、RecoverableErrorStopRetryAfterThrottlingMax に従って RecoverableErrorCount に達するまでタスクを再開し続けます。

  • ApplyErrorDeletePolicy – DELETE オペレーションとの競合がある場合に、AWS DMS が実行するアクションを決定します。デフォルトは IGNORE_RECORD です。利用できる値には以下のとおりです。

    • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。ApplyErrorEscalationCount プロパティのエラーカウンターは増分されます。したがって、テーブルにエラー数の制限を設定している場合、このエラーはその制限に向かってカウントされます。

    • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。

    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。

    • STOP_TASK – タスクが停止し、手動での介入が必要になります。

  • ApplyErrorInsertPolicy – INSERT オペレーションとの競合がある場合に、AWS DMS が実行するアクションを決定します。デフォルトは LOG_ERROR です。利用できる値には以下のとおりです。

    • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。ApplyErrorEscalationCount プロパティのエラーカウンターは増分されます。したがって、テーブルにエラー数の制限を設定している場合、このエラーはその制限に向かってカウントされます。

    • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。

    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。

    • STOP_TASK – タスクが停止し、手動での介入が必要になります。

    • INSERT_RECORD – 挿入されたソースレコードと同じプライマリ キーを含む既存のターゲットレコードがある場合、ターゲットレコードは更新されます。

      注記
      • トランザクション適用モードの場合: このプロセスでは、システムは最初にレコードの挿入を試みます。プライマリキーの競合が原因で挿入が失敗した場合、既存のレコードを削除してから新しいレコードを挿入します。

      • バッチ適用モードの場合: このプロセスでは、新しいレコードの完全なセットを挿入する前に、ターゲットバッチ内のすべての既存のレコードを削除し、データをクリーンに置換します。

  • ApplyErrorUpdatePolicy – UPDATE オペレーションと競合する欠落データがある場合に AWS DMS が実行するアクションを決定します。デフォルトは LOG_ERROR です。利用できる値には以下のとおりです。

    • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。ApplyErrorEscalationCount プロパティのエラーカウンターは増分されます。したがって、テーブルにエラー数の制限を設定している場合、このエラーはその制限に向かってカウントされます。

    • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。

    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。

    • STOP_TASK – タスクが停止し、手動での介入が必要になります。

    • UPDATE_RECORD – ターゲットレコードがない場合、欠落しているターゲットレコードがターゲットテーブルに挿入されます。AWS DMS は、タスクに対する LOB 列のサポートを完全に無効にします。このオプションを選択するには、Oracle がソースデータベースの場合、すべてのソーステーブルの列に対し、完全なサプリメンタルロギングが有効である必要があります。

      注記
      • トランザクション適用モードの場合: このプロセスでは、システムは最初にレコードの更新を試みます。ターゲットにレコードがないために更新が失敗した場合、失敗したレコードを削除してから新しいレコードを挿入します。このプロセスでは、Oracle ソースデータベースの完全なサプリメンタルロギングが必要であり、DMS はこのタスクについて LOB 列のサポートを無効にします。

      • バッチ適用モードの場合: このプロセスでは、新しいレコードの完全なセットを挿入する前に、ターゲットバッチ内のすべての既存のレコードを削除し、データをクリーンに置換します。

  • ApplyErrorEscalationPolicy – エラーが最大数(ApplyErrorEscalationCount パラメータで設定)に達したときに AWS DMS が実行するアクションを決定します。デフォルトは LOG_ERROR です:

    • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。

    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。

    • STOP_TASK – タスクが停止し、手動での介入が必要になります。

  • ApplyErrorEscalationCount – このオプションでは変更プロセスオペレーションが実施されている間、特定のテーブルに許可される APPLY 競合の最大数を設定します。この数に到達すると、このテーブルのデータは、ApplyErrorEscalationPolicy パラメータで設定されたポリシーに従って処理されます。デフォルトは 0 です。

  • ApplyErrorFailOnTruncationDdl – このオプションを true に設定すると、CDC 中に追跡されたいずれかのテーブルで切り捨てが実行された場合に、タスクは失敗します。デフォルトは false です。

    この方法は、DDL テーブルの切り捨てレプリケーションが行われない、PostgreSQL バージョン 11.x 以前またはその他のソース エンドポイントでは機能しません。

  • FailOnNoTablesCaptured – このオプションを true に設定すると、タスクに対して定義されたテーブル マッピングによりタスクの開始時にテーブルが見つからなかった場合、タスクは失敗します。デフォルトは true です。

  • FailOnTransactionConsistencyBreached – このオプションは CDC でソースとして Oracle を使用するタスクに適用されます。デフォルトは False です。これを true に設定すると、トランザクションが指定されたタイムアウトよりも長い時間開かれていて、削除できる場合、タスクは失敗します。

    CDC タスクが Oracle で開始されると、AWS DMS は最も古い、開いているトランザクションが終了するのを制限された時間待ってから、CDC を起動します。タイムアウトに達するまで最も古い、開いているトランザクションが終了しない場合、ほとんどの場合、AWS DMS ではそのトランザクションを無視して CDC が開始されます。このオプションを true に設定すると、タスクは失敗します。

  • FullLoadIgnoreConflicts – このオプションを true に設定すると、AWS DMS では、キャッシュされたイベントを適用するときに、[zero rows affected](影響を受ける行がゼロ)および[duplicates] (重複) エラーは無視されます。false に設定した場合、AWS DMS はエラーを無視せずにすべてのエラーを報告します。デフォルトは true です。

  • DataMaskingErrorPolicy – 互換性のないデータ型やその他の理由でデータマスキングが失敗した場合に AWS DMS が実行するアクションを決定します。以下のオプションが利用できます。

    • STOP_TASK (デフォルト) – タスクが停止し、手動での介入が必要になります。

    • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。

    • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。マスクされていないデータは、ターゲットテーブルにロードされます。

    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。

Redshift がターゲットの場合、テーブルロードエラーは、STL_LOAD_ERRORS として報告されることに注意します。詳細については、「Amazon Redshift データベース開発者ガイド」の「STL_LOAD_ERRORS」を参照してください。