0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@zumax

DMSのエラー処理タスクの設定を整理した

0
Posted at

背景・目的

DMS タスクのエラー処理の設定について検討する機会があったので整理します。

まとめ

下記に特徴をまとめます。

特徴 説明
DataErrorPolicy レコードレベルのデータ処理エラー（変換エラー、不良データ等）発生時の挙動を制御。デフォルトは LOG_ERROR
DataErrorPolicyの設定値
→IGNORE_RECORD エラーレコードを無視して続行。エスカレーションカウンターは加算される
→LOG_ERROR エラーをタスクログに記録して続行
→SUSPEND_TABLE 該当テーブルをエラー状態にしてレプリケーション停止、他テーブルは続行
→STOP_TASK タスク全体を停止。手動介入が必要
DataTruncationErrorPolicy データ切り捨て発生時の挙動を制御。デフォルトは LOG_ERROR
DataTruncationErrorPolicyの設定値
→IGNORE_RECORD エラーレコードを無視して続行。エスカレーションカウンター（DataErrorEscalationCount）が加算され、閾値到達時に DataErrorEscalationPolicy が発動
→LOG_ERROR エラーをタスクログに記録して続行
→SUSPEND_TABLE 該当テーブルをエラー状態にしてレプリケーション停止、他テーブルは続行
→STOP_TASK タスク全体を停止。手動介入が必要
DataErrorEscalationPolicy DataErrorEscalationCount で設定したエラー上限に達したときの挙動。デフォルトは SUSPEND_TABLE
DataErrorEscalationPolicyの設定値
→SUSPEND_TABLE 該当テーブルのレプリケーションを停止、他テーブルは続行
→STOP_TASK タスク全体を停止。手動介入が必要
DataErrorEscalationCount テーブルあたりのデータエラー許容数。この数に達するとDataErrorEscalationPolicy が発動。デフォルトは 0（エスカレーションなし）
EventErrorPolicy タスク関連イベント（CloudWatch Events等への通知）送信時のエラー挙動を制御
EventErrorPolicyの設定値
→IGNORE イベント送信エラーを無視して続行
→STOP_TASK タスク全体を停止。手動介入が必要
TableErrorPolicy テーブルレベルのエラー（個別レコードではなく、テーブル全体のデータやメタデータ処理の失敗）時の挙動。デフォルトは SUSPEND_TABLE
TableErrorPolicyの設定値
→SUSPEND_TABLE 該当テーブルのレプリケーションを停止、他テーブルは続行
→STOP_TASK タスク全体を停止。手動介入が必要
TableErrorEscalationPolicy TableErrorEscalationCount で設定したテーブルエラー上限に達したときの挙動
TableErrorEscalationPolicyの設定値
→STOP_TASK タスク全体を停止。手動介入が必要（デフォルト、かつ唯一の選択肢）
TableErrorEscalationCount テーブルあたりのテーブルレベルエラー許容数。この数に達するとTableErrorEscalationPolicy（= STOP_TASK）が発動。デフォルトは 0（エスカレーションなし）
RecoverableErrorCount 環境エラー（接続断、ターゲット適用失敗等）発生時のタスク再起動リトライ回数。デフォルトは -1
RecoverableErrorCountの設定値
-1（デフォルト）の場合		 エラー種別に応じて自動で回数が決まる
・実行中 + 回復可能エラー → 9回
・開始中 + 回復可能エラー → 6回
・実行中 + DMS処理可能な致命的エラー → 6回
・実行中 + DMS処理不可の致命的エラー → リトライなし
・上記以外 → 無期限リトライ
RecoverableErrorCountの設定値
その他の値の場合		 ・0 → リトライなし
・1以上 → 指定回数リトライ後、タスク停止
RecoverableErrorInterval リトライ間の待機秒数。デフォルトは 5秒
RecoverableErrorCount とセットで使う設定

