기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # 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) | | **작업 생성** 작업 생성 시 마이그레이션 설정과 함께 소스, 대상 및 복제 인스턴스를 지정합니다. | [작업 생성](CHAP_Tasks.Creating.md) | | **지속적 복제 태스크 생성** 원본과 대상 간에 지속적인 복제를 수행하는 작업을 설정할 수 있습니다. | [를 사용하여 지속적 복제를 위한 작업 생성 AWS DMS](CHAP_Task.CDC.md) | | **태스크 설정 적용** 각 작업에는 데이터베이스 마이그레이션의 요구 사항에 따라 구성할 수 있는 설정이 있습니다. JSON 파일에서 이러한 설정을 생성하거나 일부 설정에서는 AWS DMS 콘솔을 사용하여 설정을 지정할 수 있습니다. | [AWS Database Migration Service 작업에 대한 작업 설정 지정](#CHAP_Tasks.CustomizingTasks.TaskSettings) | | **데이터 유효성 검사** 데이터 검증을 사용하여 대상 데이터 스토어의 데이터를 소스 데이터 스토어의 데이터와 AWS DMS 비교합니다. | [AWS DMS 데이터 검증](CHAP_Validating.md) | | **작업 수정** 작업이 중지되면 작업 설정을 수정할 수 있습니다. | [작업 수정](CHAP_Tasks.Modifying.md) | | **작업 중 테이블 다시 로드** 작업 중에 오류가 발생하면 작업 중에 테이블을 다시 로드할 수 있습니다. | [작업 중 테이블 다시 로드](CHAP_Tasks.ReloadTables.md) | | **테이블 매핑 사용** 테이블 매핑에서는 여러 유형의 규칙을 사용하여 데이터 소스, 원본 스키마, 데이터, 작업 중 발생하는 모든 변환 등에 대한 작업 설정을 지정합니다. | 선택 규칙 [선택 규칙 및 작업](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Selections.md) 변환 규칙 [변환 규칙 및 작업](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Transformations.md) | | **필터 적용** 소스 필터를 사용하여 소스에서 대상으로 전송되는 레코드의 수와 유형을 제한할 수 있습니다. 예를 들어, 본사 사업장에서 근무하는 직원만이 대상 데이터베이스로 이동하도록 지정할 수 있습니다. 데이터 열에서 필터를 적용합니다. | [소스 필터 사용](CHAP_Tasks.CustomizingTasks.Filters.md) | | 태스크 모니터링 작업에서 사용하는 테이블과 작업 성능에 관한 정보를 가져오는 방법에는 여러 가지가 있습니다. | [AWS DMS 작업 모니터링](CHAP_Monitoring.md) | | 태스크 로그 관리 AWS DMS API 또는를 사용하여 작업 로그를 보고 삭제할 수 있습니다 AWS CLI. | [AWS DMS 작업 로그 보기 및 관리](CHAP_Monitoring.md#CHAP_Monitoring.ManagingLogs) | ## 작업 설정 예제 AWS Management Console 또는를 사용하여 복제 작업을 AWS CLI 생성할 수 있습니다. 를 사용하는 경우 JSON 파일을 생성한 다음 JSON 파일의 file:// URI를 [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) 파라미터로 지정하여 작업 설정을 AWS CLI지정합니다. 다음 예제에서는를 사용하여 `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 청크의 크기(단위: 킬로바이트[KB])를 입력합니다. `FullLobMode` 옵션은 매우 큰 LOB 크기에서 최고 성능을 발휘하지만 로드가 느려지는 경향이 있습니다. `LobChunkSize`의 권장값은 64킬로바이트[KB]입니다. `LobChunkSize`의 값을 64KB 이상으로 늘리면 작업이 실패할 수 있습니다. + `InlineLobMaxSize` -이 값은 전체 로드 중에 인라인LOBs AWS DMS 를 결정합니다. 작은 LOB를 전송하면 소스 테이블에서 조회하는 것보다 효율적입니다. 전체 로드 중에는 모든 LOBs AWS DMS 확인하고 보다 작은 LOBs에 대해 인라인 전송을 수행합니다`InlineLobMaxSize`.는 `InlineLobMaxSize`의 보다 큰 모든 LOBs를 AWS DMS 전송합니다`FullLobMode`. `InlineLobMaxSize`의 기본값은 0이고 범위는 1\$1102400킬로바이트(100MB)입니다. 모든 LOB가 `InlineLobMaxSize`에 지정된 값보다 작으면 `InlineLobMaxSize` 값만 지정하세요. + `LimitedSizeLobMode` – 이 옵션을 `true`로 설정하는 경우, `LobMaxSize` 옵션 값을 입력해야 합니다. 개별 LOB에서 최대 크기(KB)를 입력합니다. `LobMaxSize`의 최대 값은 102400킬로바이트(100MB)입니다. 이러한 작업 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 모드로 전환됩니다. 이러한 동작을 변경하려면 작업 설정 JSON 파일의 `"ErrorBehavior"` 그룹 속성에서 다음 정책에 대한 `"SUSPEND_TABLE"` 작업을 설정할 수 있습니다. + `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 열이 포함되면 `BatchApplyEnabled`를 제한된 LOB 모드에서만 사용할 수 있습니다. CDC(Change Data Capture) 로드에 이 설정을 사용하는 방법에 관한 자세한 내용은 [변경 처리 튜닝 설정](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입니다. 최대값은 1,000입니다. 현재 이 설정은 DynamoDB, Kinesis, Apache Kafka 또는 OpenSearch가 대상일 때만 유효합니다. 이 파라미터는 `ParallelLoadThreads`와 함께 사용하세요. `ParallelLoadBufferSize`는 둘 이상의 스레드가 있는 경우에만 유효합니다. 개별 테이블의 병렬 로드 설정에 관한 자세한 내용은 [테이블 및 컬렉션 설정 규칙과 작업](CHAP_Tasks.CustomizingTasks.TableMapping.SelectionTransformation.Tablesettings.md) 섹션을 참조하세요. + `ParallelLoadQueuesPerThread` – 대기열에서 데이터 레코드를 가져오고 대상에 대한 배치 로드를 생성하기 위해 각 동시 스레드가 액세스하는 대기열의 수를 지정합니다. 기본값은 1입니다. 현재 이 설정은 Kinesis 또는 Apache Kafka가 대상일 때만 유효합니다. + `ParallelApplyThreads` - CDC 로드 중에가 데이터 레코드를 Amazon DocumentDB, Kinesis, Amazon MSK, OpenSearch 또는 Amazon Redshift 대상 엔드포인트로 푸시하기 위해 AWS DMS 사용하는 동시 스레드 수를 지정합니다. 기본값은 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` 옵션을 설정합니다. 기본값은 10,000이고 최대값은 50,000입니다. # Time Travel 작업 설정 복제 작업을 로깅하고 디버깅하려면 AWS DMS Time Travel을 사용할 수 있습니다. 이 방식에서는 Amazon S3를 사용하여 로그를 저장하고 암호화 키를 사용하여 로그를 암호화합니다. Time Travel S3 버킷에 액세스할 경우에만 날짜-시간 필터를 사용하여 S3 로그를 검색한 다음, 필요에 따라 로그를 보고 다운로드하며 난독화할 수 있습니다. 이렇게 하면 안전하게 ‘과거로 이동’하여 데이터베이스 활동을 조사할 수 있습니다. Time Travel은 CloudWatch 로깅과는 상관없이 독립적으로 작동합니다. CloudWatch 로깅에 관한 자세한 내용은 [작업 설정 로깅](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md)을 참조하세요. AWS DMS지원되는 Oracle, Microsoft SQL Server 및 PostgreSQL 소스 엔드포인트와 AWS DMS지원되는 PostgreSQL 및 MySQL 대상 엔드포인트가 있는 모든 AWS 리전에서 Time Travel을 사용할 수 있습니다. 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"`에를 지정하는 경우 사용자 지정 관리형 AWS KMS 키의 ID를 `EncryptionMode`제공합니다. 사용하는 키에 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` AWS DMS 삭제되면가 S3에서 Time Travel 로그를 삭제합니다. 기본 값은 `false`입니다. 유형: 문자열 필수 항목 여부: 아니요 + `EnableRawData` – 이 옵션을 `true`로 설정하면 Time Travel 로그의 DML(데이터 조작 언어) 원시 데이터가 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 원시 데이터 형식을 지정하며 다음과 같이 표시할 수 있습니다. + `"TEXT"` – CDC 중에 캡처한 DML 이벤트의 구문 분석된 읽을 수 있는 열 이름과 값을 `Raw` 필드로 표시합니다. + `"HEX"` – CDC 중에 DML 이벤트에 대해 캡처한 열 이름 및 값의 원래 16진수입니다. 이 속성은 Oracle 및 Microsoft SQL Server 데이터베이스 원본에 적용됩니다. 유형: 문자열 필수 항목 여부: 아니요 + `OperationsToLog` – Time Travel 로그에 로그인하기 위한 DML 작업의 유형을 지정합니다. 다음 중 한 가지를 지정할 수 있습니다. + `"INSERT"` + `"UPDATE"` + `"DELETE"` + `"COMMIT"` + `"ROLLBACK"` + `"ALL"` 기본값은 `"ALL"`입니다. 유형: 문자열 필수 항목 여부: 아니요 + `MaxRecordSize` - 각 행에 기록되는 Time Travel 로그 레코드의 최대 크기를 지정합니다. 이 속성을 사용하여 특히 사용량이 많은 테이블의 Time Travel 로그 증가를 제어할 수 있습니다. 기본값은 64KB입니다. 유형: 정수 필수 항목 여부: 아니요 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 로그 크기가 1GB를 초과하는 경우, 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 ``` S3에서 Time Travel 로그를 사용할 수 있게 되면 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 버킷으로 푸시됩니다. + 현재 로그 크기가 1GB를 초과하는 경우는 5분 이내에 로그를 S3에 AWS DMS 업로드합니다. 따라서 AWS DMS 는 실행 중인 각 작업에 AWS KMS 대해 S3 및에 대해 시간당 최대 12개의 호출을 수행할 수 있습니다. + AWS DMS 는 로그 크기에 관계없이 매시간 S3에 로그를 업로드합니다. + 작업이 중지되면는 시간 이동 로그를 S3에 AWS DMS 즉시 업로드합니다. # 작업 설정 로깅 로깅 기능은 마이그레이션 프로세스 중에 Amazon CloudWatch를 사용하여 정보를 로그합니다. 작업 설정 로깅을 사용하면 로깅할 구성 요소 활동과 로그에 작성할 정보량을 지정할 수 있습니다. 작업 설정 로깅은 JSON 파일에 작성됩니다. 작업 구성 파일을 사용하여 작업 설정을 지정하는 방법에 관한 자세한 내용은 [작업 설정 예제](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)을 참조하세요. CloudWatch 로깅은 여러 가지 방법으로 활성화할 수 있습니다. 마이그레이션 작업을 생성할 AWS Management Console 때에서 `EnableLogging` 옵션을 선택할 수 있습니다. 또는 AWS DMS API를 사용하여 작업을 생성할 `true` 때 `EnableLogging` 옵션을 로 설정할 수 있습니다. 작업 설정의 JSON 로깅 섹션에서 `"EnableLogging": true`를 지정할 수도 있습니다. 를 `EnableLogging`로 설정하면가 다음과 같이 CloudWatch 그룹 이름과 스트림 이름을 `true` 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의 자격 증명 및 액세스 관리](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 Support에서 특별히 요청하지 않는 한 `DEFAULT` 이러한 구성 요소의 로깅 수준을에서 변경하지 않는 것이 좋습니다. 위의 항목 중 하나를 지정한 후 다음 목록과 같이 기록되는 정보의 양을 지정할 수 있습니다. 심각도 수준이 가장 낮은 정보에서 가장 높은 수준의 정보 순으로 표시됩니다. 높은 수준은 항상 낮은 수준의 정보를 포함합니다. + 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 콘솔의 태스크 생성 페이지에서 **고급** 설정을 선택하여 이러한 태스크 설정을 적용할 수 있습니다. **** 예외 적용 테이블(`dmslogs.awsdms_apply_exceptions`)은 데이터베이스 대상에 항상 생성됩니다. 작업 구성 파일을 사용하여 작업 설정을 지정하는 방법에 관한 자세한 내용은 [작업 설정 예제](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)을 참조하세요. AWS DMS 는 전체 로드 \$1 CDC 또는 CDC 전용 작업 중에만 제어 테이블을 생성하고 전체 로드 전용 작업 중에는 생성하지 않습니다. 전체 로드 및 CDC(기존 데이터 마이그레이션 및 진행 중인 변경 사항 복제) 및 CDC 전용(데이터 변경 사항만 복제) 작업의 경우, 다음을 비롯한 추가 테이블을 만들 수도 있습니다. + **복제 상태(dmslogs.awsdms\$1status)** – 이 테이블은 현재 작업에 대한 세부 정보를 제공합니다. 작업 상태, 작업에서 사용하는 메모리 크기, 대상에 아직 적용되지 않은 변경 수 등이 표시됩니다. 또한이 테이블은가 현재 읽 AWS DMS 는 소스 데이터베이스의 위치를 제공합니다. 또한 이것은 작업이 전체 로드 단계이거나 변경 데이터 캡처(CDC)인지 여부를 나타냅니다. + **일시 중지된 테이블(dmslogs.awsdms\$1suspended\$1tables)** – 이 테이블에는 일시 중지된 테이블뿐 아니라 일시 중지된 이유가 나와 있습니다. + **복제 기록(dmslogs.awsdms\$1history)** – 이 테이블은 복제 기록에 관한 정보를 제공합니다. 작업 중에 처리된 레코드의 수와 볼륨, CDC 작업 종료 시 지연 시간, 기타 통계 등이 표시됩니다. 예외 적용 테이블(`dmslogs.awsdms_apply_exceptions`)에는 다음 파라미터가 포함되어 있습니다. | 열 | Type | 설명 | | --- | --- | --- | | TASK\$1NAME | nvchar | AWS DMS 작업의 리소스 ID입니다. 리소스 ID는 태스크 ARN에서 찾을 수 있습니다. | | TABLE\$1OWNER | nvchar | 테이블 소유자입니다. | | TABLE\$1NAME | nvchar | 테이블 이름. | | ERROR\$1TIME | timestamp | 예외(오류)가 발생한 시간입니다. | | STATEMENT | nvchar | 오류가 발생했을 때 실행되고 있었던 문입니다. | | 오류 | nvchar | 오류 이름 및 설명입니다. | 복제 상태 테이블(`dmslogs.awsdms_status`)에는 작업과 대상 데이터베이스의 현재 상태가 포함되어 있습니다. 설정은 다음과 같습니다. | 열 | Type | 설명 | | --- | --- | --- | | 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/ko_kr/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`)에는 다음과 같은 파라미터가 포함되어 있습니다. | 열 | Type | 설명 | | --- | --- | --- | | SERVER\$1NAME | nvchar | 복제 작업이 실행되고 있는 시스템의 이름입니다. | | TASK\$1NAME | nvchar | AWS DMS 작업의 이름입니다. | | TABLE\$1OWNER | nvchar | 테이블 소유자입니다. | | TABLE\$1NAME | nvchar | 테이블 이름. | | SUSPEND\$1REASON | nvchar | 일시 중지 사유. | | SUSPEND\$1TIMESTAMP | timestamp | 일시 중단이 발생한 시간입니다. | 복제 기록 테이블(`dmslogs.awsdms_history`)에는 다음 파라미터가 포함되어 있습니다. | 열 | Type | 설명 | | --- | --- | --- | | 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/ko_kr/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.html) 작업이 전체 로드와 CDC를 실행하고 있는 경우, 두 이력 레코드는 타임 슬롯에 작성됩니다. | | TIMESLOT | timestamp | 시간 슬롯의 종료 타임스탬프입니다. | | TIMESLOT\$1DURATION | int | 시간 슬롯의 지속 시간(분)입니다. | | TIMESLOT\$1LATENCY | int | 시간 슬롯이 끝날 때의 대상 지연 시간(초)입니다. 이 값은 CDC 시간 슬롯에만 적용됩니다. | | RECORDS | int | 시간 슬롯 중에 처리되는 레코드의 수입니다. | | TIMESLOT\$1VOLUME | int | 처리되는 데이터의 볼륨(단위: MB)입니다. | 검증 실패 테이블(`awsdms_validation_failures_v1`)에는 작업에 대한 모든 데이터 검증 실패가 포함되어 있습니다. 자세한 내용은 [데이터 검증 문제 해결](CHAP_Validating.md#CHAP_Validating.Troubleshooting)을 참조하세요. 추가 제어 테이블 설정에는 다음이 포함됩니다. + `HistoryTimeslotInMinutes` – 이 옵션을 사용하여 복제 이력 테이블에서 각 시간 슬롯의 길이를 나타냅니다. 기본값은 5분입니다. + `ControlSchema` - AWS DMS 대상에 대한 제어 테이블의 데이터베이스 스키마 이름을 표시하려면이 옵션을 사용합니다. 이 옵션에 대한 정보를 입력하지 않으면 테이블이 다음과 같이 데이터베이스의 기본 위치로 복사됩니다. + PostgreSQL, 퍼블릭 + Oracle, 대상 스키마 + Microsoft SQL 서버, 대상 데이터베이스에 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` – 이 옵션을 사용하여 각 데이터 스트림 버퍼의 최대 크기를 나타냅니다. 기본 크기는 8MB입니다. 매우 큰 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` – 이 옵션을 사용하여 제어 스트림 버퍼의 크기를 설정합니다. 값의 단위는 메가바이트이고 범위는 1\$18입니다. 기본값은 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`로 설정되면 트랜잭션 무결성이 일시적인 시간 경과가 있어 성능이 개선될 수 있습니다. 원본 트랜잭션의 모든 변경 사항이 단일한 배치(batch)의 대상에 적용된다는 보장은 없습니다. 기본적으로는 트랜잭션 모드에서 변경 사항을 AWS DMS 처리하여 트랜잭션 무결성을 유지합니다. 트랜잭션 무결성이 일시적으로 저하될 여지가 있다면 배치 최적화 적용 옵션을 대신 사용할 수 있습니다. 이 옵션은 효율성을 위해 트랜잭션을 효율적으로 그룹화하고 일괄적으로 적용합니다. 배치 최적화 적용 옵션을 사용하면 거의 항상 참조 무결성 제약 조건을 위반합니다. 따라서 마이그레이션 프로세스 중에 이러한 제약 조건을 해제한 다음, 전환 프로세스의 일부로 다시 설정하는 것이 좋습니다. + `BatchApplyTimeoutMin` - 배치 변경의 각 적용 간에가 AWS DMS 대기하는 최소 시간을 초 단위로 설정합니다. 기본값은 1입니다. + `BatchApplyTimeoutMax` - 시간이 초과되기 전에 배치 변경의 각 적용 간에 AWS DMS 대기하는 최대 시간을 초 단위로 설정합니다. 기본값은 30입니다. + `BatchApplyMemoryLimit` – **배치 최적화 적용 모드**에서 사전 처리를 위해 사용하는 최대 메모리 양(MB)을 설정합니다. 기본값은 500입니다. + `BatchSplitSize` – 단일 배치에서 적용되는 변경 사항의 최대 수를 설정합니다. 기본값이 0이면 적용되는 제한이 없음을 뜻합니다. 다음 설정은 대상 메타데이터 파라미터 `BatchApplyEnabled`가 `false`로 설정되어 있는 경우에만 적용됩니다. + `MinTransactionSize` – 각 트랜잭션에 포함할 변경 사항의 최소 수를 설정합니다. 기본값은 1000입니다. + `CommitTimeout` - 제한 시간을 선언 AWS DMS 하기 전에가 트랜잭션을 배치로 수집하는 최대 시간을 초 단위로 설정합니다. 기본값은 1입니다. 양방향 복제의 경우, 다음 설정은 대상 메타데이터 파라미터 `BatchApplyEnabled`가 `false`로 설정되어 있는 경우에만 적용됩니다. + `LoopbackPreventionSettings` – 이러한 설정은 양방향 복제와 관련된 작업 쌍으로 된 지속적 복제 작업마다 루프백 방지를 제공합니다. *루프백 방지*는 동일한 변경 사항이 양방향 복제의 두 방향 모두에 적용되어 데이터가 손상되는 문제를 방지합니다. 양방향 복제에 관한 자세한 내용은 [양방향 복제 수행](CHAP_Task.CDC.md#CHAP_Task.CDC.Bidirectional) 섹션을 참조하세요. AWS DMS 는 트랜잭션이 소스, 대상 또는 둘 다에 완전히 커밋될 때까지 트랜잭션 데이터를 메모리에 유지하려고 시도합니다. 그렇지만 할당된 메모리보다 크거나 지정된 시간 한도 내에서 커밋되지 않은 트랜잭션은 디스크에 기록됩니다. 다음 설정은 변경 처리 모드에 상관 없이 변경 처리 튜닝에 적용됩니다. + `MemoryLimitTotal` – 디스크에 기록되기 전에 모든 트랜잭션이 메모리에서 점유할 수 있는 최대 크기(MB 단위)를 설정합니다. 기본값은 1,024입니다. + `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` -이 옵션을 로 설정하면 작업 검증의 테이블 부분에 있는 모든 LOB 열에 대한 데이터 검증을 `true` 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` – 원본과 대상 모두에서 비교하기 위해 읽을 레코드의 배치 크기를 지정합니다. 기본값은 10,000입니다. + `ValidationQueryCdcDelaySeconds` – 각 CDC 업데이트에 대해 원본과 대상 모두에서 첫 번째 유효성 검사 쿼리가 지연되는 시간입니다. 이렇게 하면 마이그레이션 지연 시간이 길어질 때 리소스 경합을 줄이는 데 도움이 될 수 있습니다. 검증 전용 작업에서는 이 옵션이 180초로 자동 설정됩니다. 기본값은 0입니다. 예를 들어 다음 JSON은 스레드의 기본 수를 두 배로 늘려 데이터 검증을 활성합니다. 또한 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 데이터 검증](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html) 섹션을 참조하세요. 재동기화 프로세스를 구성하는 `ReplicationTaskSettings` 엔드포인트의 `ResyncSettings`에 대한 추가 파라미터를 추가할 수 있습니다. 자세한 내용은 [AWS Database Migration Service 작업에 대한 작업 설정 지정](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.html)의 [작업 설정 예제](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.html#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)를 참조하세요. **참고** 재동기화 프로세스가 활성화되어 있고 작업에 CDC 구성 요소가 있는 경우 `ResyncSchedule` 및 `MaxResyncTime` 파라미터가 필요합니다. 전체 로드 전용 작업에는 유효하지 않습니다. 데이터 재동기화 파라미터 설정 및 값은 다음과 같습니다. `EnableResync` `true`로 설정하면 데이터 재동기화 기능을 활성화합니다. 기본적으로 데이터 재동기화는 비활성화되어 있습니다. **데이터 형식**: 부울 **필수 항목 여부**: 아니요 **기본값**: `false` **검증**: `TaskSettings`에 `ResyncSettings` 파라미터가 있는 경우 null이 아니어야 합니다. `ResyncSchedule` 데이터 재동기화 기능이 적용되는 기간입니다. Cron 형식으로 표시되어야 합니다. 자세한 내용은 [Cron 표현식 규칙](CHAP_Validating.DataResync.md#CHAP_DataResync.cron) 단원을 참조하십시오. **데이터 형식**: 문자열 **필수 항목 여부**: 아니요 **검증**: + Cron 표현식 형식으로 표시되어야 합니다. + `EnableResync`가 `true`로 설정된 CDC 작업의 경우 null이 아니어야 합니다. + 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진수 표기법으로 유니코드 코드 포인트 값을 사용하여 지정된 문자에 대해 발생합니다. 두 단계 모두 지정된 경우 두 단계를 다음 순서로 사용하여 문자 대체를 구현할 수 있습니다. 1. **개별 문자 대체** - 소스에서 선택한 문자의 값을 대상에서 해당 문자의 지정된 대체 값으로 AWS DMS 바꿀 수 있습니다. `CharacterSetSettings`에서 `CharacterReplacements` 배열을 사용하여 지정한 유니코드 코드 포인트가 있는 모든 소스 문자를 선택합니다. 또한 이 배열을 사용하여 대상의 해당 문자에 대한 대체 코드 포인트를 지정합니다. 지정된 코드 포인트가 있는 소스의 모든 문자를 선택하려면 `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'`로 바꿉니다. 마찬가지로는 대상`'B'`에 있는 문자의 모든 인스턴스를 문자로 바 AWS DMS 꿉니다`'A'`. 1. **문자 세트 검증 및 교체** - 개별 문자 교체가 완료되면 모든 대상 문자에 지정한 단일 문자 세트에 유효한 유니코드 코드 포인트가 있는지 AWS DMS 확인할 수 있습니다. `CharacterSetSettings`에서 `CharacterSetSupport`를 사용하여 이 대상 문자 검증 및 수정을 구성할 수 있습니다. 검증 문자 집합을 지정하려면 `CharacterSetSupport`의 `CharacterSet`를 문자 집합의 문자열 값으로 설정합니다. (`CharacterSet`에 대해 가능한 값은 다음과 같습니다.) 다음 방법 중 하나로 잘못된 대상 문자를 AWS DMS 수정할 수 있습니다. + 현재 코드 포인트에 관계없이 유효하지 않은 모든 대상 문자에 대해 단일 대체 유니코드 코드 포인트를 지정합니다. 이 대체 코드 포인트를 구성하려면 `CharacterSetSupport`의 `ReplaceWithCharacterCodePoint`를 지정된 값으로 설정합니다. + `ReplaceWithCharacterCodePoint`를 0으로 설정하여 유효하지 않은 모든 대상 문자의 삭제를 구성합니다. 예를 들어 `CharacterSetSupport`에 다음과 같은 값을 지정한다고 가정하겠습니다. ``` "CharacterSetSettings": { "CharacterSetSupport": { "CharacterSet": "UTF16_PlatformEndian", "ReplaceWithCharacterCodePoint": 0 } } ``` 이 예제에서는 대상에서 발견된 문자 중 문자 집합에서 유효하지 않은 `"UTF16_PlatformEndian"` 문자를 AWS DMS 삭제합니다. 따라서 16진수 값 `2FB6`으로 지정된 모든 문자가 삭제됩니다. 이 값은 4바이트 유니코드 코드 포인트이고 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/ko_kr/dms/latest/userguide/CHAP_Tasks.CustomizingTasks.TaskSettings.CharacterSubstitution.html) # 이전 이미지 작업 설정 Kinesis 또는 Kafka 같은 데이터 스트리밍 대상에 CDC 업데이트를 작성하는 경우 업데이트를 통한 변경 전에 소스 데이터베이스 행의 원래 값을 볼 수 있습니다. 이를 가능하게 하기 위해는 소스 데이터베이스 엔진에서 제공하는 데이터를 기반으로 업데이트 이벤트의 *이전 이미지를* AWS DMS 채웁니다. 작업 구성 파일을 사용하여 작업 설정을 지정하는 방법에 관한 자세한 내용은 [작업 설정 예제](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example)을 참조하세요. 이를 위해 `BeforeImageSettings` 파라미터를 사용하면 소스 데이터베이스 시스템에서 수집된 값을 사용하여 모든 업데이트 작업에 새 JSON 속성이 추가됩니다. `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 사용 시 이전 이미지 설정에 관한 자세한 내용은 [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 에서 수행하는 작업을 결정합니다. 기본값은 `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 에서 수행하는 작업을 결정합니다. 기본값과 유일한 사용자 설정은 `STOP_TASK`이며 여기에서 작업은 중지되고 수동 개입이 필요합니다. + `TableErrorEscalationCount` – 특정 테이블의 일반 데이터 또는 메타데이터에 발생할 수 있는 오류의 최대 수입니다. 이 수치에 도달하면 테이블의 데이터는 `TableErrorEscalationPolicy`에 설정된 정책에 따라 처리됩니다. 기본값은 0입니다. + `RecoverableErrorCount` – 환경 오류가 발생할 때 작업을 다시 시작하기 위한 시도의 최대 횟수입니다. 시스템이 작업을 지정된 횟수만큼 다시 시작하려고 시도하고 나면, 이 작업은 중지되고 수동 개입이 필요합니다. 기본값은 -1입니다. 이 값을 -1로 설정하면 DMS가 시도하는 재시도 횟수는 다음과 같이 반환된 오류 유형에 따라 달라집니다. + **실행 상태, 복구 가능 오류:** 연결 끊김 또는 대상 적용 실패와 같은 복구 가능 오류가 발생하면 DMS는 태스크를 9회 재시도합니다. + **시작 상태, 복구 가능 오류:** DMS가 태스크를 6회 재시도합니다. + **실행 상태, DMS에서 처리하는 치명적인 오류:** DMS는 태스크를 6회 재시도합니다. + **실행 중 상태, DMS에서 처리하지 않은 치명적인 오류:** DMS는 태스크를 다시 시도하지 않습니다. + **위 이외의 경우**:는 작업을 무기한 AWS DMS 재시도합니다. 이 값을 0으로 설정하면 작업을 다시 시작하기 위한 시도를 하지 않습니다. DMS 태스크가 제대로 복구될 수 있도록 `RecoverableErrorCount` 및 `RecoverableErrorInterval`을 충분한 간격으로 재시도할 수 있는 값으로 설정하는 것이 좋습니다. 치명적인 오류가 발생하면 DMS는 대부분의 시나리오에서 재시작 시도를 중지합니다. + `RecoverableErrorInterval` - AWS DMS가 작업을 다시 시작하려는 시도 사이에 대기하는 초 수입니다. 기본값은 5입니다. + `RecoverableErrorThrottling` – 활성화되면 작업 재시작 시도 간격이 `RecoverableErrorInterval` 값을 기준으로 연속적으로 늘어납니다. 예를 들어 `RecoverableErrorInterval`을 5초로 설정하면 다음 재시도는 10초 후, 20초 후, 40초 후 등등의 시간 경과 후에 다시 시도됩니다. 기본값은 `true`입니다. + `RecoverableErrorThrottlingMax` -가 활성화된 경우 AWS DMS가 작업을 다시 시작하려는 시도 사이에 대기하는 최대 초 `RecoverableErrorThrottling` 수입니다. 기본값은 1800입니다. + `RecoverableErrorStopRetryAfterThrottlingMax`- 기본값은 로 설정되며 `true`DMS는에 따라 복구 시도 사이에 AWS DMS 대기하는 최대 초 수에 도달한 후 작업 재개를 중지합니다`RecoverableErrorStopRetryAfterThrottlingMax`. 로 설정하면 `false`DMS는 복구 시도 사이에 AWS DMS 대기하는 최대 초 수에 도달한 후에 도달할 `RecoverableErrorStopRetryAfterThrottlingMax` 때까지에 따라 작업을 계속 재개`RecoverableErrorCount`합니다. + `ApplyErrorDeletePolicy` – DELETE 작업과 충돌이 있을 때 AWS 에서 수행하는 작업을 결정합니다. 기본값은 `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` - 최대 오류 수( `ApplyErrorEscalationCount` 파라미터를 사용하여 설정)에 도달할 때 AWS DMS가 수행하는 작업을 결정합니다. 기본값은 LOG\$1ERROR입니다. + `LOG_ERROR` – 작업은 계속되고 오류가 작업 로그에 기록됩니다. + `SUSPEND_TABLE` – 작업은 계속되지만 오류 레코드가 있는 테이블의 데이터는 오류 상태로 이동하고 데이터가 복제되지 않습니다. + `STOP_TASK` – 작업은 중지되고 수동 개입이 필요합니다. + `ApplyErrorEscalationCount` – 이 옵션은 변경 프로세스 작업 중에 특정 테이블에서 발생할 수 있는 최대 APPLY 충돌 개수를 설정합니다. 이 개수에 도달하면 테이블 데이터는 `ApplyErrorEscalationPolicy` 파라미터에 설정된 정책에 따라 처리됩니다. 기본값은 0입니다. + `ApplyErrorFailOnTruncationDdl` – CDC 중에 추적되는 테이블에 대해 잘림이 수행될 때 작업이 실패하도록 하려면 이 옵션을 `true`로 설정합니다. 기본값은 `false`입니다. 이 방법은 DDL 테이블 잘림을 복제하지 않는 PostgreSQL 버전 11.x나 이전 버전 또는 다른 소스 엔드포인트에서는 사용할 수 없습니다. + `FailOnNoTablesCaptured` – 작업이 시작될 때 작업에 대해 정의된 테이블 매핑이 테이블을 찾지 못하는 경우 작업이 실패하도록 하려면 이 옵션을 `true`로 설정합니다. 기본값은 `true`입니다. + `FailOnTransactionConsistencyBreached` – 이 옵션은 CDC와 함께 사용하기 위한 원본으로 Oracle을 사용하는 작업에 적용됩니다. 기본값은 false입니다. 트랜잭션이 지정된 제한 시간보다 더 오랫동안 열려 있고 삭제될 수 있는 경우 작업이 실패하도록 하려면 `true`로 설정합니다. CDC 작업이 Oracle로 시작되면는 CDC를 시작하기 전에 가장 오래된 열린 트랜잭션이 종료될 때까지 제한된 시간 동안 AWS DMS 기다립니다. 가장 오래된 열린 트랜잭션이 제한 시간에 도달할 때까지 닫히지 않으면 대부분의 경우는 해당 트랜잭션을 무시하고 CDC를 AWS DMS 시작합니다. 이 옵션을 `true`로 설정하면 작업이 실패합니다. + `FullLoadIgnoreConflicts` - 캐시된 이벤트를 적용할 때 "영향을 받는 행 0" 및 "중복" 오류를 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 파일에 복사할 작업 설정을 찾을 수 있습니다. **참고** 작업 설정을 다른 작업에 재사용하는 동안에는 모든 `CloudWatchLogGroup` 및 `CloudWatchLogStream` 속성을 제거하세요. 그렇지 않으면 다음 오류가 발생합니다. 시스템 오류 메시지: 작업 설정 생성 시 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 } ```