翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。 # AWS Database Migration Service タスクのタスク設定の指定 各タスクには、データベース移行の必要に応じて設定できる設定があります。これらの設定は JSON ファイルで作成するか、一部の設定で AWS DMS コンソールを使用して指定できます。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 以下に示すように、タスク設定には、いくつかの主要なタイプがあります。 **Topics** + [ ## タスク設定例 ](#CHAP_Tasks.CustomizingTasks.TaskSettings.Example) + [ # ターゲットメタデータのタスク設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md) + [ # 全ロードタスク設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.FullLoad.md) + [ # Time Travel タスクの設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.md) + [ # ロギングタスク設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md) + [ # 制御テーブルタスク設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.md) + [ # ストリームバッファタスク設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.StreamBuffer.md) + [ # 変更処理のチューニング設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md) + [ # データ検証タスクの設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md) + [ # データ再同期設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.DataResyncSettings.md) + [ # 変更処理の DDL 処理のタスク設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.DDLHandling.md) + [ # 文字置換タスクの設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.CharacterSubstitution.md) + [ # 前イメージタスク設定前 ](CHAP_Tasks.CustomizingTasks.TaskSettings.BeforeImage.md) + [ # エラー処理タスクの設定 ](CHAP_Tasks.CustomizingTasks.TaskSettings.ErrorHandling.md) + [ # タスク設定の保存 ](CHAP_Tasks.CustomizingTasks.TaskSettings.Saving.md) | タスク設定 | 関連資料 | | --- | --- | | **タスク評価レポートの作成** 移行中に問題を発生させる可能性のある、サポートされていないデータ型を示すタスク評価レポートを作成できます。タスクを実行する前にタスクでこのレポートを実行して、潜在的な問題を見つけることができます。 | [タスクの移行前評価の有効化と操作](CHAP_Tasks.AssessmentReport.md) | | **[Creating a task]** (タスクの作成) タスクを作成するときに、ソース、ターゲット、およびレプリケーションインスタンスを、移行設定とともに作成します。 | [[Creating a task] (タスクの作成)](CHAP_Tasks.Creating.md) | | **[Creating an ongoing replication task]** (継続的レプリケーション タスク作成) ソースとターゲット間で、継続的なレプリケーションを提供するようにタスクをセットアップできます。 | [を使用した継続的なレプリケーション用のタスクの作成 AWS DMS](CHAP_Task.CDC.md) | | **[Applying task settings]** (タスク設定の適用) 各タスクには、データベース移行の必要に応じて設定できる設定があります。これらの設定は JSON ファイルで作成するか、一部の設定で AWS DMS コンソールを使用して指定できます。 | [AWS Database Migration Service タスクのタスク設定の指定](#CHAP_Tasks.CustomizingTasks.TaskSettings) | | **[Data validation]** (データ検証) データ検証を使用して、 がターゲットデータストアのデータとソースデータストアのデータ AWS DMS を比較します。 | [AWS DMS データ検証](CHAP_Validating.md) | | **[Modifying a task]** (タスクの変更) タスクが停止した際に、そのタスクの設定を変更できます。 | [[Modifying a task] (タスクの変更)](CHAP_Tasks.Modifying.md) | | **タスク実行中のテーブルの再ロード** タスク実行中にエラーが発生した場合には、タスク実行中にテーブルを再ロードできます。 | [タスク実行中のテーブルの再ロード](CHAP_Tasks.ReloadTables.md) | | **[Using table mapping]** (テーブルマッピングの使用) テーブルマッピングは、データソース、ソーススキーマ、データ、およびタスク実行中に必要なすべての変換のタスク設定を指定するための複数のルールタイプを使用します。 | 選択ルール [選択ルールと選択アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md) 変換ルール [変換ルールおよび変換アクション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md) | | **フィルターの適用** ソースフィルタを使用すると、ソースからターゲットに転送されるレコードの数とタイプを制限できます。例えば、本社を拠点とする従業員だけがターゲットデータベースに移行されるように指定できます。データの列にフィルタを適用します。 | [ソースフィルタの使用](CHAP_Tasks.CustomizingTasks.Filters.md) | | [Monitoring a task] (タスクのモニタリング) タスクのパフォーマンスとそのタスクが使用するテーブルに関する情報を取得するためには、複数の方法があります。 | [DMS AWS タスクのモニタリング](CHAP_Monitoring.md) | | タスクログの管理 AWS DMS API または を使用して、タスクログを表示および削除できます AWS CLI。 | [DMS AWS タスクログの表示と管理](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs) | ## タスク設定例 AWS マネジメントコンソール または を使用して AWS CLI レプリケーションタスクを作成できます。を使用する場合は AWS CLI、JSON ファイルを作成してタスク設定を行い、[CreateReplicationTask](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateReplicationTask.html) オペレーションの [ ReplicationTaskSettings](https://docs.aws.amazon.com/dms/latest/APIReference/API_CreateReplicationTask.html#DMS-CreateReplicationTask-request-ReplicationTaskSettings) パラメータとして JSON ファイルの file:// URI を指定します。 次の例は、 を使用して `CreateReplicationTask`オペレーションを AWS CLI 呼び出す方法を示しています。 ``` aws dms create-replication-task \ --replication-task-identifier MyTask \ --source-endpoint-arn arn:aws:dms:us-west-2:123456789012:endpoint:ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABC \ --target-endpoint-arn arn:aws:dms:us-west-2:123456789012:endpoint:ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABC \ --replication-instance-arn arn:aws:dms:us-west-2:123456789012:rep:ABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890ABC \ --migration-type cdc \ --table-mappings file://tablemappings.json \ --replication-task-settings file://settings.json ``` 前の例では、`tablemappings.json`というテーブルマッピングファイルを使用しています。テーブルマッピング例については、「[テーブルマッピングを使用して、タスクの設定を指定する](CHAP_Tasks.CustomizingTasks.TableMapping.md)」をご参照ください。 タスク設定の JSON ファイルは次のようになります。 ``` { "TargetMetadata": { "TargetSchema": "", "SupportLobs": true, "FullLobMode": false, "LobChunkSize": 64, "LimitedSizeLobMode": true, "LobMaxSize": 32, "InlineLobMaxSize": 0, "LoadMaxFileSize": 0, "ParallelLoadThreads": 0, "ParallelLoadBufferSize":0, "ParallelLoadQueuesPerThread": 1, "ParallelApplyThreads": 0, "ParallelApplyBufferSize": 100, "ParallelApplyQueuesPerThread": 1, "BatchApplyEnabled": false, "TaskRecoveryTableEnabled": false }, "FullLoadSettings": { "TargetTablePrepMode": "DO_NOTHING", "CreatePkAfterFullLoad": false, "StopTaskCachedChangesApplied": false, "StopTaskCachedChangesNotApplied": false, "MaxFullLoadSubTasks": 8, "TransactionConsistencyTimeout": 600, "CommitRate": 10000 }, "TTSettings" : { "EnableTT" : true, "TTS3Settings": { "EncryptionMode": "SSE_KMS", "ServerSideEncryptionKmsKeyId": "arn:aws:kms:us-west-2:112233445566:key/myKMSKey", "ServiceAccessRoleArn": "arn:aws:iam::112233445566:role/dms-tt-s3-access-role", "BucketName": "myttbucket", "BucketFolder": "myttfolder", "EnableDeletingFromS3OnTaskDelete": false }, "TTRecordSettings": { "EnableRawData" : true, "OperationsToLog": "DELETE,UPDATE", "MaxRecordSize": 64 } }, "Logging": { "EnableLogging": false }, "ControlTablesSettings": { "ControlSchema":"", "HistoryTimeslotInMinutes":5, "HistoryTableEnabled": false, "SuspendedTablesTableEnabled": false, "StatusTableEnabled": false }, "StreamBufferSettings": { "StreamBufferCount": 3, "StreamBufferSizeInMB": 8 }, "ChangeProcessingTuning": { "BatchApplyPreserveTransaction": true, "BatchApplyTimeoutMin": 1, "BatchApplyTimeoutMax": 30, "BatchApplyMemoryLimit": 500, "BatchSplitSize": 0, "MinTransactionSize": 1000, "CommitTimeout": 1, "MemoryLimitTotal": 1024, "MemoryKeepTime": 60, "StatementCacheSize": 50 }, "ChangeProcessingDdlHandlingPolicy": { "HandleSourceTableDropped": true, "HandleSourceTableTruncated": true, "HandleSourceTableAltered": true }, "LoopbackPreventionSettings": { "EnableLoopbackPrevention": true, "SourceSchema": "LOOP-DATA", "TargetSchema": "loop-data" }, "CharacterSetSettings": { "CharacterReplacements": [ { "SourceCharacterCodePoint": 35, "TargetCharacterCodePoint": 52 }, { "SourceCharacterCodePoint": 37, "TargetCharacterCodePoint": 103 } ], "CharacterSetSupport": { "CharacterSet": "UTF16_PlatformEndian", "ReplaceWithCharacterCodePoint": 0 } }, "BeforeImageSettings": { "EnableBeforeImage": false, "FieldName": "", "ColumnFilter": "pk-only" }, "ErrorBehavior": { "DataErrorPolicy": "LOG_ERROR", "DataTruncationErrorPolicy":"LOG_ERROR", "DataMaskingErrorPolicy": "STOP_TASK", "DataErrorEscalationPolicy":"SUSPEND_TABLE", "DataErrorEscalationCount": 50, "TableErrorPolicy":"SUSPEND_TABLE", "TableErrorEscalationPolicy":"STOP_TASK", "TableErrorEscalationCount": 50, "RecoverableErrorCount": 0, "RecoverableErrorInterval": 5, "RecoverableErrorThrottling": true, "RecoverableErrorThrottlingMax": 1800, "ApplyErrorDeletePolicy":"IGNORE_RECORD", "ApplyErrorInsertPolicy":"LOG_ERROR", "ApplyErrorUpdatePolicy":"LOG_ERROR", "ApplyErrorEscalationPolicy":"LOG_ERROR", "ApplyErrorEscalationCount": 0, "FullLoadIgnoreConflicts": true }, "ValidationSettings": { "EnableValidation": false, "ValidationMode": "ROW_LEVEL", "ThreadCount": 5, "PartitionSize": 10000, "FailureMaxCount": 1000, "RecordFailureDelayInMinutes": 5, "RecordSuspendDelayInMinutes": 30, "MaxKeyColumnSize": 8096, "TableFailureMaxCount": 10000, "ValidationOnly": false, "HandleCollationDiff": false, "RecordFailureDelayLimitInMinutes": 1, "SkipLobColumns": false, "ValidationPartialLobSize": 0, "ValidationQueryCdcDelaySeconds": 0 } } ``` # ターゲットメタデータのタスク設定 ターゲットメタデータ設定には、以下のものが含まれます。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 + `TargetSchema` - ターゲットテーブルスキーマ名。このメタデータオプションが空の場合、ソーステーブルのスキーマが使用されます。 AWS DMS は、ソーススキーマが定義されていない場合、ターゲットデータベースの所有者プレフィックスをすべてのテーブルに自動的に追加します。このオプションは、MySQL 型のターゲットエンドポイントでは空のままにする必要があります。データマッピングでスキーマの名前を変更すると、この設定よりも優先されます。 + LOB 設定 - ラージ オブジェクト (LOB) の管理方法を決定する設定。`SupportLobs=true` と設定した場合、次のいずれかを `true` に設定する必要があります。 + `FullLobMode` – このオプションを `true` に設定した場合、 `LobChunkSize` オプションの値を入力します。ターゲットにデータをレプリケートするときに使用する LOB チャンクサイズをキロバイト単位で入力します。`FullLobMode` オプションは、LOB のサイズが大きい場合に最適ですが、ロードが遅くなる傾向になります。`LobChunkSize` の推奨値は 64 キロバイトです。`LobChunkSize` の値を 64 キロバイト以上に設定すると、タスクが失敗する可能性があります。 + `InlineLobMaxSize` – この値は、全ロード中にインラインで転送する LOBs AWS DMS を決定します。小さな LOB は、ソーステーブルから探すよりも転送する方が効率的です。全ロード中、 はすべての LOBs AWS DMS をチェックし、 より小さい LOBs のインライン転送を実行します`InlineLobMaxSize`。 は、 `InlineLobMaxSize`の より大きいすべての LOBs AWS DMS を転送します`FullLobMode`。`InlineLobMaxSize` のデフォルト値は 0 で、範囲は 1～102,400 キロバイト (100 MB) です。ほとんどの LOB が `InlineLobMaxSize` で設定した値よりも小さいことがわかっている場合のみ、`InlineLobMaxSize` に値を指定します。 + `LimitedSizeLobMode` – このオプションを `true` に設定した場合、 `LobMaxSize` オプションの値を入力します。個々の LOB の最大サイズをキロバイト単位で入力します。の最大値`LobMaxSize`は 102400 KB (100 MB) です。 これらのタスクの LOB 設定を使用する条件の詳細については、「[AWS DMS タスクでのソースデータベースの LOB サポートの設定](CHAP_Tasks.LOBSupport.md)」をご参照ください。また、個々のテーブルの LOB の管理を制御できます。詳細については、「[テーブルとコレクション設定のルールとオペレーション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md)」を参照してください。 + `BatchApplyEnabled` - 各トランザクションを個別に適用するか、変更をバッチでコミットするかを決定します。デフォルト値は `false` です。 `BatchApplyEnabled` を `true` に設定した場合、DMS は **ソース**テーブルにプライマリキー (PK) または一意のキー (UK) を必要とします。ソーステーブルに PK または UK がない場合、バッチ挿入のみが適用され、バッチ更新と削除は適用されません。 `BatchApplyEnabled` が `true` に設定されていて、**ターゲット**テーブルに一意の制約とプライマリキーがある場合、 AWS DMS はエラーメッセージを生成します。`BatchApplyEnabled` が `true` に設定されている場合、一意の制約とプライマリキーの両方を持つターゲットテーブルはサポートされません。 `BatchApplyEnabled` が true に設定され、デフォルトのエラー処理ポリシーを持つテーブルからデータエラー AWS DMS が発生した場合、 AWS DMS タスクは残りのテーブルに対してバッチモードから one-by-oneモードに切り替わります。この動作を変更するには、`"SUSPEND_TABLE"` の次のポリシーに対するアクションを タスク設定 JSON ファイルの `"ErrorBehavior"` グループ プロパティに設定できます: + `DataErrorPolicy` + `ApplyErrorDeletePolicy` + `ApplyErrorInsertPolicy` + `ApplyErrorUpdatePolicy` `"ErrorBehavior"` のグループ プロパティの詳細については、[AWS Database Migration Service タスクのタスク設定の指定](CHAP_Tasks.CustomizingTasks.TaskSettings.md) のタスク設定 JSON ファイル例をご参照ください。これらのポリシーを に設定すると`"SUSPEND_TABLE"`、 AWS DMS タスクはそれらを発生させるテーブルのデータエラーを停止し、すべてのテーブルに対してバッチモードで続行します。 `BatchApplyEnabled` パラメータを `BatchApplyPreserveTransaction` パラメータと併用することはできません。`BatchApplyEnabled` を `true` に設定すると、`BatchApplyPreserveTransaction` パラメータがトランザクションの整合性を確認します。 `BatchApplyPreserveTransaction` を `true` に設定すると、トランザクションの整合性が保持され、バッチにはソースのトランザクション内のすべての変更が確実に含まれます。 `BatchApplyPreserveTransaction` を `false` に設定すると、パフォーマンスを向上させるためにトランザクションの整合性が一時的に失われることがあります。 `BatchApplyPreserveTransaction` パラメータは、Oracle ターゲットエンドポイントにのみ適用され、`BatchApplyEnabled` パラメータが `true` に設定されている場合に限り、適切に機能します。 LOB 列がレプリケーションに含まれる場合、制限された LOB モードのみで `BatchApplyEnabled` を使用できます。 変更データ キャプチャ (CDC) のロードでこれらの設定を使用する方法の詳細については、「[変更処理のチューニング設定](CHAP_Tasks.CustomizingTasks.TaskSettings.ChangeProcessingTuning.md)」をご参照ください。 + `MaxFullLoadSubTasks` – 並列にロードするテーブルの最大数を指定します。デフォルトは 8、最大値は 49 です。 + `ParallelLoadThreads` – AWS DMS が各テーブルをターゲットデータベースにロードするために使用するスレッドの数を指定します。このパラメータには、非 RDBMS ターゲットの最大値があります。DynamoDB ターゲットの最大数は 200 です。Amazon Kinesis Data Streams、Apache Kafka、または Amazon OpenSearch Serviceターゲットの最大値は 32 です。この上限を引き上げるように要請できます。`ParallelLoadThreads` はフルロードタスクに適用します。個々のテーブルの並列ロードを設定する詳細については、「[テーブルとコレクション設定のルールとオペレーション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md)」をご参照ください。 この設定は、次のエンドポイントエンジンタイプに適用されます。 + DynamoDB + Amazon Kinesis Data Streams + Amazon MSK + Amazon OpenSearch Service + Amazon Redshift AWS DMS は、追加の接続属性として MySQL `ParallelLoadThreads`の をサポートします。 `ParallelLoadThreads`はタスク設定として MySQL には適用されません。 + `ParallelLoadBufferSize` – 並列ロードスレッドがターゲットにデータをロードするために使用するバッファに保存するレコードの最大数を指定します。デフォルト値は 50 です。最大値は 1000 です。この設定は現時点では、DynamoDB、Kinesis、Apache Kafka、OpenSearch がターゲットの場合にのみ有効です。このパラメータを `ParallelLoadThreads` で使用します。1 つ以上のスレッドがある場合にのみ `ParallelLoadBufferSize` が有効になります。個々のテーブルの並列ロードを設定する詳細については、「[テーブルとコレクション設定のルールとオペレーション](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md)」をご参照ください。 + `ParallelLoadQueuesPerThread` - 各同時スレッドがアクセスするキューの数を指定して、データレコードをキューから取り出し、ターゲットのバッチロードを生成します。デフォルトは 1 です。この設定は、現在、Kinesis または Apache Kafka がターゲットの場合にのみ有効です。 + `ParallelApplyThreads` – CDC ロード中に AWS DMS がデータレコードを Amazon DocumentDB、Kinesis、Amazon MSK、OpenSearch、または Amazon Redshift ターゲットエンドポイントにプッシュするために使用する同時スレッドの数を指定します。デフォルト値は 0 です。 この設定は CDC にのみ適用されます。この設定はフルロードには適用されません。 この設定は、次のエンドポイントエンジンタイプに適用されます。 + Amazon DocumentDB (MongoDB 互換性) + Amazon Kinesis Data Streams + Amazon Managed Streaming for Apache Kafka + Amazon OpenSearch Service + Amazon Redshift + `ParallelApplyBufferSize` – CDC ロード中に Amazon DocumentDB、Kinesis、Amazon MSK、OpenSearch、または Amazon Redshift のターゲットエンドポイントにプッシュする同時スレッドの各バッファキューに格納するレコードの最大数を指定します。デフォルト値は 100 です。最大値は 1,000 です。このオプションは、`ParallelApplyThreads` で複数のスレッドを指定する場合に使用します。 + `ParallelApplyQueuesPerThread` – CDC 中に各スレッドがキューからデータレコードを取り出して Amazon DocumentDB、Kinesis、Amazon MSK、または OpenSearch エンドポイントのバッチロードを生成するためにアクセスするキューの数を指定します。デフォルト値は 1 です。 # 全ロードタスク設定 全ロード設定には、以下のものが含まれます。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 + 全ロードセットアップ時にターゲットのロードを処理する方法を指定するには、`TargetTablePrepMode` オプションに次のいずれかの値を指定します。 + `DO_NOTHING` - 既存のターゲットテーブルのデータとメタデータには影響しません。 + `DROP_AND_CREATE` - 既存のテーブルが削除され、新しいテーブルがその場所に作成されます。 + `TRUNCATE_BEFORE_LOAD` - テーブルメタデータに影響を与えずにデータが切り捨てられます。 + 全ロードが完了するまでプライマリ キーや一意のインデックスの作成を遅らせるには、`CreatePkAfterFullLoad` オプションを `true` に設定します。 + 全ロードタスクと CDC が有効なタスクの場合、次の `Stop task after full load completes` のオプションを設定できます。 + `StopTaskCachedChangesApplied` – このオプションを `true` に設定し、全ロードが完了してキャッシュされた変更が適用された後にタスクを停止します。 + `StopTaskCachedChangesNotApplied` – キャッシュされた変更が適用される前にタスクを停止するには、このオプションを `true` に設定します。 + 並行してロードするテーブルの最大数を指定するには、`MaxFullLoadSubTasks` オプションを設定します。デフォルトは 8、最大値は 49 です。 + データレコードをターゲットエンドポイントにプッシュするために DMS がフルロードプロセス中に使用する同時スレッドの数を指定するには、`ParallelLoadThreads` を設定します。デフォルト値はゼロ (0) です。 **重要** `MaxFullLoadSubTasks` は、並行してロードするテーブルまたはテーブルのセグメント数を制御します。`ParallelLoadThreads` は、ロードを並行して実行するために移行タスクが使用するスレッド数を制御します。**上記の設定は乗算です。そのため、フルロードタスクで使用するスレッドの合計数は、ほぼ `ParallelLoadThreads `値と `MaxFullLoadSubTasks` 値を乗算した値になります (`ParallelLoadThreads` **\$1** `MaxFullLoadSubtasks)`) 多数のフルロードサブタスクがあり、多数の並列ロードスレッドがあるタスクを作成すると、タスクがメモリを大量に消費してエラーとなる可能性があります。 + が全ロードオペレーションを開始する前にトランザクションが閉じるのを AWS DMS 待機する秒数を設定できます。これを行うには、タスクの開始時にトランザクションが開いている場合は、`TransactionConsistencyTimeout` オプションを設定します。デフォルト値は 600 (10 分) です。 は、開いているトランザクションがある場合でも、タイムアウト値に達した後に全ロード AWS DMS を開始します。全ロードのみのタスクは 10 分間待機せず、即座に開始されます。 + 一括転送可能なレコードの最大数を指定するには、`CommitRate` オプションを設定します。デフォルト値は 10000 で、最大値は 50000 です。 # Time Travel タスクの設定 レプリケーションタスクをログ記録およびデバッグするには、 AWS DMS Time Travel を使用できます。この方法の場合、Amazon S3 を使用してログを保存し、暗号化キーを使用して暗号化します。Time Travel S3 バケットにアクセスできる場合にのみ、日時フィルターを使用して S3 ログを取得して、必要に応じてログを表示、ダウンロード、難読化できます。これにより、安全に「時間を遡って」データベースのアクティビティを調査できます。Time Travel は CloudWatch のログ記録とは独立して機能します。CloudWatch ログの詳細については、「[ロギングタスク設定](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md)」を参照してください。 Time Travel は、 AWS DMSサポートされている Oracle、Microsoft SQL Server、PostgreSQL ソースエンドポイント、および AWS DMSサポートされている PostgreSQL と MySQL ターゲットエンドポイントを持つすべての AWS リージョンで使用できます。Time Travel は、フルロードと変更データキャプチャ (CDC) タスクと CDC のみのタスクでのみ有効にできます。Time Travel を有効にしたり、既存の Time Travel 設定を変更したりするには、レプリケーションタスクが停止していることを確認します。 Time Travel 設定には、次の `TTSettings` プロパティがあります。 + `EnableTT` – このオプションを `true` に設定すると、タスクの Time Travel ログ記録が有効になります。デフォルト値は `false` です。 タイプ: ブール値 必須: いいえ + `EncryptionMode` – データとログを保存するために S3 バケットで使用されるサーバー側の暗号化のタイプ。`"SSE_S3"` (デフォルト) または `"SSE_KMS"` のいずれかを指定できます。 `EncryptionMode` を `"SSE_KMS"` から `"SSE_S3"` に変更することはできても、その逆の変更はできません。 タイプ: 文字列 必須: いいえ + `ServerSideEncryptionKmsKeyId` – `"SSE_KMS"`に を指定する場合は`EncryptionMode`、カスタムマネージド AWS KMS キーの ID を指定します。使用するキーに、 AWS Identity and Access Management (IAM) ユーザーのアクセス許可を有効にし、キーの使用を許可するポリシーがアタッチされていることを確認します。 `"SSE_KMS"` オプションでは、独自のカスタマーマネージド 対称 KMS キーのみがサポートされます。 タイプ: 文字列 必須: `EncryptionMode` が `"SSE_KMS"` に設定されている場合のみ + `ServiceAccessRoleArn` – IAM ロールにアクセスするためにサービスが使用する Amazon リソースネーム (ARN)。ロール名は、`dms-tt-s3-access-role` に設定します。これは、 が S3 バケットからのオブジェクト AWS DMS の書き込みと読み取りを許可する必須の設定です。 タイプ: 文字列 必須: Time Travel がオンになっている場合 このロールのポリシーの例は次のとおりです。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "s3:PutObject", "kms:GenerateDataKey", "kms:Decrypt", "s3:ListBucket", "s3:DeleteObject" ], "Resource": [ "arn:aws:s3:::S3bucketName*", "arn:aws:kms:us-east-1:112233445566:key/1234a1a1-1m2m-1z2z-d1d2-12dmstt1234" ] } ] } ``` ------ このロールの信頼ポリシーの例は次のとおりです。 ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "dms.amazonaws.com" ] }, "Action": "sts:AssumeRole" } ] } ``` ------ + `BucketName` – Time Travel ログを保存する S3 バケットの名前。Time Travel ログを有効にする前に、この S3 バケットが作成されていることを確認します。 タイプ: 文字列 必須: Time Travel がオンになっている場合 + `BucketFolder` – S3 バケット内のフォルダ名を設定するためのオプションのパラメータ。のパラメータを指定すると、DMS は `"/BucketName/BucketFolder/taskARN/YYYY/MM/DD/hh"` のパスにTime Travel ログを作成します。このパラメータを指定しない場合、 はデフォルトパスを として AWS DMS 作成します`"/BucketName/dms-time-travel-logs/taskARN/YYYY/MM/DD/hh`。 タイプ: 文字列 必須: いいえ + `EnableDeletingFromS3OnTaskDelete` – このオプションを に設定すると`true`、タスクが削除されると、 は S3 から Time Travel ログ AWS DMS を削除します。デフォルト値は `false` です。 タイプ: 文字列 必須: いいえ + `EnableRawData` – このオプションを `true` に設定すると、Time Travel ログのデータ操作言語 (DML) の raw データがTime Travel ログの `raw_data` 列の下に表示されます。詳細については、「[Time Travel ログの使用](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.LogSchema.md)」を参照してください。デフォルト値は `false` です。このオプションを `false` に設定すると、DML タイプのみがキャプチャされます。 タイプ: 文字列 必須: いいえ + `RawDataFormat` – AWS DMS バージョン 3.5.0 以降では、 `EnableRawData` が に設定されている場合`true`。このプロパティは、Time Travel ログ内の DML の raw データの形式を指定し、次のとおり表示します。 + `"TEXT"` – CDC 中に `Raw` フィールドとしてキャプチャした DML イベントの、解析され、読み取り可能な列名と値。 + `"HEX"` – CDC 中に DML イベントでキャプチャした列名と値の元の16 進数値。 このプロパティは Oracle と Microsoft SQL Server データベースソースに適用されます。 タイプ: 文字列 必須: いいえ + `OperationsToLog` – Time Travel ログに記録する DML オペレーションのタイプを指定します。以下のいずれかを指定できます。 + `"INSERT"` + `"UPDATE"` + `"DELETE"` + `"COMMIT"` + `"ROLLBACK"` + `"ALL"` デフォルトは `"ALL"` です。 タイプ: 文字列 必須: いいえ + `MaxRecordSize` – 各行に記録される Time Travel ログのレコードの最大サイズを指定します。このプロパティを使用して、特に使用頻度の高いテーブルの Time Travel ログの増大を制御します。デフォルトは 64 KB です。 タイプ: 整数 必須: いいえ Time Travel ログを有効にして使用する方法の詳細については、次のトピックを参照してください。 **Topics** + [ # タスクの Time Travel ログを有効にする ](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.TaskEnabling.md) + [ # Time Travel ログの使用 ](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.LogSchema.md) + [ # が Time Travel ログを S3 AWS DMS にアップロードする頻度 ](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.UploadsToS3.md) # タスクの Time Travel ログを有効にする 前述の AWS DMS タスク設定を使用して、タスクの Time Travel を有効にできます。Time Travel を有効にする前に、レプリケーションタスクが停止していることを確認します。 **を使用して Time Travel を有効にするには AWS CLI** 1. DMS タスク設定 JSON ファイルを作成して、次のとおりの `TTSettings` セクションを追加します。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 ``` . . . }, "TTSettings" : { "EnableTT" : true, "TTS3Settings": { "EncryptionMode": "SSE_KMS", "ServerSideEncryptionKmsKeyId": "arn:aws:kms:us-west-2:112233445566:key/myKMSKey", "ServiceAccessRoleArn": "arn:aws:iam::112233445566:role/dms-tt-s3-access-role", "BucketName": "myttbucket", "BucketFolder": "myttfolder", "EnableDeletingFromS3OnTaskDelete": false }, "TTRecordSettings": { "EnableRawData" : true, "OperationsToLog": "DELETE,UPDATE", "MaxRecordSize": 64 }, . . . ``` 1. 適切なタスクアクションで、`--replication-task-settings` オプションを使用してこの JSON ファイルを指定します。例えば、次の CLI コードフラグメントは、では、このTime Travel 設定ファイルを `create-replication-task` の一部で指定しています。 ``` aws dms create-replication-task --target-endpoint-arn arn:aws:dms:us-east-1:112233445566:endpoint:ELS5O7YTYV452CAZR2EYBNQGILFHQIFVPWFRQAY \ --source-endpoint-arn arn:aws:dms:us-east-1:112233445566:endpoint:HNX2BWIIN5ZYFF7F6UFFZVWTDFFSMTNOV2FTXZA \ --replication-instance-arn arn:aws:dms:us-east-1:112233445566:rep:ERLHG2UA52EEJJKFYNYWRPCG6T7EPUAB5AWBUJQ \ --migration-type full-load-and-cdc --table-mappings 'file:///FilePath/mappings.json' \ --replication-task-settings 'file:///FilePath/task-settings-tt-enabled.json' \ --replication-task-identifier test-task . . . ``` この例での、Time Travel 設定ファイル名は `task-settings-tt-enabled.json` です。 同様に、このファイルを `modify-replication-task` アクションの一部として指定できます。 次のタスクアクションの Time Travel ログの特別な処理に注意します。 + `start-replication-task` – レプリケーションタスクを実行する際に、Time Travel に使用される S3 バケットにアクセスできない場合、タスクは `FAILED` としてマークされます。 + `stop-replication-task` – タスクが停止すると、 は、レプリケーションインスタンスで現在利用可能なすべての Time Travel ログを Time Travel に使用される S3 バケットに AWS DMS すぐにプッシュします。 レプリケーションタスク実行中は、`EncryptionMode` 値を `"SSE_KMS"` から `"SSE_S3"` に変更できます。ただし、その逆の変更はできません。 実行中のタスクの Time Travel ログのサイズが 1 GB を超える場合、DMS はそのサイズに達してから 5 分以内にログを S3 にプッシュします。タスクの実行後、S3 バケットまたは KMS キーにアクセスできなくなると、DMS はこのバケットへのログのプッシュを停止します。ログが S3 バケットにプッシュされていない場合は、S3 と アクセス AWS KMS 許可を確認してください。DMS が上記のログを S3 にプッシュする頻度の詳細については、「[が Time Travel ログを S3 AWS DMS にアップロードする頻度](CHAP_Tasks.CustomizingTasks.TaskSettings.TimeTravel.UploadsToS3.md)」を参照してください。 コンソールから既存のタスクの Time Travel を有効にするには、**[タスク設定]** の下にある JSON エディタオプションを使用して `TTSettings` セクションを追加します。 # Time Travel ログの使用 **Time Travel ログファイルは、次のフィールドを持つカンマ区切り値 (CSV) ファイルです。 ``` log_timestamp component dms_source_code_location transaction_id event_id event_timestamp lsn/scn primary_key record_type event_type schema_name table_name statement action result raw_data ``` Time Travel ログが S3 で利用できるようになったら、Amazon Athena などのツールを使用して直接アクセスし、クエリを実行できます。または、S3 から任意のファイルをダウンロードする場合と同様に、ログをダウンロードすることもできます。 `mytable` というテーブルのトランザクションがログ記録される Time Travel ログの例は次のとおりです。読みやすくするために、次のログには行末が追加されています。 ``` "log_timestamp ","tt_record_type","dms_source_code_location ","transaction_id", "event_id","event_timestamp","scn_lsn","primary_key","record_type","event_type", "schema_name","table_name","statement","action","result","raw_data" "2021-09-23T01:03:00:778230","SOURCE_CAPTURE","postgres_endpoint_wal_engine.c:00819", "609284109","565612992","2021-09-23 01:03:00.765321+00","00000E9C/D53AB518","","DML", "UPDATE (3)","dmstest","mytable","","Migrate","","table dmstest.mytable: UPDATE: id[bigint]:2244937 phone_number[character varying]:'phone-number-482' age[integer]:82 gender[character]:'f' isactive[character]:'true ' date_of_travel[timestamp without time zone]:'2021-09-23 01:03:00.76593' description[text]:'TEST DATA TEST DATA TEST DATA TEST DATA'" ``` # が Time Travel ログを S3 AWS DMS にアップロードする頻度 レプリケーションインスタンスのストレージ使用量を最小限に抑えるために、 は Time Travel ログを定期的に AWS DMS オフロードします。 Time Travel ログは、次の場合に Amazon S3 バケットにプッシュされます。 + ログの現在のサイズが 1 GB を超える場合、 は 5 分以内にログを S3 AWS DMS にアップロードします。したがって、 AWS DMS は実行中のタスクごとに S3 および に対して 1 時間 AWS KMS あたり最大 12 回の呼び出しを行うことができます。 + AWS DMS は、ログのサイズに関係なく、1 時間ごとにログを S3 にアップロードします。 + タスクが停止すると、 はタイムトラベルログを AWS DMS すぐに S3 にアップロードします。 # ロギングタスク設定 ロギング機能は、移行プロセス中に Amazon CloudWatch を使用して情報をログします。ロギングタスク設定を使用して、記録するコンポーネントアクティビティと、ログに書き込まれる情報量を指定できます。ログ記録タスク設定は JSON ファイルに書き込まれます。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 CloudWatch ログ記録は、いくつかの方法で有効にできます。移行タスクを作成する AWS マネジメントコンソール ときに、 で `EnableLogging`オプションを選択できます。または、 AWS DMS API を使用してタスクを作成する`true`ときに、 `EnableLogging`オプションを に設定することもできます。さらに、タスク設定のロギングセクションの JSON で `"EnableLogging": true` を指定することもできます。 `EnableLogging` を に設定すると`true`、 は CloudWatch グループ名とストリーム名を次のように AWS DMS 割り当てます。上記の値を直接設定することはできません。 + **CloudWatchLogGroup**: `dms-tasks-` + **CloudWatchLogStream**: `dms-task-` `` は、レプリケーションインスタンスの識別子です。`` は、タスク ARN の `` セクションの値です。がリソース ARN AWS DMS を生成する方法については、「」を参照してください[の Amazon リソースネーム (ARN) の構築 AWS DMS](CHAP_Introduction.AWS.ARN.md)。 ARNs CloudWatch は AWS Identity and Access Management (IAM) と統合され、 AWS アカウントのユーザーが実行できる CloudWatch アクションを指定できます。CloudWatch での IAM の操作方法については、*Amazon CloudWatch ユーザーガイド*の[Amazon CloudWatch の Identity and Access Management](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/auth-and-access-control-cw.html) と 「[Amazon CloudWatch API コールのログ記録](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/logging_cw_api_calls.html)」をご参照ください。 タスクログを削除するには、タスク設定のログ記録セクションの JSON で `DeleteTaskLogs` を true に設定します。 次のタイプのイベントのログ記録を指定できます。 + `FILE_FACTORY` – ファイルファクトリは、バッチ適用とバッチのロードに使用されるファイルを管理し、Amazon S3 エンドポイントを管理します。 + `METADATA_MANAGER` – メタデータマネージャは、レプリケーション中のソースとターゲットのメタデータ、パーティション分割、テーブルのステータスを管理します。 + `SORTER` – `SORTER` は、`SOURCE_CAPTURE` プロセスから受信イベントを受け取ります。イベントはトランザクションでバッチ処理され、`TARGET_APPLY` サービスコンポーネントに渡されます。`SOURCE_CAPTURE` プロセスが、`TARGET_APPLY` コンポーネントが処理できるよりも速くイベントを生成した場合、`SORTER` コンポーネントはバックログのイベントをディスクまたはスワップファイルにキャッシュします。キャッシュされたイベントは、レプリケーションインスタンスのストレージ不足を引き起こすよくある原因となります。 `SORTER` サービスコンポーネントは、キャッシュされたイベントの管理、CDC 統計の収集、タスクのレイテンシーの報告を行います。 + `SOURCE_CAPTURE` – 継続的なレプリケーション (CDC) データがソースデータベースまたはサービスからキャプチャされ、SORTER サービス コンポーネントに渡されます。 + `SOURCE_UNLOAD` – フルロード中にソースデータベースまたはサービスからデータがアンロードされます。 + `TABLES_MANAGER` — テーブルマネージャは、キャプチャされたテーブルを追跡し、テーブルの移行順序を管理し、テーブル統計を収集します。 + `TARGET_APPLY` - データおよびデータ定義言語 (DDL) ステートメントがターゲットデータベースに適用されます。 + `TARGET_LOAD` — データはターゲットデータベースにロードされます。 + `TASK_MANAGER` – タスクマネージャーは実行中のタスクを管理し、並列データ処理に向けてタスクをサブタスクに分割します。 + `TRANSFORMATION` – テーブルマッピング変換イベント。詳細については、「[テーブルマッピングを使用して、タスクの設定を指定する](CHAP_Tasks.CustomizingTasks.TableMapping.md)」を参照してください。 + `VALIDATOR/ VALIDATOR_EXT` – `VALIDATOR` サービスコンポーネントは、データがソースからターゲットに正確に移行されたことを検証します。詳細については、「[データ検証](CHAP_Validating.md)」を参照してください。 + `DATA_RESYNC` – データ再同期フローを管理するデータ再同期機能の一般的なコンポーネント。詳細については、「[AWS DMS データの再同期](CHAP_Validating.DataResync.md)」を参照してください。 + `RESYNC_UNLOAD` – データは再同期プロセス中にソースデータベースまたはサービスからアンロードされます。 + `RESYNC_APPLY` – データ操作言語 (DML) ステートメントは、再同期中にターゲットデータベースに適用されます。 次のログ記録コンポーネントは、`LOGGER_SEVERITY_DETAILED_DEBUG` ログの重大度レベルを使用すると大量のログを生成します。 + `COMMON` + `ADDONS` + `DATA_STRUCTURE` + `COMMUNICATION` + `FILE_TRANSFER` + `FILE_FACTORY` これらのコンポーネントでは、トラブルシューティング時に `DEFAULT` 以外のログレベルが必要になることは、ほぼありません。 AWS サポートから特に要求されない限り、`DEFAULT`これらのコンポーネントのログ記録レベルを から変更することはお勧めしません。 上記の 1 つを指定した後、次のリストに示すように、ログに記録される情報の量を指定できます。 緊急度のレベルは、情報の最低レベルから最高レベルの順に並んでいます。高いレベルには、必ず低いレベルの情報が含まれています。 + LOGGER\$1SEVERITY\$1ERROR(ロガーエラー重度) - エラー メッセージがログに書き込まれます。 + LOGGER\$1SEVERITY\$1WARNING(ロガーエラー警告) - 警告とエラー メッセージがログに書き込まれます。 + LOGGER\$1SEVERITY\$1INFO(ロガーエラー情報) - 情報メッセージ、警告、エラー メッセージがログに書き込まれます。 + LOGGER\$1SEVERITY\$1DEFAULT(ロガーデフォルト重度) - 情報メッセージ、警告、エラー メッセージがログに書き込まれます。 + LOGGER\$1SEVERITY\$1DEBUG(ロガーデバッグ重度) - デバッグ メッセージ、情報メッセージ、警告、エラーメッセージがログに書き込まれます。 + LOGGER\$1SEVERITY\$1DETAILED\$1DEBUG(ロガー詳細デバッグ重度) - すべての情報がログに書き込まれます。 次の JSON の例は、すべてのアクションと緊急度のレベルを記録するためのタスク設定を示しています。 ``` … "Logging": { "EnableLogging": true, "LogComponents": [ { "Id": "FILE_FACTORY", "Severity": "LOGGER_SEVERITY_DEFAULT" },{ "Id": "METADATA_MANAGER", "Severity": "LOGGER_SEVERITY_DEFAULT" },{ "Id": "SORTER", "Severity": "LOGGER_SEVERITY_DEFAULT" },{ "Id": "SOURCE_CAPTURE", "Severity": "LOGGER_SEVERITY_DEFAULT" },{ "Id": "SOURCE_UNLOAD", "Severity": "LOGGER_SEVERITY_DEFAULT" },{ "Id": "TABLES_MANAGER", "Severity": "LOGGER_SEVERITY_DEFAULT" },{ "Id": "TARGET_APPLY", "Severity": "LOGGER_SEVERITY_DEFAULT" },{ "Id": "TARGET_LOAD", "Severity": "LOGGER_SEVERITY_INFO" },{ "Id": "TASK_MANAGER", "Severity": "LOGGER_SEVERITY_DEBUG" },{ "Id": "TRANSFORMATION", "Severity": "LOGGER_SEVERITY_DEBUG" },{ "Id": "VALIDATOR", "Severity": "LOGGER_SEVERITY_DEFAULT" } ], "CloudWatchLogGroup": null, "CloudWatchLogStream": null }, … ``` # 制御テーブルタスク設定 コントロールテーブルは、 AWS DMS タスクに関する情報を提供します。また、現在の移行タスクと今後のタスクの両方を計画および管理するために使用できる有益な統計情報も提供します。これらのタスク設定は、JSON ファイルに適用するか、 AWS DMS コンソールの**タスクの作成**ページで**詳細設定**を選択して適用できます。[Apply Exceptions] (例外を適用)] テーブル (`dmslogs.awsdms_apply_exceptions`) は常にデータベース ターゲットで作成されます。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 AWS DMS は、フルロード \$1 CDC または CDC のみのタスク中にのみコントロールテーブルを作成し、フルロードのみのタスク中には作成しません。 全ロードタスクと CDC（既存データの移行あらに進行中変更のレプリケーション）タスクと CDC のみ（データ変更のみレプリケーション）タスクでは、以下の内容を含むテーブルを追加することもできます： + **[Replication Status (dmslogs.awsdms\$1status)]** (レプリケーションステータス (dmslogs.awsdms\$1status)) - このテーブルは、現在のタスクに関する詳細を提供します。これには、タスクステータス、タスクにより消費されるメモリの量、まだターゲットに適用されていない変更の数が含まれます。この表は、 AWS DMS が現在読み取り中のソースデータベース内の位置も示しています。タスクの全ロードフェーズあるいはデータ キャプチャの変更 (CDC) についても表示します。 + **[Suspended Tables (dmslogs.awsdms\$1suspended\$1tables)]** (停止済みテーブル (dmslogs.awsdms\$1suspended\$1tables)) - このテーブルは、停止済みテーブルのリストと、停止理由を示します。 + **[Replication History (dmslogs.awsdms\$1history)]** (レプリケーション履歴 (dmslogs.awsdms\$1history)) - このテーブルは、レプリケーション履歴に関する情報を提供します。この情報には、タスク中に処理されたレコードの数とボリューム、CDC タスク終了時のレイテンシー、およびその他の統計情報などが含まれています。 例外適用テーブル `dmslogs.awsdms_apply_exceptions` には、以下のパラメータが含まれます。 | 列 | 型 | 説明 | | --- | --- | --- | | TASK\$1NAME | nvchar | AWS DMS タスクのリソース ID。リソース ID は タスク ARN で確認できる。 | | TABLE\$1OWNER | nvchar | テーブルの所有者。 | | TABLE\$1NAME | nvchar | テーブル名。 | | ERROR\$1TIME | timestamp | 時間例外 (エラー) が発生しました。 | | STATEMENT | nvchar | エラーが発生したときに実行されたステートメント。 | | エラー | nvchar | エラーの名前と説明。 | レプリケーションステータステーブル (`dmslogs.awsdms_status`) には、タスクの現在のステータスとターゲットのデータベースが含まれます。これには、次の設定があります。 | 列 | 型 | 説明 | | --- | --- | --- | | SERVER\$1NAME | nvchar | レプリケーションタスクを実行しているマシンの名前。 | | TASK\$1NAME | nvchar | AWS DMS タスクのリソース ID。リソース ID は タスク ARN で確認できる。 | | TASK\$1STATUS | varchar | 次のいずれかの値になります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.html) 全ロードされているテーブルが少なくとも 1 つある限り、タスクのステータスを FULL LOAD と設定します。CDC が有効化されている場合、すべてのテーブルがロードされた後、タスクステータスは CHANGE PROCESSING に変更します。タスクを開始する前、またはタスクが完了した後は、タスクは NOT RUNNING に設定されます。 | | STATUS\$1TIME | timestamp | タスクの状態のタイムスタンプ。 | | PENDING\$1CHANGES | int | ソースデータベースでコミットされ、レプリケーションインスタンスのメモリとディスクにキャッシュされた変更レコードの数 | | DISK\$1SWAP\$1SIZE | int | 古い、またはオフロードされたトランザクションにより使用されるディスク領域の量。 | | TASK\$1MEMORY | int | 使用されている現在のメモリを MB で表示。 | | SOURCE\$1CURRENT \$1POSITION | varchar | AWS DMS 現在読み取り元のソースデータベース内の位置。 | | SOURCE\$1CURRENT \$1TIMESTAMP | timestamp | AWS DMS 現在読み取り元のソースデータベースのタイムスタンプ。 | | SOURCE\$1TAIL \$1POSITION | varchar | 最も以前に起動された完了していないトランザクションの位置。この値は、すべての変更を失わずに返すことができる最も新しい位置を示します。 | | SOURCE\$1TAIL \$1TIMESTAMP | timestamp | 最も以前に起動された完了していないトランザクションのタイムスタンプ。この値は、すべての変更を失わずに返すことができる最も新しいタイムスタンプを示します。 | | SOURCE\$1TIMESTAMP \$1APPLIED | timestamp | 最新の完了したトランザクションのタイムスタンプ。一括適用のプロセスでは、この値はバッチ内の最新トランザクション完了のタイムスタンプの値を示します。 | 停止したテーブル (`dmslogs.awsdms_suspended_tables`) には次のパラメータがあります。 | 列 | 型 | 説明 | | --- | --- | --- | | SERVER\$1NAME | nvchar | レプリケーションタスクを実行しているマシンの名前。 | | TASK\$1NAME | nvchar | AWS DMS タスクの名前 | | TABLE\$1OWNER | nvchar | テーブルの所有者。 | | TABLE\$1NAME | nvchar | テーブル名。 | | SUSPEND\$1REASON | nvchar | 停止理由 | | SUSPEND\$1TIMESTAMP | timestamp | 停止が実行された時刻 | レプリケーション履歴テーブル (`dmslogs.awsdms_history`) には、以下のパラメータが含まれます。 | 列 | 型 | 説明 | | --- | --- | --- | | SERVER\$1NAME | nvchar | レプリケーションタスクを実行しているマシンの名前。 | | TASK\$1NAME | nvchar | AWS DMS タスクのリソース ID。リソース ID は タスク ARN で確認できる。 | | TIMESLOT\$1TYPE | varchar | 次のいずれかの値になります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.html) タスクが全ロードと CDC の両方を実行している場合、2 つの履歴レコードがタイムスロットに書き込まれます。 | | TIMESLOT | timestamp | タイムスロットのタイムスタンプ終了。 | | TIMESLOT\$1DURATION | int | タイムスロットの時間 (分単位)。 | | TIMESLOT\$1LATENCY | int | タイムスロットの終了時のでターゲットレイテンシー (秒単位)。この値は CDC タイムスロットにのみ適用されます。 | | RECORDS | int | タイムスロット中に処理されるレコード数。 | | TIMESLOT\$1VOLUME | int | 処理されるデータ量を MB で 表示。 | [Validation Failure](検証失敗)テーブル (`awsdms_validation_failures_v1`) には、タスクのすべてのデータ検証の障害が含まれます。詳細については、「[データ検証のトラブルシューティング](CHAP_Validating.md#CHAP_Validating.Troubleshooting)」をご参照ください。 追加の制御テーブル設定には、以下のものが含まれます。 + `HistoryTimeslotInMinutes` - [Replication History](レプリケーション履歴) テーブルにおける各タイムスロットの長さを指定するには、このオプションを使用します。デフォルト値は 5 分です。 + `ControlSchema` – このオプションを使用して、 AWS DMS ターゲットのコントロールテーブルのデータベーススキーマ名を指定します。このオプションに情報を入力しない場合、テーブルは次の表のとおりデータベースのデフォルトの場所にコピーされます。 + PostgreSQL、Public + Oracle、ターゲットスキーマ + Microsoft SQL Server、ターゲットデータベースの dbo + MySQL、awsdms\$1control + MariaDB、awsdms\$1control + Amazon Redshift、公開 + DynamoDB、データベースに個別のテーブルとして作成 + IBM Db2 LUW、awsdms\$1control # ストリームバッファタスク設定 ストリームバッファ設定は AWS CLI、以下を含む を使用して設定できます。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 + `StreamBufferCount` - 移行タスクのデータストリームバッファの数を指定するには、このオプションを指定します。デフォルトストリームバッファの数は 3 です。この設定の値を大きくすると、データ抽出速度が上昇する可能性があります。ただし、このパフォーマンス向上は、レプリケーションサーバーのソースシステムやインスタンスクラスなど、移行環境に大きく依存します。ほとんどの場合はデフォルトで十分です。 + `StreamBufferSizeInMB` - 各データストリームバッファの最大サイズを指定するには、このオプションを使用します。デフォルトサイズは 8 MB です。非常に大きい LOB を使用する場合、このオプションの値を大きくする必要がある場合があります。また、ストリームバッファサイズが不十分であることを示すメッセージがログファイルに記録されている場合も、この値を大きくする必要がある可能性があります。このオプションのサイズを計算するときは、` [Max LOB size (or LOB chunk size)]*[number of LOB columns]*[number of stream buffers]*[number of tables loading in parallel per task(MaxFullLoadSubTasks)]*3` 式を使用できます。 + `CtrlStreamBufferSizeInMB` - 制御ストリーム バッファのサイズを設定するには、このオプションを使用します。値は MB 単位で、1 ～ 8 が使用できます。デフォルト値は 5 です。かなり多くのテーブル (数万のテーブルなど) を使用している場合、状況によってはこの値を大きくする必要があります。 # 変更処理のチューニング設定 次の設定は、変更データキャプチャ (CDC) 中に がターゲットテーブルの変更 AWS DMS を処理する方法を決定します。これらの設定のいくつかは、ターゲットメタデータパラメータ `BatchApplyEnabled` の値によって異なります。`BatchApplyEnabled` パラメータの詳細については、「[ターゲットメタデータのタスク設定](CHAP_Tasks.CustomizingTasks.TaskSettings.TargetMetadata.md)」をご参照ください。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 変更処理のチューニング設定には、以下のものが含まれます。 以下の設定は、ターゲットメタデータパラメータ `BatchApplyEnabled` を `true` に設定している場合にのみ適用されます。 + `BatchApplyPreserveTransaction` – `true` に設定すると、トランザクションの整合性が保持され、必ずバッチにはソースからのトランザクション内のすべての変更が含まれます。デフォルト値は `true` です。この設定は、Oracle ターゲットエンドポイントにのみ適用されます。 `false` に設定すると、パフォーマンスを向上させるためにトランザクションの整合性が一時的に失われることがあります。ソースからのトランザクション内のすべての変更が 1 バッチでターゲットに適用されるとは限りません。 デフォルトでは、 はトランザクションモードで変更 AWS DMS を処理し、トランザクションの整合性を維持します。トランザクションの完全性を一時的に失効できる場合は、代わりに [最適化バッチ] オプションを使用できます。このオプションでは、効率的にトランザクションがグループ化され、効率化のためにバッチに適用します。バッチ最適化適用オプションを使用すると、ほとんどの場合、参照整合性の制約に違反します。そのため、移行プロセス中にこれらの制約をオフにし、カットオーバー プロセスの一環として再度オンにすることをお勧めします。 + `BatchApplyTimeoutMin` – バッチ変更の各アプリケーション間で が AWS DMS 待機する最小時間を秒単位で設定します。デフォルト値は 1 です。 + `BatchApplyTimeoutMax` – バッチ変更の各適用からタイムアウトするまでに が AWS DMS 待機する最大時間を秒単位で設定します。デフォルト値は 30 です。 + `BatchApplyMemoryLimit` – **[Batch optimized apply mode]** (最適化バッチ適用モード) での前処理に使用されるメモリの最大量 (MB) を設定します。デフォルト値は 500 です。 + `BatchSplitSize` - 1 つのバッチに適用される変更の最大数を設定します。デフォルト値 0 は、適用される制限がないことを意味します。 以下の設定は、ターゲットメタデータパラメータ `BatchApplyEnabled` を `false` に設定している場合にのみ適用されます。 + `MinTransactionSize` - 各トランザクションに含める変更の最小数を設定します。デフォルト値は 1000 です。 + `CommitTimeout` – タイムアウトを宣言する前に がトランザクション AWS DMS をバッチで収集する最大時間を秒単位で設定します。デフォルト値は 1 です。 双方向レプリケーションの場合、次の設定は、ターゲットメタデータパラメータ `BatchApplyEnabled` を `false` に設定している場合にのみ適用されます。 + `LoopbackPreventionSettings` – これらの設定により、双方向レプリケーションに関係するタスクのペアで進行中の各レプリケーション タスクのループバックを阻止します。*ループバック防止*は、双方向レプリケーションの両方向で同一の変更が適用されてデータが破損するのを防ぎます。双方向レプリケーションの詳細については、「[双方向レプリケーションの実行](CHAP_Task.CDC.md#CHAP_Task.CDC.Bidirectional)」をご参照ください。 AWS DMS は、トランザクションがソース、ターゲット、またはその両方に完全にコミットされるまで、トランザクションデータをメモリに保持しようとします。ただし、割り当てたメモリより大きいトランザクションや、指定した制限時間内にコミットされないトランザクションは、ディスクに書き込まれます。 以下の設定は、変更処理のモードに関係なく、変更処理のチューニングに適用されます。 + `MemoryLimitTotal` - すべてのトランザクションがディスクに書き込まれるまでにメモリで占有可能な最大サイズ (MB) を設定します。デフォルト値は 1024 です。 + `MemoryKeepTime` - 各トランザクションがディスクに書き込まれるまでにメモリに保持できる最長時間 (秒) を設定します。期間は、 がトランザクションのキャプチャ AWS DMS を開始した時刻から計算されます。デフォルト値は 60 です。 + `StatementCacheSize` - ターゲットに変更を適用するときに、後で実行するためにサーバーに保存する準備済みステートメントの最大数を設定します。デフォルト値は 50 で、最大値は 200 です。 + `RecoveryTimeout`– CDC モードでタスクを再開する場合、RecoveryTimeout はタスクが再開チェックポイントに到達するまで待機する時間 (分単位) を制御します。設定した期間内にチェックポイントが検出されない場合、タスクは失敗します。デフォルトの動作は、チェックポイントイベントを無期限に待機することです。 変更処理チューニングを処理するタスク設定がタスク設定 JSON ファイルにどのように表示されるかの例: ``` "ChangeProcessingTuning": { "BatchApplyPreserveTransaction": true, "BatchApplyTimeoutMin": 1, "BatchApplyTimeoutMax": 30, "BatchApplyMemoryLimit": 500, "BatchSplitSize": 0, "MinTransactionSize": 1000, "CommitTimeout": 1, "MemoryLimitTotal": 1024, "MemoryKeepTime": 60, "StatementCacheSize": 50 "RecoveryTimeout": -1 } ``` データ レプリケーション タスク中に Amazon S3 ターゲットへの書き込みの頻度を制御するには、`cdcMaxBatchInterval` と `cdcMinFileSize` の追加接続属性を設定することができます。これにより、追加のオーバーヘッド オペレーションなしでデータを分析する際のパフォーマンスが向上します。詳細については、「[のターゲットとして Amazon S3 を使用する場合のエンドポイント設定 AWS DMS](CHAP_Target.S3.md#CHAP_Target.S3.Configuring)」をご参照ください。 # データ検証タスクの設定 データがソースからターゲットに正確に移行されたことを確認できます。タスクの検証を有効にすると、 はテーブルに対して全ロードが実行された直後にソースデータとターゲットデータの比較 AWS DMS を開始します。タスクのデータ検証の詳細、要件、データベースサポートのスコープ、レポートするメトリクスについては、「[AWS DMS データ検証](CHAP_Validating.md)」をご参照ください。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 データの検証設定およびその値には、以下のものが含まれます。 + `EnableValidation` - true に設定すると、データの検証を有効にします。それ以外の場合は、タスクの検証が無効になります。デフォルト値は false です。 + `ValidationMode` – がソーステーブルに対してターゲットテーブルのデータ AWS DMS を検証する方法を制御します。レプリケーションエンジンバージョン 3.5.4 以降、DMS はサポートされている移行パス`GROUP_LEVEL`に対してこれを に自動的に設定し、検証パフォーマンスが向上し、大規模なデータセットの処理が大幅に高速化されます。この機能強化は、[AWS DMS データ再同期](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.DataResync.html#CHAP_DataResync.limitations)にリストされている移行パスの移行に適用されます。他のすべての移行パスでは、検証モードはデフォルトで になります`ROW_LEVEL`。 **注記** 設定に関係なく、 はテーブル AWS DMS 検証によって設定されたすべての行を検証します。 + `FailureMaxCount` - タスク検証が停止する前に、検証を失敗できるレコードの最大数を指定します。デフォルト値は 10,000 です。検証に失敗するレコードの数に関係なく検証を継続するには、この値をソースのレコード数より大きく設定します。 + `HandleCollationDiff` – このオプションを に設定すると`true`、検証はソースデータベースとターゲットデータベース間の列照合の違いを考慮します。それ以外の場合は、このような列照合の違いは検証で無視されます。列の照合は行の順序を指定でき、データ検証にとってはとても重要となります。`HandleCollationDiff` を true に設定すると、この照合の違いを自動的に解決し、データ検証における誤検出を防ぎます。デフォルト値は `false` です。 + `RecordFailureDelayInMinutes` – 検証障害の詳細を報告する前に遅延を分単位で指定します。 全体的な DMS タスク CDC レイテンシーが の値より大きい`RecordFailureDelayInMinutesthen`場合、例えば `RecordFailureDelayInMinutes`が 5 で CDC レイテンシーが 7 分の場合、DMS は検証失敗の詳細を報告するまで 7 分待機します。 + `RecordFailureDelayLimitInMinutes` – 検証失敗の詳細を報告する前の遅延を指定します。 は、タスクのレイテンシー AWS DMS を使用して、ターゲットに変更を加える実際の遅延を認識し、誤検出を防ぎます。この設定は、実際の遅延と DMS タスク CDC レイテンシー値を上書きし、検証メトリクスを報告する前により大きな遅延を設定できます。デフォルト値は 0 です。 + `RecordSuspendDelayInMinutes` - `FailureMaxCount` で設定されたエラーしきい値のため、テーブル検証が中断されるまでの遅延時間を分単位で指定します。 + `SkipLobColumns` – このオプションを に設定すると`true`、 はタスク検証のテーブルの部分内のすべての LOB 列のデータ検証を AWS DMS スキップします。デフォルト値は `false` です。 + `TableFailureMaxCount` – テーブル検証が停止する前に、検証を失敗できるテーブルあたりの最大行数を指定します。デフォルト値は 1,000 です。 + `ThreadCount` – 検証中に が AWS DMS 使用する実行スレッドの数を指定します。各スレッドは、ソースとターゲットからまだ検証されていないデータを選択し、比較して検証します。デフォルト値は 5 です。をより高い数値`ThreadCount`に設定すると、 は検証をより迅速に完了 AWS DMS できます。ただし、この場合、 AWS DMS はより多くの同時クエリを実行し、ソースとターゲットでより多くのリソースを消費します。 + `ValidationOnly` – このオプションを `true` に設定すると、タスクはデータの移行やレプリケーションを実行せずにデータ検証を実行します。デフォルト値は `false` です。タスク作成後に `ValidationOnly` 設定を変更することはできません。 **[TargetTablePrepMode]** は `DO_NOTHING` (検証のみのタスクのデフォルト)に設定し、**[移行タイプ]** は次のいずれかに設定します。 + 全ロード — タスク**移行タイプ**を設定して、 AWS DMS コンソールで**既存のデータを移行**します。または、 AWS DMS API で移行タイプを FULL-LOAD に設定します。 + CDC — AWS DMS コンソールで、タスクの **[移行タイプ]** を **[データ変更のみをレプリケートする]** に設定します。または、 AWS DMS API で移行タイプを CDC に設定します。 選択した移行タイプを問わず、検証のみのタスクではデータが実際に移行またはレプリケートされることはありません。 詳細については、「[検証のみのタスク](CHAP_Validating.md#CHAP_Validating.ValidationOnly)」を参照してください。 **重要** `ValidationOnly` の設定はイミュータブルです。タスクの作成後、タスクに対する変更はできません。 + `ValidationPartialLobSize` - 列に保存されているすべてのデータを検証するのではなく、LOB 列の部分検証を実行するかどうかを指定します。これは、LOB データセット全体ではなく LOB データの一部のみを移行する場合に便利な機能です。この値は、KB 単位です。デフォルト値は 0 で、 AWS DMS はすべての LOB 列データを検証します。たとえば、 は、ソースとターゲットの両方の列データの最初の 32KB AWS DMS のみを検証する`"ValidationPartialLobSize": 32`ことを意味します。 + `PartitionSize` -ソースとターゲットの両方から比較noために読み取るレコードのバッチサイズを指定します。デフォルトは 10,000 です。 + `ValidationQueryCdcDelaySeconds` — CDC 更新ごとに、ソースとターゲットの両方で最初の検証クエリが遅延する時間。これにより、移行のレイテンシーが高い場合にリソースの競合が軽減される可能性があります。検証のみのタスクでは、このオプションは自動的に 180 秒に設定されます。デフォルトは 0 です。 たとえば、以下の JSON ではスレッドのデフォルト数の 2 倍のデータ検証を有効化しています。また、ここでは PostgreSQL エンドポイントでの列照合の違いによって生じるレコード順序の相違も考慮されます。また、すべての検証失敗を処理する追加の時間を考慮に入れた検証報告遅延を提供します。 ``` "ValidationSettings": { "EnableValidation": true, "ThreadCount": 10, "HandleCollationDiff": true, "RecordFailureDelayLimitInMinutes": 30 } ``` **注記** Oracle エンドポイントの場合、 は DBMS\$1CRYPTO AWS DMS を使用して BLOBs。Oracle エンドポイントで BLOB を使用する場合は、Oracle エンドポイントにアクセスするために使用されるユーザーアカウントに DBMS\$1CRYPTO での `execute` 許可を付与します。これを行うには、以下のステートメントを実行します。 ``` grant execute on sys.dbms_crypto to dms_endpoint_user; ``` # データ再同期設定 データ再同期機能を使用すると、データ検証レポートに基づいてターゲットデータベースをソースデータベースと再同期できます。詳細については、「[AWS DMS data validation](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html)」を参照してください。 再同期プロセスを設定する`ReplicationTaskSettings`エンドポイント`ResyncSettings`に のパラメータを追加できます。詳細については、[「タスクのタスク設定の指定」の「タスク設定の例](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.html#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)[AWS Database Migration Service](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.html)」を参照してください。 **注記** `ResyncSchedule` 再同期プロセスが有効で、タスクに CDC コンポーネントがある場合は、 および `MaxResyncTime`パラメータが必要です。フルロードのみのタスクには有効ではありません。 Data resync パラメータの設定と値は次のとおりです。 `EnableResync` に設定すると、データ再同期機能を有効にします`true`。デフォルトでは、データの再同期は無効になっています。 **データ型**: ブール値 **必須:** いいえ **デフォルト**: `false` **検証**: `ResyncSettings`パラメータが に存在する場合は null にできません`TaskSettings`。 `ResyncSchedule` データ再同期機能を有効にする時間枠。Cron 形式で存在する必要があります。詳細については、「[cron 式のルール](CHAP_Validating.DataResync.md#CHAP_DataResync.cron)」を参照してください。 **データ型**: 文字列 **必須:** いいえ **検証**: + Cron 式形式で存在する必要があります。 + が に`EnableResync`設定された CDC を持つタスクでは null にすることはできません`true`。 + CDC コンポーネントがないタスクには設定できません。 `MaxResyncTime` データ再同期機能を有効にするための分単位の最大時間制限。 **データ型**: 整数 **必須:** いいえ **検証**: + CDC を使用するタスクでは null にすることはできません。 + CDC のないタスクには必要ありません。 + 最小値: `5 minutes`、最大値: `14400 minutes` (10 日間）。 `Validation onlyTaskID` 検証タスクの一意の ID。検証のみのタスク ID は、ARN の最後に追加されます。例えば、次のようになります。 + 検証のみのタスク ARN: `arn:aws:dms:us-west-2:123456789012:task:6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI` + 検証のみのタスク ID: `6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI` **データ型**: 文字列 **必須:** いいえ **検証**: データ再同期機能が有効で検証が無効になっているタスクでは null にできません。 例: ``` "ResyncSettings": { "EnableResync": true, "ResyncSchedule": "30 9 ? * MON-FRI", "MaxResyncTime": 400, "ValidationTaskId": "JXPP94804DJOEWIJD9348R3049" }, ``` # 変更処理の DDL 処理のタスク設定 次の設定は、 が変更データキャプチャ (CDC) 中にターゲットテーブルのデータ定義言語 (DDL) の変更 AWS DMS を処理する方法を決定します。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 変更処理の DDL を処理するタスク設定には、次のものがあります。 + `HandleSourceTableDropped –` ソーステーブルが削除されたときにターゲットテーブルを削除するには、このオプションを `true` に設定します。 + `HandleSourceTableTruncated`ソーステーブルが切り捨てられたときにターゲットテーブルを切り捨てるには、このオプションを `true` に設定します。 + `HandleSourceTableAltered` – ソーステーブルが変更されたときにターゲットテーブルを変更するには、このオプションを `true` に設定します。 次に、変更処理の DDL を処理するタスク設定が、タスク設定 JSON ファイルにどのように表示されるかを示します。 ``` "ChangeProcessingDdlHandlingPolicy": { "HandleSourceTableDropped": true, "HandleSourceTableTruncated": true, "HandleSourceTableAltered": true }, ``` **注記** 特定のソースでサポートされている DDL ステートメントについては、そのソースについて説明しているトピックをご参照ください。 # 文字置換タスクの設定 レプリケーションタスクが、 `STRING`または `WSTRING` データ型を持つすべてのソースデータベース列のターゲットデータベースで文字置換を実行するように AWS DMS 指定できます。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 次のソースデータベースとターゲットデータベースからのエンドポイントを持つ任意のタスクの文字置換を設定できます。 + ソースデータベース。 + Oracle + Microsoft SQL Server + MySQL + MariaDB + [PostgreSQL] + SAP Adaptive Server Enterprise (ASE) + IBM Db2 LUW + ターゲットデータベース: + Oracle + Microsoft SQL Server + MySQL + MariaDB + [PostgreSQL] + SAP Adaptive Server Enterprise (ASE) + Amazon Redshift タスク設定の `CharacterSetSettings` パラメータを使用して、文字置換を指定できます。これらの文字置換は、16 進数表記の Unicode コードポイント値を使用して指定された文字に対して発生します。両方が指定されている場合は、2 つのフェーズで置換を実装できます。 1. **個々の文字置換** — ソース上の選択した文字の値を、ターゲット上の対応する文字の指定された置換値に置き換え AWS DMS ることができます。`CharacterSetSettings` の `CharacterReplacements` 配列を使用して、指定した Unicode コードポイントを持つすべてのソース文字を選択します。また、この配列を使用して、ターゲットの対応する文字の置換コードポイントを指定します。 特定のコードポイントを持つソースのすべての文字を選択するには、`CharacterReplacements` 配列の `SourceCharacterCodePoint` のインスタンスをそのコードポイントに設定します。次に、この配列で `TargetCharacterCodePoint` の対応するインスタンスを設定することで、すべての同等のターゲット文字の置換コードポイントを指定します。ターゲットキャラクターを置き換えるのではなく削除するには、`TargetCharacterCodePoint` の適切なインスタンスをゼロ (0) に設定します。`CharacterReplacements` 配列で `SourceCharacterCodePoint` 設定と `TargetCharacterCodePoint` 設定の追加のペアを指定することで、必要な数のターゲットキャラクターの値を置換または削除できます。`SourceCharacterCodePoint` の複数のインスタンスに同じ値を指定した場合、対応する最後の `TargetCharacterCodePoint` の設定の値がターゲットに適用されます。 例えば、`CharacterReplacements` に次の値を指定するとします。 ``` "CharacterSetSettings": { "CharacterReplacements": [ { "SourceCharacterCodePoint": 62, "TargetCharacterCodePoint": 61 }, { "SourceCharacterCodePoint": 42, "TargetCharacterCodePoint": 41 } ] } ``` この例では、 はすべての文字をターゲット上のソースコードポイントの 16 進値 62 でコードポイント値 61 の文字 AWS DMS に置き換えます。また、すべての文字をターゲットのソースコードポイント 42 に、コードポイント値 41 の文字 AWS DMS に置き換えます。つまり、 AWS DMS は、ターゲット上の文字 `'b'` のすべてのインスタンスを文字 `'a'` で置き換えます。同様に、 AWS DMS はターゲット`'B'`上の文字のすべてのインスタンスを文字 に置き換えます`'A'`。 1. **文字セットの検証と置換** – 個々の文字置換が完了したら、指定した 1 文字セットにすべてのターゲット文字の有効な Unicode コードポイントがあることを確認 AWS DMS できます。`CharacterSetSettings` で `CharacterSetSupport` を使用して、このターゲットキャラクターの検証と変更を設定します。検証文字セットを指定するには、`CharacterSetSupport` で `CharacterSet` を文字セットの文字列値に設定します。（指定できる値については、`CharacterSet`を参照してください） 次のいずれかの方法で、無効なターゲット文字を で AWS DMS 変更できます。 + 現在のコードポイントに関係なく、すべての無効なターゲット文字に対して 1 つの置換 Unicode コードポイントを指定します。この置換コードポイントを設定するには、`CharacterSetSupport` の `ReplaceWithCharacterCodePoint` を指定された値に設定します。 + `ReplaceWithCharacterCodePoint` をゼロ (0) に設定して、すべての無効なターゲット文字の削除を設定します。 例えば、`CharacterSetSupport` に次の値を指定するとします。 ``` "CharacterSetSettings": { "CharacterSetSupport": { "CharacterSet": "UTF16_PlatformEndian", "ReplaceWithCharacterCodePoint": 0 } } ``` この例では、 は、文字セットで無効なターゲットで見つかった`"UTF16_PlatformEndian"`文字をすべて AWS DMS 削除します。したがって、16 進値で指定された文字 `2FB6` はすべて削除されます。この値は 4 バイトの Unicode コードポイントであり、UTF16 文字セットが 2 バイトのコードポイントを持つ文字のみを受け付けるため、無効です。 **注記** レプリケーションタスクは、テーブルマッピングで指定したグローバルまたはテーブルレベルの変換を開始する前に、指定されたすべての文字置換を完了します。テーブルマッピングの詳細については、「[テーブルマッピングを使用して、タスクの設定を指定する](CHAP_Tasks.CustomizingTasks.TableMapping.md)」をご参照ください。 文字置換では LOB データ型をサポートしていません。これには、DMS が LOB データ型と見なすすべてのデータ型が含まれます。例えば、Oracle の `Extended` データ型は LOB と見なされます。ソースデータ型の詳細については、次の「[Oracle のソースデータ型](CHAP_Source.Oracle.md#CHAP_Source.Oracle.DataTypes)」を参照してください。 で が AWS DMS サポートする値は、次の表のとおり`CharacterSet`です。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.CharacterSubstitution.html) # 前イメージタスク設定前 Kinesis や Apache Kafka のようなデータストリーミングターゲットに CDC 更新を書き込む場合、更新により変更される前のソースデータベース行の元の値を表示できます。これを可能にするために、 はソースデータベースエンジンによって提供されたデータに基づいて、更新イベントの*前のイメージ* AWS DMS を入力します。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 これを行うには、ソースデータベースシステムから収集された値を使用して、すべての更新オペレーションに新しい JSON 属性を追加する `BeforeImageSettings` パラメータを使用します。 `BeforeImageSettings` を全ロードと CDC タスクのみ、または CDC のみのタスクに適用することを忘れないでください。全ロードと CDC タスクにより、既存のデータが移行され、継続的変更のレプリケーションをできます。CDC のみのタスクは、データ変更のみのレプリケーションとなります。 全ロードのタスクには `BeforeImageSettings` を適用しないでください。 `BeforeImageSettings` で考えられるオプション： + `EnableBeforeImage` — `true` に設定すると、前イメージが有効になります。デフォルトは `false` です。 + `FieldName` — 新しい JSON 属性に名前を割り当てます。`EnableBeforeImage` が `true` の場合、`FieldName` は必須であり、空にすることはできません。 + `ColumnFilter` — 前イメージを使用して追加する列を指定します。テーブルのプライマリキーの一部である列だけを追加するには、デフォルト値 `pk-only` を使用します。前イメージ値を持つ列を追加するには、`all` を使用します。変換前イメージは、CLOB や BLOB などのラージバイナリオブジェクト (LOB) データ型をサポートしていないことに注意します。 `BeforeImageSettings` の使用例： ``` "BeforeImageSettings": { "EnableBeforeImage": true, "FieldName": "before-image", "ColumnFilter": "pk-only" } ``` 追加のテーブルマッピング設定など、前イメージ設定前の詳細については、「[前イメージを使用した Kinesis データストリームの CDC 行の元の値のターゲットとしての表示](CHAP_Target.Kinesis.md#CHAP_Target.Kinesis.BeforeImage)」をご参照ください。 追加のテーブルマッピング設定を含む、Kafka の前イメージ設定の詳細については、「[ターゲットとして Apache Kafka の CDC 行の元の値を表示するために前イメージを使用](CHAP_Target.Kafka.md#CHAP_Target.Kafka.BeforeImage)」をご参照ください。 # エラー処理タスクの設定 次の設定を使用して、レプリケーションタスクのエラー処理の動作を設定できます。タスク設定ファイルを使用してタスク設定を設定する方法については、「[タスク設定例](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)」をご参照ください。 + `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 に設定します。 `RecoverableErrorCount` と `RecoverableErrorInterval` は、DMS タスクが十分な間隔で十分な再試行を行って適切に復旧が行える値に設定することをお勧めします。致命的なエラーが発生した場合、DMS はほとんどのシナリオで再起動の試行を停止します。 + `RecoverableErrorInterval` – タスクの再起動を試行するまで AWS に DMS が待機する秒数。デフォルトは 5 です。 + `RecoverableErrorThrottling` – 有効にすると、タスクの再起動を試みる間隔が `RecoverableErrorInterval` の値に基づいて徐々に増加します。例えば、`RecoverableErrorInterval` が 5 秒に設定されている場合、次の再試行は 10 秒後、次は 20 秒後、次は 20 秒後、その次は 40 秒後に行われます。デフォルトは `true` です。 + `RecoverableErrorThrottlingMax` – `RecoverableErrorThrottling`が有効になっている場合にタスクの再起動を試行するまで AWS に DMS が待機する最大秒数。デフォルトは 1800 です。 + `RecoverableErrorStopRetryAfterThrottlingMax`– デフォルト値は に設定され`true`、DMS は、 ごとに復旧試行間の AWS DMS 待機の最大秒数に達した後、タスクの再開を停止します`RecoverableErrorStopRetryAfterThrottlingMax`。に設定すると`false`、DMS は、復旧試行の間に AWS DMS 待機する最大秒数に達した後、 ごとに `RecoverableErrorCount`に達する`RecoverableErrorStopRetryAfterThrottlingMax`までタスクを再開し続けます。 + `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` – ターゲットレコードがない場合、欠落しているターゲットレコードがターゲットテーブルに挿入されます。 は、タスクの LOB 列のサポート AWS DMS を完全に無効にします。このオプションを選択するには、Oracle がソースデータベースの場合、すべてのソーステーブルの列に対し、完全なサプリメンタルロギングが有効である必要があります。 **注記** **トランザクション適用モード**の場合: このプロセスでは、システムは最初にレコードの更新を試みます。ターゲットにレコードがないために更新が失敗した場合、失敗したレコードに対して削除を実行し、新しいレコードを挿入します。このプロセスでは、Oracle ソースデータベースの完全なサプリメンタルロギングが必要であり、DMS はこのタスクの LOB 列のサポートを無効にします。 **バッチ適用モード**の場合: プロセスは、新しいレコードの完全なセットを挿入する前に、ターゲットバッチ内のすべての既存のレコードを削除し、データの置き換えをクリーンに行います。 + `ApplyErrorEscalationPolicy` – エラーの最大数 ( AWS `ApplyErrorEscalationCount`パラメータを使用して設定) に達したときに DMS が実行するアクションを決定します。デフォルトは LOG\$1ERROR です： + `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 で始まると、CDC を開始する前に、最も古いオープントランザクションが終了するまで期間限定で AWS DMS 待機します。最も古いオープントランザクションがタイムアウトに達するまで閉じない場合、ほとんどの場合、そのトランザクションを無視して CDC AWS DMS を開始します。このオプションを `true` に設定すると、タスクは失敗します。 + `FullLoadIgnoreConflicts` – キャッシュされたイベントを適用するときに、 が「影響を受ける行がゼロ」を無視し、「重複」エラー AWS DMS を持つ`true`ようにこのオプションを に設定します。に設定すると`false`、 はすべてのエラーを無視せずに AWS DMS 報告します。デフォルトは `true` です。 + `DataMaskingErrorPolicy` – 互換性のないデータ型やその他の理由でデータマスキングが失敗した場合に AWS DMS 実行するアクションを決定します。以下のオプションを使用できます。 + `STOP_TASK` (デフォルト) – タスクが停止し、手動による介入が必要です。 + `IGNORE_RECORD` – タスクは続行され、該当するレコードのデータは無視されます。 + `LOG_ERROR` – タスクは続行され、エラーはタスクログに書き込まれます。マスクされていないデータはターゲットテーブルにロードされます。 + `SUSPEND_TABLE` – タスクは続行されますが、エラーレコードのあるテーブルのデータはエラー状態になり、データ レプリケーションはされません。 **注記** ターゲットとしての Redshift のテーブルロードエラーは、 で報告されます`STL_LOAD_ERRORS`。詳細については、「**Amazon Redshift データベース開発者ガイド」の「[STL\$1LOAD\$1ERRORS](https://docs.aws.amazon.com/redshift/latest/dg/r_STL_LOAD_ERRORS.html)」を参照してください。 **注記** 復旧可能なエラーに関連するパラメータの変更は、DMS タスクを停止して再開した後にのみ有効になります。変更は現在の実行には適用されません。 # タスク設定の保存 別のタスクで設定を再利用する場合、タスクの設定を JSON ファイルして保存することができます。JSON ファイルにコピーするタスク設定は、タスクのセクション**[Overview details]** (概要の詳細) の下で検索できます。 **注記** 他のタスクでタスク設定を再利用するときは、`CloudWatchLogGroup` と `CloudWatchLogStream` 属性を削除します。それ以外の場合は、次のエラーが表示されます：[SYSTEM ERROR MESSAGE:Task Settings CloudWatchLogGroup or CloudWatchLogStream cannot be set on create.](システムエラーメッセージ:タスク設定 CloudWatchLogGroup または CloudWatchLogStream は、作成時に設定できません。) たとえば、以下の JSON ファイルにはタスクに保存された設定が含まれています。 ``` { "TargetMetadata": { "TargetSchema": "", "SupportLobs": true, "FullLobMode": false, "LobChunkSize": 0, "LimitedSizeLobMode": true, "LobMaxSize": 32, "InlineLobMaxSize": 0, "LoadMaxFileSize": 0, "ParallelLoadThreads": 0, "ParallelLoadBufferSize": 0, "BatchApplyEnabled": false, "TaskRecoveryTableEnabled": false, "ParallelLoadQueuesPerThread": 0, "ParallelApplyThreads": 0, "ParallelApplyBufferSize": 0, "ParallelApplyQueuesPerThread": 0 }, "FullLoadSettings": { "TargetTablePrepMode": "DO_NOTHING", "CreatePkAfterFullLoad": false, "StopTaskCachedChangesApplied": false, "StopTaskCachedChangesNotApplied": false, "MaxFullLoadSubTasks": 8, "TransactionConsistencyTimeout": 600, "CommitRate": 10000 }, "Logging": { "EnableLogging": true, "LogComponents": [ { "Id": "TRANSFORMATION", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "SOURCE_UNLOAD", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "IO", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "TARGET_LOAD", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "PERFORMANCE", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "SOURCE_CAPTURE", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "SORTER", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "REST_SERVER", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "VALIDATOR_EXT", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "TARGET_APPLY", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "TASK_MANAGER", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "TABLES_MANAGER", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "METADATA_MANAGER", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "FILE_FACTORY", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "COMMON", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "ADDONS", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "DATA_STRUCTURE", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "COMMUNICATION", "Severity": "LOGGER_SEVERITY_DEFAULT" }, { "Id": "FILE_TRANSFER", "Severity": "LOGGER_SEVERITY_DEFAULT" } ] }, "ControlTablesSettings": { "ControlSchema": "", "HistoryTimeslotInMinutes": 5, "HistoryTableEnabled": false, "SuspendedTablesTableEnabled": false, "StatusTableEnabled": false, "FullLoadExceptionTableEnabled": false }, "StreamBufferSettings": { "StreamBufferCount": 3, "StreamBufferSizeInMB": 8, "CtrlStreamBufferSizeInMB": 5 }, "ChangeProcessingDdlHandlingPolicy": { "HandleSourceTableDropped": true, "HandleSourceTableTruncated": true, "HandleSourceTableAltered": true }, "ErrorBehavior": { "DataErrorPolicy": "LOG_ERROR", "DataTruncationErrorPolicy": "LOG_ERROR", "DataErrorEscalationPolicy": "SUSPEND_TABLE", "DataErrorEscalationCount": 0, "TableErrorPolicy": "SUSPEND_TABLE", "TableErrorEscalationPolicy": "STOP_TASK", "TableErrorEscalationCount": 0, "RecoverableErrorCount": -1, "RecoverableErrorInterval": 5, "RecoverableErrorThrottling": true, "RecoverableErrorThrottlingMax": 1800, "RecoverableErrorStopRetryAfterThrottlingMax": true, "ApplyErrorDeletePolicy": "IGNORE_RECORD", "ApplyErrorInsertPolicy": "LOG_ERROR", "ApplyErrorUpdatePolicy": "LOG_ERROR", "ApplyErrorEscalationPolicy": "LOG_ERROR", "ApplyErrorEscalationCount": 0, "ApplyErrorFailOnTruncationDdl": false, "FullLoadIgnoreConflicts": true, "FailOnTransactionConsistencyBreached": false, "FailOnNoTablesCaptured": true }, "ChangeProcessingTuning": { "BatchApplyPreserveTransaction": true, "BatchApplyTimeoutMin": 1, "BatchApplyTimeoutMax": 30, "BatchApplyMemoryLimit": 500, "BatchSplitSize": 0, "MinTransactionSize": 1000, "CommitTimeout": 1, "MemoryLimitTotal": 1024, "MemoryKeepTime": 60, "StatementCacheSize": 50 }, "PostProcessingRules": null, "CharacterSetSettings": null, "LoopbackPreventionSettings": null, "BeforeImageSettings": null, "FailTaskWhenCleanTaskResourceFailed": false } ```