例)RecoverableErrorCount: 9 + RecoverableErrorInterval: 5 なら、5秒間隔で最大9回（計45秒間）再起動を試みる
RecoverableErrorThrottling リトライ間隔を指数的に増加させるかどうか。デフォルトは true（有効）
false にすると固定間隔（毎回5秒）でリトライ
RecoverableErrorThrottlingMax スロットリング有効時のリトライ間隔の上限。デフォルトは 1800秒（30分）
この値で頭打ちになる
RecoverableErrorStopRetryAfterThrottlingMax リトライ間隔が RecoverableErrorThrottlingMax に達した後、リトライを止めるかどうか。デフォルトは true
RecoverableErrorStopRetryAfterThrottlingMaxの設定値
→true（デフォルト） リトライ間隔が上限（デフォルト30分）に達した時点でリトライ終了、タスク停止
→false 間隔が上限に達しても、RecoverableErrorCount の回数に達するまでリトライを継続（上限間隔で繰り返す）
ApplyErrorDeletePolicy DELETEオペレーション競合時のアクション
デフォルトはIGNORE_RECORD
ApplyErrorDeletePolicyの設定値
→IGNORE_RECORD タスク続行、該当レコードのデータを無視。エラーカウンターが増分され、テ
ーブルのエラー数制限にカウントされる
→LOG_ERROR タスク続行、エラーをタスクログに書き込み
→SUSPEND_TABLE タスク続行、エラーレコードのあるテーブルをエラー状態にしてレプリケーション停止
→STOP_TASK タスク停止、手動介入が必要
ApplyErrorInsertPolicy INSERT競合時のアクション、デフォルトは、LOG_ERROR
ApplyErrorInsertPolicyの設定値
→ IGNORE_RECORD 無視して続行、エラーカウンター増分
→ LOG_ERROR ログに記録して続行
→ SUSPEND_TABLE 該当テーブルのレプリケーション停止
→ STOP_TASK タスク停止、手動介入必要
→ INSERT_RECORD 同一PKの既存レコードを更新（UPSERT的動作）
ApplyErrorUpdatePolicy UPDATE競合時・欠落データ時のアクション、デフォルトは、LOG_ERROR
ApplyErrorUpdatePolicyの設定値
→ IGNORE_RECORD 無視して続行、エラーカウンター増分
→ LOG_ERROR ログに記録して続行
→ SUSPEND_TABLE 該当テーブルのレプリケーション停止
→ STOP_TASK タスク停止、手動介入必要
→ UPDATE_RECORD ターゲットにレコードがなければINSERTする。ただしLOB列サポートが無効になり、Oracleソースの場合は全列の完全サプリメンタルロギングが必要
ApplyErrorEscalationPolicy エラーの最大数に達したときに DMS が実行するアクションを決定。デフォルトは、LOG_ERROR
ApplyErrorEscalationPolicyの設定値
→ LOG_ERROR タスクは続行され、エラーはタスクログに書き込まれる
→ SUSPEND_TABLE タスクは続行され、エラーレコードのあるテーブルのデータはエラー状態になる。レプリケーションはされない
→ STOP_TASK タスクが停止し、手動での介入が必要
ApplyErrorEscalationCount 変更プロセス中にテーブルあたりで許容されるAPPLY競合の最大数。この数に達するとApplyErrorEscalationPolicyが発動。デフォルトは0（エスカレーションなし）
ApplyErrorFailOnTruncationDdl CDC中に追跡テーブルでTRUNCATE DDLが実行された場合にタスクを失敗させるかどうか。デフォルトはfalse。PostgreSQL 11.x以前など、DDLテーブル切り捨てレプリケーション非対応のソースでは機能しない
FailOnNoTablesCaptured テーブルマッピングで定義したテーブルがタスク開始時に1つも見つからない場合にタスクを失敗させるかどうか。デフォルトはtrue
FailOnTransactionConsistencyBreached Oracle CDC専用。CDC開始時にオープントランザクションがタイムアウトしても閉じない場合、通常は無視してCDC開始するが、trueにするとタスクを失敗させる。デフォルトはfalse
FullLoadIgnoreConflicts フルロード時のキャッシュイベント適用で「影響を受ける行がゼロ」や「重複」エラーを無視するかどうか。デフォルトはtrue
DataMaskingErrorPolicy データマスキング失敗時のアクション。デフォルトはSTOP_TASK
DataMaskingErrorPolicyの設定値
→STOP_TASK タスク停止、手動介入必要
→IGNORE_RECORD 無視して続行
→LOG_ERROR ログに記録して続行、マスクされていないデータがそのままターゲットにロードされる
→SUSPEND_TABLE 該当テーブルのレプリケーション停止

概要

下記のページを基に整理します。

