エラー処理タスクの設定 - 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 で、 AWS DMS タスクを無期限に再起動するように指示します。タスクの再開を試行しない場合には、この値を 0 に設定します。致命的なエラーが発生した場合、6 AWS DMS 回試行するとタスクの再開が中止されます。

  • RecoverableErrorInterval— AWS DMS がタスクの再開を試みるまでに待機する秒数。デフォルトは 5 です。

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

  • RecoverableErrorThrottlingMax— が有効な場合、 AWS DMS がタスクを再開するまでに待機する最大秒数。RecoverableErrorThrottlingデフォルトは 1800 です。

  • RecoverableErrorStopRetryAfterThrottlingMax— に設定するとtrue、1 回あたりの回復試行間隔の最大秒数に達すると、タスクの再開を停止します。 AWS DMS RecoverableErrorThrottlingMax

  • 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 がソースデータベースの場合、すべてのソーステーブルの列に対し、完全なサプリメンタルロギングが有効である必要があります。

  • 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 に設定すると、タスクに対して定義されたテーブル マッピングによりタスクの開始時にテーブルが見つからなかった場合、タスクは失敗します。デフォルトは false です。

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

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

  • FullLoadIgnoreConflicts— このオプションを設定すると、trueキャッシュされたイベントを適用するときに「影響を受ける行がゼロ」エラーと「重複」 AWS DMS エラーが無視されます。に設定するとfalse、 AWS DMS すべてのエラーを無視せずに報告します。デフォルトは true です。

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