DataErrorPolicy

  • DataErrorPolicy – レコードレベルでのデータ処理に関連するエラーが発生した場合に AWS DMS が実行するアクションを決定します。データ処理エラーの例には、変換エラー、変換時のエラー、および不良データが含まれます。デフォルトは LOG_ERROR です。
    • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。DataErrorEscalationCount プロパティのエラーカウンターは増分されます。したがって、テーブルにエラー数の制限を設定している場合、このエラーはその制限に向かってカウントされます。
    • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。
    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。
    • STOP_TASK – タスクが停止し、手動での介入が必要になります。
  • DataErrorPolicy
    • レコードレベルのデータ処理エラー（変換エラー、不良データ等）発生時の挙動を制御。デフォルトは LOG_ERROR
    • 設定値は下記の通り
      • IGNORE_RECORD – エラーレコードを無視して続行。エスカレーションカウンターは加算される
      • LOG_ERROR – エラーをタスクログに記録して続行
        • DataErrorEscalationCountの値に達すると、DataErrorEscalationPolicy で指定したアクション（デフォルトではテーブルのレプリケーション停止）が発動する
      • SUSPEND_TABLE – 該当テーブルをエラー状態にしてレプリケーション停止、他テーブルは続行
      • STOP_TASK – タスク全体を停止。手動介入が必要

下記のパターンがあり得る。

  • 無視
  • しばらくは無視するが、一定回数超えると、定義したアクションを発動
  • テーブル単位で停止
  • タスク全体を停止

DataTruncationErrorPolicy

  • DataTruncationErrorPolicy – データが切り捨てられたときに AWS DMS が実行するアクションを決定します。デフォルトは LOG_ERROR です。
    • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。DataErrorEscalationCount プロパティのエラーカウンターは増分されます。したがって、テーブルにエラー数の制限を設定している場合、このエラーはその制限に向かってカウントされます。
    • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。
    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。
    • STOP_TASK – タスクが停止し、手動での介入が必要になります。
  • DataTruncationErrorPolicy
    • データ切り捨て発生時の挙動を制御。デフォルトは LOG_ERROR
    • 設定値は下記の通り
      • IGNORE_RECORD – エラーレコードを無視して続行。エスカレーションカウンター（DataErrorEscalationCount）が加算され、閾値到達時に DataErrorEscalationPolicy が発動
      • LOG_ERROR – エラーをタスクログに記録して続行
      • SUSPEND_TABLE – 該当テーブルをエラー状態にしてレプリケーション停止、他テーブルは続行
      • STOP_TASK – タスク全体を停止。手動介入が必要

「データ切り捨て（truncation）」は、ソースのデータがターゲットの列定義に収まりきらないときに、はみ出た部分が切り落とされる。

DataErrorEscalationPolicy

  • DataErrorEscalationPolicy – エラーが最大数(DataErrorEscalationCount パラメータで設定)に達したときに AWS DMS が実行するアクションを決定します。デフォルトは SUSPEND_TABLE です。
    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。
    • STOP_TASK – タスクが停止し、手動での介入が必要になります。
  • DataErrorEscalationPolicy
    • DataErrorEscalationCount で設定したエラー上限に達したときの挙動。デフォルトは SUSPEND_TABLE
    • 設定値は下記の通り
      • SUSPEND_TABLE – 該当テーブルのレプリケーションを停止、他テーブルは続行
      • STOP_TASK – タスク全体を停止。手動介入が必要

DataErrorEscalationCount

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

  • DataErrorEscalationCount – テーブルあたりのデータエラー許容数。この数に達するとDataErrorEscalationPolicy が発動。デフォルトは 0（エスカレーションなし）

EventErrorPolicy

  • EventErrorPolicy – タスク関連のイベントの送信中にエラーが発生した場合に AWS DMS が実行するアクションを決定します。指定できる値は次のとおりです。
    • IGNORE – タスクは続行され、そのイベントに関連付けられたデータはすべて無視されます。
    • STOP_TASK – タスクが停止し、手動での介入が必要になります。
  • EventErrorPolicy
    • タスク関連イベント（CloudWatch Events等への通知）送信時のエラー挙動を制御
      • IGNORE – イベント送信エラーを無視して続行
      • STOP_TASK – タスク全体を停止。手動介入が必要

TableErrorPolicy

  • TableErrorPolicy – 特定のテーブルのデータまたはメタデータの処理中にエラーが発生した場合に、 AWS DMS が実行するアクションを決定します。このエラーは一般のテーブルデータにのみ適用され、特定のレコードに関連するエラーではありません。デフォルトは SUSPEND_TABLE です。
    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。
    • STOP_TASK – タスクが停止し、手動での介入が必要になります。
  • TableErrorPolicy
    • テーブルレベルのエラー（個別レコードではなく、テーブル全体のデータやメタデータ処理の失敗）時の挙動。デフォルトは SUSPEND_TABLE
    • 設定値は下記の通り
      • SUSPEND_TABLE – 該当テーブルのレプリケーションを停止、他テーブルは続行
      • STOP_TASK – タスク全体を停止。手動介入が必要

DataErrorPolicy との違い

  • DataErrorPolicy → 特定レコードの変換・処理エラー（行単位）
  • TableErrorPolicy → テーブル構造の変更検知失敗、DDL適用エラー、テーブルへのアクセス不能など（テーブル単位）

TableErrorEscalationPolicy

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

  • TableErrorEscalationPolicy
    • TableErrorEscalationCount で設定したテーブルエラー上限に達したときの挙動
    • 設定値は下記の通り
      • STOP_TASK – タスク全体を停止。手動介入が必要（デフォルト、かつ唯一の選択肢）

DataErrorEscalationPolicy と違い

  • SUSPEND_TABLE の選択肢がない
  • テーブルレベルのエラーが複数テーブルで頻発している状況はタスク全体に問題がある可能性が高い。タスク停止一択という設計

TableErrorEscalationCount

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

  • TableErrorEscalationCount
    • テーブルあたりのテーブルレベルエラー許容数。この数に達すると TableErrorEscalationPolicy（= STOP_TASK）が発動。デフォルトは 0（エスカレーションなし）

DataErrorEscalationCount と同じ構造

  • 対象がレコードレベルエラーかテーブルレベルエラーかの違いだけ

RecoverableErrorCount

  • RecoverableErrorCount – 環境エラーが発生したときに、タスクの再開を試みる最大回数。システムが再起動を試みる回数が指定の回数に達すると、タスクが停止し、手動での介入が必要になります。デフォルト値は -1 です。
    この値を -1 に設定すると、DMS が再試行する回数は、返されるエラータイプに応じて次のように異なります。
    • 実行中の状態、回復可能なエラー: 接続が失われたり、ターゲット適用の失敗などの回復可能なエラーが発生した場合、DMS はタスクを 9 回再試行します。
    • 開始状態、回復可能なエラー: DMS はタスクを 6 回再試行します。
    • 実行中の状態、DMS によって処理される致命的なエラー: DMS はタスクを 6 回再試行します。
    • 実行中の状態、DMS によって処理されない致命的なエラー: DMS はタスクを再試行しません。
    • 上記以外: はタスクを無期限に AWS DMS 再試行します。
  • タスクの再開を試行しない場合には、この値を 0 に設定します。
  • RecoverableErrorCount と RecoverableErrorInterval は、DMS タスクが十分な間隔で十分な再試行を行って適切に復旧が行える値に設定することをお勧めします。致命的なエラーが発生した場合、DMS はほとんどのシナリオで再起動の試行を停止します。
  • RecoverableErrorCount
    • 環境エラー（接続断、ターゲット適用失敗等）発生時のタスク再起動リトライ回数。デフォルトは -1
    • -1（デフォルト）の場合、エラー種別に応じて自動で回数が決まる
      • 実行中 + 回復可能エラー → 9回
      • 開始中 + 回復可能エラー → 6回
      • 実行中 + DMS処理可能な致命的エラー → 6回
      • 実行中 + DMS処理不可の致命的エラー → リトライなし
      • 上記以外 → 無期限リトライ
    • その他の値：
      • 0 → リトライなし
      • 1以上 → 指定回数リトライ後、タスク停止
  • 前述のポリシー群（Data/Table/Event）とは別軸の設定
  • データやテーブルの問題ではなく、ネットワーク断やDB接続エラーなどインフラレベルの障害に対するリトライ制御
  • RecoverableErrorInterval（リトライ間隔）とセットで調整が推奨されている

RecoverableErrorInterval

RecoverableErrorInterval – タスクの再起動を試行するまで AWS に DMS が待機する秒数。デフォルトは 5 です。

  • RecoverableErrorInterval
    • リトライ間の待機秒数。デフォルトは 5秒
  • RecoverableErrorCount とセットで使う設定
  • 例えば RecoverableErrorCount: 9 + RecoverableErrorInterval: 5 なら、5秒間隔で最大9回（計45秒間）再起動を試みる

RecoverableErrorThrottling

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

例（RecoverableErrorInterval: 5 の場合）：

  • 1回目 → 5秒後、2回目 → 10秒後、3回目 → 20秒後、4回目 → 40秒後

  • false にすると固定間隔（毎回5秒）でリトライ

  • デフォルトで有効。いわゆるエクスポネンシャルバックオフが標準動作

  • DB側の一時的な過負荷などで接続が切れた場合に、短い間隔で連続リトライして負荷を悪化させるのを防ぐ設計と思われる

RecoverableErrorThrottlingMax

RecoverableErrorThrottlingMax – RecoverableErrorThrottlingが有効になっている場合にタスクの再起動を試行するまで AWS に DMS が待機する最大秒数。デフォルトは 1800 です。

  • RecoverableErrorThrottlingMax
    • スロットリング有効時のリトライ間隔の上限。デフォルトは 1800秒（30分）

指数的に増加するリトライ間隔（5→10→20→40→80→…）がこの値で頭打ちになる
デフォルトだと、間隔が30分に達した後はずっと30分間隔でリトライし続ける

RecoverableErrorStopRetryAfterThrottlingMax

RecoverableErrorStopRetryAfterThrottlingMax– デフォルト値は に設定されtrue、DMS は、 ごとに復旧試行間の AWS DMS 待機の最大秒数に達した後、タスクの再開を停止しますRecoverableErrorStopRetryAfterThrottlingMax。に設定するとfalse、DMS は、復旧試行の間に AWS DMS 待機する最大秒数に達した後、 が RecoverableErrorCount に達するRecoverableErrorStopRetryAfterThrottlingMaxまでタスクを再開し続けます。

  • RecoverableErrorStopRetryAfterThrottlingMax
    • リトライ間隔が RecoverableErrorThrottlingMax に達した後、リトライを止めるかどうか。デフォルトは true
    • true（デフォルト）→ リトライ間隔が上限（デフォルト30分）に達した時点でリトライ終了、タスク停止
    • false → 間隔が上限に達しても、RecoverableErrorCount の回数に達するまでリトライを継続（上限間隔で繰り返す）

デフォルト設定だと、RecoverableErrorCount で指定した回数に届く前でも、スロットリングの上限間隔に達した時点でリトライを打ち切る。
長時間復旧しない障害に対して早めに諦める挙動

ApplyErrorDeletePolicy

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

  • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。ApplyErrorEscalationCount プロパティのエラーカウンターは増分されます。したがって、テーブルにエラー数の制限を設定している場合、このエラーはその制限に向かってカウントされます。
    • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。
    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。
    • STOP_TASK – タスクが停止し、手動での介入が必要になります。
  • ApplyErrorDeletePolicy
    • DELETEオペレーション競合時のアクション
    • デフォルトはIGNORE_RECORD
      • IGNORE_RECORD
        • タスク続行、該当レコードのデータを無視。エラーカウンターが増分され、テ
          ーブルのエラー数制限にカウントされる
      • LOG_ERROR
        • タスク続行、エラーをタスクログに書き込み
      • SUSPEND_TABLE
        – タスク続行、エラーレコードのあるテーブルをエラー状態にしてレプリケーシ
        ョン停止
      • STOP_TASK – タスク停止、手動介入が必要

ApplyErrorInsertPolicy

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

  • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。ApplyErrorEscalationCount プロパティのエラーカウンターは増分されます。したがって、テーブルにエラー数の制限を設定している場合、このエラーはその制限に向かってカウントされます。
  • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。
  • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。
  • STOP_TASK – タスクが停止し、手動での介入が必要になります。
  • INSERT_RECORD – 挿入されたソースレコードと同じプライマリ キーを含む既存のターゲットレコードがある場合、ターゲットレコードは更新されます。

注記

  • トランザクション適用モードの場合: このプロセスでは、システムは最初にレコードを挿入しようとします。プライマリキーの競合が原因で挿入が失敗した場合、既存のレコードを削除し、新しいレコードを挿入します。
  • バッチ適用モードの場合: プロセスは、新しいレコードの完全なセットを挿入する前に、ターゲットバッチ内のすべての既存のレコードを削除し、データの置換をクリーンに行います。
  • ApplyErrorInsertPolicy
    • INSERT競合時のアクション、デフォルトは、LOG_ERROR
    • IGNORE_RECORD
      • 無視して続行、エラーカウンター増分
    • LOG_ERROR
      • ログに記録して続行
    • SUSPEND_TABLE
      • 該当テーブルのレプリケーション停止
    • STOP_TASK
      • タスク停止、手動介入必要
    • INSERT_RECORD
      • 同一PKの既存レコードを更新（UPSERT的動作）

INSERT_RECORDの挙動はモードで異なる

  • トランザクション適用モード
    • INSERT失敗 → 既存レコード削除 → 再INSERT
  • バッチ適用モード
    • バッチ内の既存レコードを全削除 → 新レコードを一括INSERT

ApplyErrorUpdatePolicy

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

  • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。ApplyErrorEscalationCount プロパティのエラーカウンターは増分されます。したがって、テーブルにエラー数の制限を設定している場合、このエラーはその制限に向かってカウントされます。
  • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。
  • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。
  • STOP_TASK – タスクが停止し、手動での介入が必要になります。
  • UPDATE_RECORD – ターゲットレコードがない場合、欠落しているターゲットレコードがターゲットテーブルに挿入されます。 は、タスクの LOB 列のサポート AWS DMS を完全に無効にします。このオプションを選択するには、Oracle がソースデータベースの場合、すべてのソーステーブルの列に対し、完全なサプリメンタルロギングが有効である必要があります。

注記

  • トランザクション適用モードの場合: このプロセスでは、システムは最初にレコードの更新を試みます。ターゲットにレコードがないために更新が失敗した場合、失敗したレコードに対して削除を実行し、新しいレコードを挿入します。このプロセスでは、Oracle ソースデータベースの完全なサプリメンタルロギングが必要であり、DMS はこのタスクの LOB 列のサポートを無効にします。
  • バッチ適用モードの場合: プロセスは、新しいレコードの完全なセットを挿入する前に、ターゲットバッチ内のすべての既存のレコードを削除し、データの置き換えをクリーンに行います。
  • ApplyErrorUpdatePolicy
    • UPDATE競合時・欠落データ時のアクション、デフォルト: LOG_ERROR
    • IGNORE_RECORD
      • 無視して続行、エラーカウンター増分
    • LOG_ERROR
      • ログに記録して続行
    • SUSPEND_TABLE
      • 該当テーブルのレプリケーション停止
    • STOP_TASK
      • タスク停止、手動介入必要
    • UPDATE_RECORD
      • ターゲットにレコードがなければINSERTする。ただしLOB列サポートが無効になり、Oracleソースの場合は全列の完全サプリメンタルロギングが必要
  • UPDATE_RECORDの挙動はモードで異なる
    • トランザクション適用モード – UPDATE失敗 → DELETE → INSERT。Oracleの完全サプリメンタルロギ
      ング必須、LOB列サポート無効
    • バッチ適用モード – バッチ内の既存レコードを全削除 → 新レコードを一括INSERT

ApplyErrorEscalationPolicy

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

  • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。
  • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。
  • STOP_TASK – タスクが停止し、手動での介入が必要になります。
  • ApplyErrorEscalationPolicy
    • エラーの最大数に達したときに DMS が実行するアクションを決定
    • デフォルトは、LOG_ERROR
    • LOG_ERROR
      • タスクは続行され、エラーはタスクログに書き込まれる
    • SUSPEND_TABLE
      • タスクは続行され、エラーレコードのあるテーブルのデータはエラー状態になる。レプリケーションはされない
    • STOP_TASK
      • タスクが停止し、手動での介入が必要

ApplyErrorEscalationCount

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

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

ApplyErrorFailOnTruncationDdl

ApplyErrorFailOnTruncationDdl – このオプションを true に設定すると、CDC 中に追跡されたいずれかのテーブルで切り捨てが実行された場合に、タスクは失敗します。デフォルトは false です。
この方法は、DDL テーブルの切り捨てレプリケーションが行われない、PostgreSQL バージョン 11.x 以前またはその他のソース エンドポイントでは機能しません。

  • ApplyErrorFailOnTruncationDdl
    • CDC 中に追跡されたいずれかのテーブルで切り捨てが実行された場合に、タスクは失敗
    • DDL テーブルの切り捨てレプリケーションが行われない、PostgreSQL バージョン 11.x 以前またはその他のソース エンドポイントでは機能しない

FailOnNoTablesCaptured

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

  • FailOnNoTablesCaptured
    • タスクに対して定義されたテーブル マッピングによりタスクの開始時にテーブルが見つからなかった場合、タスクは失敗する

FailOnTransactionConsistencyBreached

FailOnTransactionConsistencyBreached – このオプションは CDC でソースとして Oracle を使用するタスクに適用されます。デフォルトは False です。これを true に設定すると、トランザクションが指定されたタイムアウトよりも長い時間開かれていて、削除できる場合、タスクは失敗します。
CDC タスクが Oracle で始まると、CDC を開始する前に、最も古いオープントランザクションが終了するまで期間限定で AWS DMS 待機します。最も古いオープントランザクションがタイムアウトに達するまで閉じない場合、ほとんどの場合、そのトランザクションを無視して CDC AWS DMS を開始します。このオプションを true に設定すると、タスクは失敗します。

  • FailOnTransactionConsistencyBreached
    • CDC開始時、DMSは最も古いオープントランザクションの終了を一定時間待機する
    • タイムアウトしても閉じない場合、通常はそのトランザクションを無視してCDC開始
    • trueに設定すると、無視せずタスクを失敗させる

FullLoadIgnoreConflicts

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

  • FullLoadIgnoreConflicts
    • true
      • フルロード時のキャッシュイベント適用で「影響を受ける行がゼロ」や「重複」エラーを無
        視して続行
    • false
      • すべてのエラーを報告する

DataMaskingErrorPolicy

  • DataMaskingErrorPolicy – 互換性のないデータ型やその他の理由でデータマスキングが失敗した場合に AWS DMS 実行するアクションを決定します。以下のオプションを使用できます。
    • STOP_TASK (デフォルト) – タスクが停止し、手動による介入が必要です。
    • IGNORE_RECORD – タスクは続行され、該当するレコードのデータは無視されます。
    • LOG_ERROR – タスクは続行され、エラーはタスクログに書き込まれます。マスクされていないデータはターゲットテーブルにロードされます。
    • SUSPEND_TABLE – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。
  • DataMaskingErrorPolicy
    • データマスキング失敗時のアクション、デフォルトはSTOP_TASK
    • STOP_TASK
      • タスク停止、手動介入必要
    • IGNORE_RECORD
      • 無視して続行
    • LOG_ERROR
      • ログに記録して続行、マスクされていないデータがそのままターゲットにロードされる
    • SUSPEND_TABLE
      • 該当テーブルのレプリケーション停止

考察

下記のように理解しました。

エラーハンドリングの階層構造

  • レコード → テーブル → タスクの3階層で、「無視→ログ→テーブル停止→タスク停止」と段階的にエスカレーションできる設計

デフォルト値の設計について

  • データ系エラー
    • LOG_ERROR（続行優先）
    • レコード単位の変換エラーや型不一致は、移行全体を止めるほどではない。ログに残して後から確認・修正できればよいという判断ではないか
  • DELETE競合
    • IGNORE_RECORD
    • 存在しないレコードの削除は実害が少ない
    • 「ターゲットに存在しないレコードをDELETEしようとした」というケース。元々ないものを消せなくてもも結果は同じ
  • テーブル系エラー
    • SUSPEND_TABLE
    • 影響をテーブル単位に封じ込め
    • テーブル構造の変更検知失敗やDDL適用エラーなど
    • レコード単位ではなくテーブル全体に影響する問題
    • タスク全体を止めるのは過剰だが、そのテーブルのレプリケーションは信頼できないので停止する
    • データマスキング
      • STOP_TASK
      • 未マスクデータの漏洩防止のため最も厳格
      • マスキング失敗時にLOG_ERRORやIGNORE_RECORDにすると、マスクされていない生データ（個人情報
        等）がターゲットにロードされるリスク
      • セキュリティ事故を防ぐため、即座にタスクを止める

参考

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?