기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다. # AWS DMS 데이터 검증 **Topics** + [복제 작업 통계](#CHAP_Validating.TaskStatistics) + [Amazon CloudWatch를 사용한 복제 태스크 통계](#CHAP_Validating.TaskStatistics.CloudWatch) + [작업 중 테이블 다시 검증](#CHAP_Validating.Revalidating) + [JSON 편집기를 사용하여 검증 규칙 수정](#CHAP_Validating.JSONEditor) + [검증 전용 태스크](#CHAP_Validating.ValidationOnly) + [문제 해결](#CHAP_Validating.Troubleshooting) + [Redshift 검증 성능](#CHAP_Validating.Redshift) + [에 대한 향상된 데이터 검증 AWS Database Migration Service](#CHAP_Validating_Enhanced) + [제한 사항](#CHAP_Validating.Limitations) + [Amazon S3 대상 데이터 검증](CHAP_Validating_S3.md) + [AWS DMS 데이터 재동기화](CHAP_Validating.DataResync.md) AWS DMS 는 데이터가 소스에서 대상으로 정확하게 마이그레이션되었는지 확인하기 위해 데이터 검증을 지원합니다. 활성화된 경우 테이블에 대해 전체 로드가 수행된 직후 검증이 시작됩니다. 검증은 CDC 지원 태스크에 대해 증분 변경 사항이 발생할 경우 이러한 변경 사항을 비교합니다. 데이터 검증 중에는 소스의 각 행을 대상의 해당 행과 AWS DMS 비교하고, 행에 동일한 데이터가 포함되어 있는지 확인하고, 불일치를 보고합니다. 이를 위해 AWS DMS 적절한 쿼리를 실행하여 데이터를 검색합니다. 이러한 쿼리는 소스 및 대상의 추가 리소스와 추가 네트워크 리소스를 사용합니다. 검증이 활성화된 CDC 전용 태스크의 경우, 새 데이터의 검증을 시작하기 전에 테이블에 있는 기존 데이터를 모두 검증합니다. 데이터 검증은가 소스 엔드포인트로 AWS DMS 지원하는 모든 곳에서 다음 소스 데이터베이스와 함께 작동합니다. + Oracle + PostgreSQL 호환 데이터베이스(PostgreSQL, Aurora PostgreSQL 또는 Aurora Serverless for PostgreSQL) + MySQL 호환 데이터베이스(MySQL, MariaDB, Aurora MySQL 또는 Aurora Serverless for MySQL) + Microsoft SQL Server + IBM DB2 LUW 데이터 검증은가 대상 엔드포인트로 AWS DMS 지원하는 모든 곳에서 다음 대상 데이터베이스와 함께 작동합니다. + Oracle + PostgreSQL 호환 데이터베이스(PostgreSQL, Aurora PostgreSQL 또는 Aurora Serverless for PostgreSQL) + MySQL 호환 데이터베이스(MySQL, MariaDB, Aurora MySQL 또는 Aurora Serverless for MySQL) + Microsoft SQL Server + IBM DB2 LUW + Amazon Redshift + Amazon S3. Amazon S3 대상 데이터 유효성 검사에 대한 자세한 내용은 [Amazon S3 대상 데이터 검증](CHAP_Validating_S3.md) 섹션을 참조하세요. 지원되는 엔드포인트에 대한 자세한 내용은 [AWS DMS 엔드포인트 작업](CHAP_Endpoints.md) 섹션을 참조하세요. 데이터 검증에는 마이그레이션 자체에 소요되는 시간 외에도 추가 시간이 요구됩니다. 필요한 추가 시간은 마이그레이션되는 데이터의 양에 따라 달라집니다. 이러한 설정에 대한 자세한 내용은 [데이터 검증 작업 설정](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md) 섹션을 참조하세요. JSON 파일의 `ValidationSettings` 태스크 설정에 대한 예제는 [작업 설정 예제](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example) 섹션을 참조하세요. ## 복제 작업 통계 데이터 검증이 활성화되면는 테이블 수준에서 다음 통계를 AWS DMS 제공합니다. + **ValidationState** - 테이블의 검증 상태입니다. 이 파라미터의 값은 다음과 같습니다. + **활성화되지 않음** - 마이그레이션 작업의 테이블에 대해 검증이 활성화되지 않습니다. + **보류 중인 레코드** - 테이블의 일부 레코드가 검증 대기 중입니다. + **일치하지 않는 레코드** - 테이블의 일부 레코드가 원본과 대상 간에 일치하지 않습니다. 불일치가 발생하는 이유에는 여러 가지가 있으므로 자세한 내용은 대상 엔드포인트의 `awsdms_control.awsdms_validation_failures_v1` 테이블을 참조하세요. + **일시 중지된 레코드** - 테이블의 일부 레코드를 검증할 수 없습니다. + **프라이머리 키 없음** - 프라이머리 키가 없어 테이블을 검증할 수 없습니다. + **테이블 오류** - 테이블이 오류 상태이고 일부 데이터가 마이그레이션되지 않아 테이블이 검증되지 않았습니다. + **검증됨** - 테이블의 모든 행이 검증되었습니다. 테이블이 업데이트된 경우 상태가 Validated에서 변경할 수 있습니다. + **오류** - 예상치 못한 오류로 인해 테이블을 검증할 수 없습니다. + **검증 보류 중** - 테이블이 검증 대기 중입니다. + **테이블 준비 중** - 마이그레이션 태스크에서 활성화된 테이블을 검증하기 위해 준비 중입니다. + **재검증 보류 중** - 테이블이 업데이트된 후 테이블의 모든 행이 검증 보류 중입니다. + **ValidationPending** - 대상에 마이그레이션되었지만 아직 검증되지 않은 레코드 수입니다. + **ValidationSuspended** - 비교할 AWS DMS 수 없는 레코드 수입니다. 예를 들어 소스의 레코드가 지속적으로 업데이트되는 경우는 소스와 대상을 비교할 AWS DMS 수 없습니다. + **ValidationFailed** - 데이터 검증 단계를 통과하지 않은 레코드 수입니다. JSON 파일의 `ValidationSettings` 태스크 설정에 대한 예제는 [작업 설정 예제](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example) 섹션을 참조하세요. 콘솔, AWS CLI또는 AWS DMS API를 사용하여 데이터 검증 정보를 볼 수 있습니다. + 콘솔에서 작업을 생성하거나 수정할 때 작업을 검증하도록 선택할 수 있습니다. 콘솔을 사용하여 데이터 검증 보고서를 보려면 **작업** 페이지에서 작업을 선택하고 세부 정보 섹션에서 **테이블 통계** 탭을 선택합니다. + 데이터 검증을 시작하도록 작업을 생성하거나 수정하려는 경우 CLI를 사용하여 `EnableValidation` 파라미터를 `true`로 설정합니다. 다음 예제에서는 작업을 생성하고 데이터 검증을 활성화합니다. ``` create-replication-task --replication-task-settings '{"ValidationSettings":{"EnableValidation":true}}' --replication-instance-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q --source-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CSZAEFQURFYMM --target-endpoint-arn arn:aws:dms:us-east-1:5731014: endpoint:CGPP7MF6WT4JQ --migration-type full-load-and-cdc --table-mappings '{"rules": [{"rule-type": "selection", "rule-id": "1", "rule-name": "1", "object-locator": {"schema-name": "data_types", "table-name": "%"}, "rule-action": "include"}]}' ``` `describe-table-statistics` 명령을 사용하여 JSON 형식의 데이터 검증 보고서를 받습니다. 다음 명령은 데이터 검증 보고서를 표시합니다. ``` aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:5731014: rep:36KWVMB7Q ``` 이 보고서는 다음과 비슷합니다. ``` { "ReplicationTaskArn": "arn:aws:dms:us-west-2:5731014:task:VFPFTYKK2RYSI", "TableStatistics": [ { "ValidationPendingRecords": 2, "Inserts": 25, "ValidationState": "Pending records", "ValidationSuspendedRecords": 0, "LastUpdateTime": 1510181065.349, "FullLoadErrorRows": 0, "FullLoadCondtnlChkFailedRows": 0, "Ddls": 0, "TableName": "t_binary", "ValidationFailedRecords": 0, "Updates": 0, "FullLoadRows": 10, "TableState": "Table completed", "SchemaName": "d_types_s_sqlserver", "Deletes": 0 } } ``` + AWS DMS API를 사용하여 **CreateReplicationTask** 작업을 사용하여 작업을 생성하고 `EnableValidation` 파라미터를 **true**로 설정하여 작업에 의해 마이그레이션된 데이터를 검증합니다. **DescribeTableStatistics** 작업을 사용하여 JSON 형식의 데이터 검증 보고서를 받습니다. ## Amazon CloudWatch를 사용한 복제 태스크 통계 Amazon CloudWatch가 활성화되면는 다음과 같은 복제 작업 통계를 AWS DMS 제공합니다. + **ValidationSucceededRecordCount** - 분당 AWS DMS 검증한 행 수입니다. + **ValidationAttemptedRecordCount** - 검증을 시도한 분당 행 수입니다. + **ValidationFailedOverallCount** - 검증이 실패한 행 수입니다. + **ValidationSuspendedOverallCount** - 검증이 일시 중지된 행 수입니다. + **ValidationPendingOverallCount** - 검증이 보류 중인 행 수입니다. + **ValidationBulkQuerySourceLatency** - AWS DMS 는 변경 사항이 많을 경우, 전체 복제 또는 지속적 복제 동안 특정 시나리오를 중심으로 일괄적으로 데이터를 검증할 수 있습니다. 이 지표는 소스 엔드포인트 대량의 데이터세트를 읽는 데 필요한 지연 시간을 나타냅니다. + **ValidationBulkQueryTargetLatency** - AWS DMS 는 변경 사항이 많을 경우, 전체 복제 또는 지속적 복제 동안 특정 시나리오를 중심으로 일괄적으로 데이터를 검증할 수 있습니다. 이 지표는 대상 엔드포인트의 대량의 데이터세트를 읽는 데 필요한 지연 시간을 나타냅니다. + **ValidationItemQuerySourceLatency** - 지속적 복제 동안 데이터 검증은 지속적 변경 사항을 식별하고 이러한 변경 사항을 검증합니다. 이 지표는 소스에서 이런 변경을 읽는 데 필요한 지연 시간을 나타냅니다. 검증은 변경의 수를 근거로, 검증 동안 오류가 있을 시 필요한 것보다 더 많은 쿼리를 실행할 수 있습니다. + **ValidationItemQueryTargetLatency** - 지속적 복제 동안 데이터 검증은 지속적 변경 사항을 식별하고 행 단위로 변경 사항을 검증할 수 있습니다. 이 지표는 대상에서 이런 변경을 읽는 데 필요한 지연 시간을 제공합니다. 검증은 변경의 수를 근거로, 검증 동안 오류가 있을 시 필요한 것보다 더 많은 쿼리를 실행할 수도 있습니다. CloudWatch를 사용한 통계에서 데이터 검증 정보를 수집하려면 콘솔을 사용하여 태스크를 생성하거나 수정할 때 **CloudWatch 로그 활성화**를 선택합니다. 그런 다음, 데이터가 소스에서 대상으로 정확히 마이그레이션되었는지 확인하기 위한 데이터 검증 정보를 확인하려면 다음 작업을 수행합니다. 1. **데이터베이스 마이그레이션 태스크** 페이지에서 태스크를 선택합니다. 1. **CloudWatch 지표** 탭을 선택합니다. 1. 드롭다운 메뉴에서 **검증**을 선택합니다. ## 작업 중 테이블 다시 검증 작업이 실행되는 동안 AWS DMS 에 데이터 검증 수행을 요청할 수 있습니다. ### AWS Management Console 1. 에 로그인 AWS Management Console 하고 [https://console.aws.amazon.com/dms/v2/](https://console.aws.amazon.com/dms/v2/) AWS DMS 콘솔을 엽니다. AWS Identity and Access Management (IAM) 사용자로 로그인한 경우 액세스할 수 있는 적절한 권한이 있는지 확인합니다 AWS DMS. 필요한 권한은 섹션을 참조하세요[를 사용하는 데 필요한 IAM 권한 AWS DMS](security-iam.md#CHAP_Security.IAMPermissions). 1. 탐색 창에서 **작업**을 선택합니다. 1. 다시 검증할 테이블이 있는 실행 중인 작업을 선택합니다. 1. **테이블 통계** 탭을 선택합니다. 1. 다시 검증할 테이블을 선택합니다(한 번에 최대 10개의 테이블을 선택할 수 있음). 작업이 더 이상 실행되고 있지 않으면 테이블을 다시 검증할 수 없습니다. 1. **다시 검증**을 선택합니다. ## JSON 편집기를 사용하여 검증 규칙 수정 AWS DMS 콘솔의 JSON 편집기를 사용하여 작업에 검증 규칙을 추가하려면 다음을 수행합니다. 1. **데이터베이스 마이그레이션 태스크**를 선택합니다. 1. 마이그레이션 태스크 목록에서 태스크를 선택합니다. 1. 태스크가 실행 중인 경우 **작업** 드롭다운 메뉴에서 **중지**를 선택합니다. 1. 태스크가 중지된 후 태스크를 수정하려면 **작업** 드롭다운 메뉴에서 **수정**을 선택합니다. 1. **테이블 매핑** 섹션에서 **JSON 편집기**를 선택하고 테이블 매핑에 검증 규칙을 추가합니다. 예를 들어, 다음과 같은 검증 규칙을 추가하여 소스에서 replace 함수를 실행할 수 있습니다. 이 경우 검증 규칙에서 null 바이트가 발견되면 해당 바이트는 공백으로 확인됩니다. ``` { "rule-type": "validation", "rule-id": "1", "rule-name": "1", "rule-target": "column", "object-locator": { "schema-name": "Test-Schema", "table-name": "Test-Table", "column-name": "Test-Column" }, "rule-action": "override-validation-function", "source-function": "REPLACE(${column-name}, chr(0), chr(32))", "target-function": "${column-name}" } ``` **참고** `override-validation-function`은 열이 프라이머리 키의 일부인 경우 적용되지 않습니다. ## 검증 전용 태스크 마이그레이션이나 데이터 복제를 수행하지 않고도 데이터를 미리 보고 검증하는 검증 전용 태스크를 생성할 수 있습니다. 검증 전용 태스크를 생성하려면 `EnableValidation` 및 `ValidationOnly` 설정을 `true`로 설정합니다. `ValidationOnly`를 활성화하면 추가 요구 사항이 적용됩니다. 자세한 내용은 [데이터 검증 작업 설정](CHAP_Tasks.CustomizingTasks.TaskSettings.DataValidation.md) 단원을 참조하십시오. 전체 로드 전용 마이그레이션 유형의 경우, 실패가 많이 보고되면 검증 전용 태스크가 CDC 태스크보다 훨씬 더 빨리 완료됩니다. 그러나 소스 또는 대상 엔드포인트에 대한 변경 사항은 전체 로드 모드에서 실패로 보고되며, 이는 단점이 될 수 있습니다. CDC 검증 전용 태스크는 평균 지연 시간을 기준으로 검증을 지연시키며, 실패를 보고하기 전에 여러 번 재시도합니다. 대부분의 데이터 비교 결과가 실패로 이어질 경우, CDC 모드의 검증 전용 태스크는 속도가 매우 느리며, 이는 단점이 될 수 있습니다. 검증 전용 작업은 복제 작업와 같은 방향으로 설정해야 하며, 특히 CDC의 경우에는 더욱 그렇습니다. CDC 검증 전용 태스크는 소스의 변경 로그를 기준으로, 어떤 행이 변경되었고 재검증해야 하는지 감지하기 때문입니다. 대상이 소스로 지정된 경우, DMS에서 대상으로 전송한 변경 사항만 인식하며 복제 오류를 포착하지 못할 수 있습니다. ### 전체 로드 검증 전용 AWS DMS 버전 3.4.6 이상부터 전체 로드 검증 전용 작업은 소스 및 대상 테이블의 모든 행을 한 번의 패스로 빠르게 비교하고 즉시 오류를 보고한 다음 종료합니다. 이 모드에서는 실패로 인해 검증이 일시 중지되지 않으며, 속도에 최적화되어 있습니다. 그러나 소스 또는 대상 엔드포인트에 대한 변경 사항은 실패로 보고됩니다. **참고** AWS DMS 버전 3.4.6 이상부터이 검증 동작은 검증이 활성화된 전체 로드 마이그레이션 작업에도 적용됩니다. ### CDC 검증 전용 CDC 검증 전용 태스크는 새로 시작할 때 소스 테이블과 대상 테이블 사이에 있는 모든 기존 행을 검증합니다. 또한 CDC 검증 전용 태스크는 지속적으로 실행되며, 지속적 복제의 변경 사항을 재검증하고, 각 패스에서 보고된 실패 횟수를 제한하고, 불일치 행이 실패하기 전에 다시 시도합니다. 이는 거짓 긍정을 방지하도록 최적화되었습니다. ` FailureMaxCount` 또는 `TableFailureMaxCount` 임계값을 위반하면 테이블(또는 전체 태스크)에 대한 검증이 일시 중지됩니다. 이는 검증이 활성화된 CDC 또는 전체 로드\$1CDC 마이그레이션 태스크에도 적용됩니다. 그리고 검증이 활성화된 CDC 태스크는 평균 소스 및 대상 지연 시간을 기준으로 변경된 각 행에 대한 재검증을 지연시킵니다. 하지만 CDC *검증 전용 태스크*는 데이터를 마이그레이션하지 않으며 지연 시간도 발생하지 않습니다. 기본적으로 `ValidationQueryCdcDelaySeconds`는 180으로 설정됩니다. 그리고 지연 시간이 긴 환경을 고려하여 용량을 늘리고 거짓 긍정을 방지할 수 있습니다. ### 검증 전용 사용 사례 마이그레이션 또는 복제 태스크의 데이터 검증 부분을 별도의 *검증 전용 태스크*로 분할하는 사용 사례에는 다음 경우가 포함되나, 이에 국한되지 않습니다. + *검증이 수행되는 시기를 정확하게 제어* - 검증 쿼리는 소스 및 대상 엔드포인트 양쪽 모두에 추가적인 부하를 가중시킵니다. 따라서 먼저 한 태스크에서 데이터를 마이그레이션 또는 복제한 다음, 다른 태스크에서 결과를 검증하는 편이 유리할 수 있습니다. + *복제 인스턴스의 부하 감소* - 데이터 검증을 분할하여 자체 인스턴스에서 실행하는 편이 유리할 수 있습니다. + *특정 시점에 일치하지 않는 행의 수를 신속하게 파악* - 예를 들어, 유지 관리 기간 직전에 또는 도중에 프로덕션이 대상 엔드포인트로 전환될 경우 전체 로드 검증 전용 태스크를 생성하여 질문에 대한 답을 얻을 수 있습니다. + *CDC 구성 요소를 사용한 마이그레이션 태스크에서 검증 실패가 예상될 경우* - 예를 들어, Oracle `varchar2`를 PostgreSQL `jsonb`으로 마이그레이션할 경우 CDC 검증은 이러한 실패한 행을 계속 재시도하고 매번 보고되는 실패 횟수를 제한합니다. 하지만 전체 로드 검증 전용 태스크를 생성하면 더 빠른 답을 얻을 수 있습니다. + *검증 실패 테이블을 읽는 데이터 복구 스크립트/유틸리티를 개발한 경우* - ([문제 해결](#CHAP_Validating.Troubleshooting)도 참조하세요). 전체 로드 검증 태스크는 데이터 복구 스크립트가 조치를 취해야 할 오류를 신속하게 보고합니다. JSON 파일의 `ValidationSettings` 태스크 설정에 대한 예제는 [작업 설정 예제](CHAP_Tasks.CustomizingTasks.TaskSettings.md#CHAP_Tasks.CustomizingTasks.TaskSettings.Example) 섹션을 참조하세요. ## 문제 해결 검증 중에는 대상 엔드포인트에서 새 테이블을 AWS DMS 생성합니다`awsdms_control.awsdms_validation_failures_v1`. 어떤 레코드가 *ValidationSuspended* 또는 *ValidationFailed* 상태가 되면는 진단 정보를에 AWS DMS 기록합니다`awsdms_control.awsdms_validation_failures_v1`. 이 테이블을 쿼리하여 검증 오류 문제를 해결할 수 있습니다. 대상에서 테이블이 생성되는 기본 스키마를 변경하는 방법에 대한 내용은 [제어 테이블 태스크 설정](CHAP_Tasks.CustomizingTasks.TaskSettings.ControlTable.md) 섹션을 참조하세요. 다음은 `awsdms_control.awsdms_validation_failures_v1` 테이블에 대한 설명입니다. | 열 이름 | 데이터 유형 | 설명 | | --- | --- | --- | | `TASK_NAME` | `VARCHAR(128) NOT NULL` | AWS DMS 작업 식별자입니다. | | TABLE\$1OWNER | VARCHAR(128) NOT NULL | 테이블의 스키마(소유자). | | `TABLE_NAME` | VARCHAR(128) NOT NULL | 테이블 이름. | | FAILURE\$1TIME | DATETIME(3) NOT NULL | 실패가 발생한 시간. | | KEY\$1TYPE | VARCHAR(128) NOT NULL | 나중에 사용할 수 있도록 예약됩니다(값은 항상 'Row'). | | KEY | TEXT NOT NULL | 이 키는 행 레코드 유형의 프라이머리 키입니다. | | FAILURE\$1TYPE | VARCHAR(128) NOT NULL | 검증 오류의 심각도. `RECORD_DIFF`, `MISSING_SOURCE`, `MISSING_TARGET` 또는 `TABLE_WARNING`입니다. | | DETAILS | VARCHAR(8000) NOT NULL | 지정된 키와 일치하지 않는 모든 소스/대상 열 값의 JSON 형식 문자열입니다. | 다음은 `awsdms_control.awsdms_validation_failures_v1` 테이블을 쿼리하여 태스크에 대한 모든 실패를 표시하는 MySQL 대상에 대한 샘플 쿼리입니다. 스키마 이름과 쿼리 구문은 대상 엔진 버전마다 다릅니다. 작업 이름은 작업의 외부 리소스 ID여야 합니다. 작업의 외부 리소스 ID는 작업 ARN의 마지막 값입니다. 예를 들어, ARN 값이 arn:aws:dms:us-west-2:5599:task: VFPFKH4FJR3FTYKK2RYSI인 작업의 경우, 작업의 외부 리소스 ID는 VFPFKH4FJR3FTYKK2RYSI입니다. ``` select * from awsdms_validation_failures_v1 where TASK_NAME = 'VFPFKH4FJR3FTYKK2RYSI' TASK_NAME VFPFKH4FJR3FTYKK2RYSI TABLE_OWNER DB2PERF TABLE_NAME PERFTEST FAILURE_TIME 2020-06-11 21:58:44 KEY_TYPE Row KEY {"key": ["3451491"]} FAILURE_TYPE RECORD_DIFF DETAILS [[{'MYREAL': '+1.10106036e-01'}, {'MYREAL': '+1.10106044e-01'}],] ``` `DETAILS` 필드를 보고 일치하지 않는 열을 확인할 수 있습니다. 실패한 레코드의 프라이머리 키가 있으므로, 소스 및 대상 엔드포인트를 쿼리하여 레코드에서 일치하지 않는 부분을 찾아낼 수 있습니다. ### `awsdms_validation_failures_v2` 제어 테이블 검증 중에 AWS DMS 버전 3.6.1 이상에서 DMS는 PostgreSQL 대상 엔드포인트에 새 테이블을 생성합니다`awsdms_validation_failures_v2`. 이 테이블은 데이터 검증이 활성화된 모든 DMS 작업에 대한 실패로 구성됩니다. `awsdms_validation_failures_v2` 테이블이 생성되면 검증 및 재동기화가 활성화된 모든 작업에 오류가 발생할 수 있으므로 테이블을 삭제하거나 자르면 안 됩니다. `awsdms_validation_failures_v2` 테이블에는 자동 증분 프라이머리 키 기능이 있습니다. 이 테이블은 데이터 재동기화 기능을 지원하는 새 열로 구성됩니다. 스크립트는 다음과 같습니다. `RESYNC_RESULT` **값**: `SUCCESS` 또는 `FAILURE`. **`RESYNC_TIME`** 밀리초 정밀도의 타임스탬프입니다. 이 실패에 대해 데이터 재동기화를 시도하지 않는 경우 기본값은 `NULL`입니다. **`RESYNC_ACTION`** **값**: `UPSERT` 또는 `DELETE`. `RESYNC_ID` 자동 증분이 활성화된 프라이머리 키 열입니다. `awsdms_validation_failures_v2` 테이블에서 인덱스가 `TASK_NAME`, `TABLE_OWNER`, `TABLE_NAME`, `FAILURE_TYPE`, 및 `FAILURE_TIME` 열에 추가되어 대상 데이터베이스의 지정된 테이블에 대한 실패를 효율적으로 읽습니다. 다음은 `awsdms_validation_failures_v2` 테이블을 생성하기 위한 생성 문 예제입니다. ``` CREATE TABLE public.awsdms_validation_failures_v2 ( "RESYNC_ID" int8 GENERATED BY DEFAULT AS IDENTITY( INCREMENT BY 1 MINVALUE 1 MAXVALUE 9223372036854775807 START 1 CACHE 1 NO CYCLE) NOT NULL, "TASK_NAME" varchar(128) NOT NULL, "TABLE_OWNER" varchar(128) NOT NULL, "TABLE_NAME" varchar(128) NOT NULL, "FAILURE_TIME" timestamp NOT NULL, "KEY_TYPE" varchar(128) NOT NULL, "KEY" varchar(7800) NOT NULL, "FAILURE_TYPE" varchar(128) NOT NULL, "DETAILS" varchar(7000) NOT NULL, "RESYNC_RESULT" varchar(128) NULL, "RESYNC_TIME" timestamp NULL, "RESYNC_ACTION" varchar(128) NULL, CONSTRAINT awsdms_validation_failures_v2_pkey PRIMARY KEY ("RESYNC_ID") ); ``` ## Redshift 검증 성능 Amazon Redshift는 열 기반 스토리지, MPP, 데이터 압축 및 기타 요소 등 여러 가지 면에서 관계형 데이터베이스와 다릅니다. 이러한 차이로 인해 Redshift는 관계형 데이터베이스와는 다른 성능 프로파일을 제공합니다. 전체 로드 복제 단계 중 검증에서는 `PartitionSize` 설정에 따라 데이터 크기가 제어되는 범위 쿼리를 사용합니다. 이러한 범위 기반 쿼리에서는 소스 테이블의 모든 레코드가 선택됩니다. 지속적인 복제의 경우 쿼리는 범위 기반과 개별 레코드 가져오기 간에 전환됩니다. 쿼리 유형은 다음과 같은 여러 요인에 따라 동적으로 결정됩니다. + 쿼리 볼륨 + 소스 테이블의 DML 쿼리 유형 + 작업 지연 시간 + 총 레코드 수 + `PartitionSize` 등의 검증 설정 검증 쿼리로 인해 Amazon Redshift 클러스터에 추가 로드가 발생할 수 있습니다. 위의 요인은 사용 사례에 따라 다르므로 검증 쿼리 성능을 검토하고 그에 따라 클러스터와 테이블을 조정해야 합니다. 성능 문제를 완화하기 위한 몇 가지 옵션은 다음과 같습니다. + `PartitionSize` 및 `ThreadCount` 설정을 줄이면 전체 로드 검증 중에 워크로드를 줄이는 데 도움이 됩니다. 이렇게 하면 데이터 검증 속도가 느려진다는 점에 유의하세요. + Redshift는 기본 키를 적용하지 않지만 AWS DMS 는 기본 키를 사용하여 데이터 검증을 위해 대상의 레코드를 고유하게 식별합니다. 전체 로드 검증 쿼리가 더 빠르게 실행되기 위해 가능하면 프라이머리 키가 정렬 키를 미러링하도록 설정합니다. ## 에 대한 향상된 데이터 검증 AWS Database Migration Service AWS Database Migration Service 는 데이터베이스 마이그레이션을 위한 데이터 검증 성능을 개선하여 고객이 처리 시간이 훨씬 빨라진 대규모 데이터 세트를 검증할 수 있도록 합니다. 이제 CDC 마이그레이션 작업을 통한 전체 로드 및 전체 로드 모두에 대해 복제 엔진 버전 3.5.4에서이 향상된 데이터 검증을 사용할 수 있습니다. 현재이 개선 사항은 Oracle에서 PostgreSQL로, SQL Server에서 PostgreSQL로, Oracle에서 Oracle로, SQL Server에서 SQL Server로의 마이그레이션 경로를 지원하며 향후 릴리스에 추가 마이그레이션 경로가 계획되어 있습니다. ### 사전 조건 + *Oracle:* Oracle 엔드포인트에 액세스하는 `SYS.DBMS_CRYPTO` 사용자 계정에 대한 `EXECUTE` 권한을 부여합니다. ``` GRANT EXECUTE ON SYS.DBMS_CRYPTO TO dms_endpoint_user; ``` + PostgreSQL 데이터베이스에 `pgcrypto` 확장 프로그램을 생성합니다. 자체 관리형 PostgreSQL 인스턴스의 경우 `contrib` 모듈 라이브러리를 설치하고 확장을 생성해야 합니다. + `contrib` 모듈 라이브러리를 설치합니다. 예를 들어 Amazon Linux 및 PostgreSQL 15가 있는 Amazon EC2 인스턴스의 경우: ``` sudo dnf install postgresql15-contrib ``` + `pgcrypto` 확장 기능을 생성합니다. ``` CREATE EXTENSION IF NOT EXISTS pgcrypto; ``` + Amazon RDS for PostgreSQL 인스턴스의 경우 AWS DMS 엔드포인트에 대한 SSL 모드를 구성합니다. + 기본적으로 Amazon RDS는 SSL 연결을 강제로 실행합니다. Amazon RDS for PostgreSQL 인스턴스에 대한 AWS DMS 엔드포인트를 생성할 때 "SSL 모드" 옵션 = "필수"를 사용합니다. + "SSL 모드" 옵션 = "없음"을 사용하려면 RDS `rds.force_ssl` 파라미터 그룹에서 파라미터를 0으로 설정합니다. + PostgreSQL 12 및 13의 경우 `BIT_XOR` 집계를 생성합니다. ``` CREATE OR REPLACE AGGREGATE BIT_XOR(IN v bit) (SFUNC = bitxor, STYPE = bit); ``` ### 향상된 데이터 검증 제한 사항 이 향상된 데이터 검증 기능에는 다음과 같은 제한 사항이 있습니다. + 데이터베이스 엔드포인트 요구 사항:이 개선 사항은 다음 기준을 충족하는 데이터베이스 엔드포인트에서만 활성화됩니다. + AWS Secrets Manager 를 사용하여 자격 증명을 저장합니다. + Microsoft SQL Server의 경우 Kerberos 인증도 지원됩니다. + 데이터베이스 버전 지원: + PostgreSQL 12 이상 + Oracle 12.1 이상 + 2019년 이전의 Microsoft SQL Server 버전에서는 NCHAR 및 NVARCHAR 데이터 형식의 검증이 지원되지 않습니다. ## 제한 사항 + 데이터를 검증하려면 테이블에 프라이머리 키나 고유한 인덱스가 있어야 합니다. + 프라이머리 키 열은 `CLOB`, `BLOB`, `BINARY` 또는 `BYTE` 형식이 아니어야 합니다. + `VARCHAR` 또는 `CHAR` 형식의 프라이머리 키 열은 길이가 1024보다 작아야 합니다. 데이터 유형에 길이를 지정해야 합니다. 무제한 데이터 유형을 데이터 검증의 프라이머리 키로 사용할 수 없습니다. + `NOVALIDATE` 절을 사용하여 생성된 Oracle 키는 프라이머리 키 또는 고유 인덱스로 간주되지 *않습니다*. + 프라이머리 키가 없고 고유 키만 있는 Oracle 테이블의 경우에는 고유 제약 조건이 있는 열에도 `NOT NULL` 제약 조건이 있어야 합니다. + NULL PK/UK 값의 검증은 지원되지 않습니다. + 대상 PostgreSQL 인스턴스의 프라이머리 키 열의 콜레이션이 "C"로 설정되어 있지 않으면 프라이머리 키의 정렬 순서가 Oracle의 정렬 순서와 달라집니다. PostgreSQL과 Oracle의 정렬 순서가 다르면 데이터 검증을 통해 레코드를 검증할 수 없습니다. + 데이터 검증을 수행하면 원본 및 대상 데이터베이스에 대해 추가 쿼리가 생성됩니다. 두 데이터베이스에 이 추가 로드를 처리할 수 있을 만큼 충분한 리소스가 확보되었는지 확인해야 합니다. Redshift 대상의 경우 특히 그렇습니다. 자세한 내용은 [Redshift 검증 성능](#CHAP_Validating.Redshift) 섹션을 참조하세요. + 여러 데이터베이스를 하나로 통합할 때는 데이터 검증이 지원되지 않습니다. + 소스 또는 대상 Oracle 엔드포인트의 경우를 AWS DMS 사용합니다`DBMS_CRYPTO`. Oracle 엔드포인트에서 데이터 검증을 사용하는 경우, Oracle 엔드포인트에 액세스하는 데 사용되는 사용자 계정에 `dbms_crypto`에 대한 실행 권한을 부여해야 합니다. 다음 명령문을 실행하여 이 권한을 호출할 수 있습니다 ``` grant execute on sys.dbms_crypto to dms_endpoint_user; ``` + 검증 AWS DMS 중에 대상 데이터베이스가 외부에서 수정되면 불일치가 정확하게 보고되지 않을 수 있습니다. 이 결과는 애플리케이션 중 하나가 동일한 테이블에서 검증을 수행하는 동안 대상 테이블에 데이터를 쓰 AWS DMS 는 경우에 발생할 수 있습니다. + 검증 중에 하나 이상의 행이 지속적으로 수정되는 경우는 해당 행을 검증할 AWS DMS 수 없습니다. + 가 10,000개 이상의 실패하거나 일시 중지된 레코드를 AWS DMS 감지하면 검증이 중지됩니다. 계속 진행하기 전에 데이터에 잠재된 문제를 해결하세요. + AWS DMS 는 뷰의 데이터 검증을 지원하지 않습니다. + AWS DMS 는 문자 대체 작업 설정을 사용할 때 데이터 검증을 지원하지 않습니다. + AWS DMS 는 Oracle LONG 유형의 검증을 지원하지 않습니다. + AWS DMS 는 이기종 마이그레이션 중에 Oracle Spatial 유형의 검증을 지원하지 않습니다. + 데이터 검증은 테이블 매핑에 데이터 마스킹 변환이 있는 테이블의 열을 무시합니다. + 데이터 검증은 PK/UK 열에 대한 데이터 마스킹 변환 규칙이 있는 경우 전체 테이블을 건너뜁니다. 검증 상태는 해당 테이블에 대한 프라이머리 키 없음으로 표시됩니다. + Amazon Aurora PostgreSQL Limitless에서는 데이터 검증이 작동하지 않습니다. Limitless Database의 테이블을 검증하려고 하면 검증 상태에 이러한 테이블에 대한 "프라이머리 키 없음"이 표시됩니다. S3 대상 검증 사용에 대한 제한 사항은 [S3 대상 검증 사용에 대한 제한 사항](CHAP_Validating_S3.md#CHAP_Validating_S3_limitations) 섹션을 참조하세요. # Amazon S3 대상 데이터 검증 AWS DMS 는 Amazon S3 대상에서 복제된 데이터의 검증을 지원합니다. 는 복제된 데이터를 Amazon S3에 플랫 파일로 AWS DMS 저장하기 때문에 [ Amazon Athena](https://docs.aws.amazon.com/athena/latest/ug/what-is.html)`CREATE TABLE AS SELECT`(CTAS) 쿼리를 사용하여 데이터를 검증합니다. Amazon S3에 저장된 데이터에 대한 쿼리는 컴퓨팅 집약적입니다. 따라서는 하루에 한 번만 변경 데이터 캡처(CDC) 중에 자정(00:00) UTC에 Amazon S3 데이터에 대한 검증을 AWS DMS 실행합니다. 가 AWS DMS 실행하는 각 일일 검증을 *간격 검증*이라고 합니다. 간격 검증 중에는 이전 24시간 동안 대상 Amazon S3 버킷으로 마이그레이션된 모든 변경 레코드를 AWS DMS 검증합니다. 간격 검증의 제한 사항에 대한 자세한 내용은 [S3 대상 검증 사용에 대한 제한 사항](#CHAP_Validating_S3_limitations) 섹션을 참조하세요. Amazon S3 대상 검증은 Amazon Athena를 사용하므로 추가 비용이 적용됩니다. 자세한 내용은 [Amazon Athena 요금](https://aws.amazon.com/athena/pricing/)을 참조하세요. **참고** S3 대상 검증에는 AWS DMS 버전 3.5.0 이상이 필요합니다. **Topics** + [사전 조건](#CHAP_Validating_S3_prerequisites) + [권한](#CHAP_Validating_S3_permissions) + [제한 사항](#CHAP_Validating_S3_limitations) + [검증 전용 태스크](#CHAP_Validating_S3_only) ## S3 대상 검증 사전 조건 S3 대상 검증을 사용하기 전에 다음과 같은 설정 및 권한을 확인합니다. + 엔드포인트의 [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html)에 대한 `DataFormat` 값을 `parquet`로 설정합니다. 자세한 내용은 [S3의 Parquet 설정](CHAP_Target.S3.md#CHAP_Target.S3.EndpointSettings.Parquet) 단원을 참조하십시오. + 마이그레이션 태스크를 생성하는 데 사용된 사용자 계정에 할당된 역할은 올바른 권한 집합을 보유하고 있어야 합니다. 아래의 [권한](#CHAP_Validating_S3_permissions) 섹션을 참조하세요. 지속적 복제(CDC)를 사용하는 태스크의 경우 다음 설정을 확인하세요. + CDC 데이터에 전체 레코드를 남기려면 보충 로깅을 활성화합니다. 보충 로깅 활성화에 대한 내용은 이 가이드의 [문제 해결 및 진단 지원지연 시간 문제 해결](CHAP_Troubleshooting.md) 섹션에서 [보충 로깅을 Oracle 소스 엔드포인트에 자동으로 추가합니다.](CHAP_Troubleshooting.md#CHAP_Troubleshooting.Oracle.AutoSupplLogging) 부분을 참조하세요. + 대상 엔드포인트의 `TimestampColumnName` 파라미터를 설정합니다. 타임스탬프 열 이름에는 제한 사항이 없습니다. 자세한 내용은 [S3Settings](https://docs.aws.amazon.com/dms/latest/APIReference/API_S3Settings.html) 섹션을 참조하세요. + 대상의 날짜 기반 폴더 분할을 설정합니다. 자세한 내용은 [날짜 기반 폴더 파티셔닝 사용](CHAP_Target.S3.md#CHAP_Target.S3.DatePartitioning) 단원을 참조하십시오. ## S3 대상 검증을 사용하기 위한 권한 S3 대상 검증을 위한 액세스 권한을 설정하려면 마이그레이션 작업 생성에 사용된 사용자 계정에 할당된 역할은 다음과 같은 권한 집합을 보유하고 있어야 합니다. 샘플 값을 내가 생각한 값으로 바꿉니다. ------ #### [ JSON ] **** ``` { "Version":"2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": [ "athena:StartQueryExecution", "athena:GetQueryExecution", "athena:CreateWorkGroup" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "glue:CreateDatabase", "glue:DeleteDatabase", "glue:GetDatabase", "glue:GetTables", "glue:CreateTable", "glue:DeleteTable", "glue:GetTable" ], "Resource": "*" }, { "Effect": "Allow", "Action": [ "s3:GetBucketLocation", "s3:GetObject", "s3:ListBucketMultipartUploads", "s3:AbortMultipartUpload", "s3:ListMultipartUploadParts" ], "Resource": "*" } ] } ``` ------ ## S3 대상 검증 사용에 대한 제한 사항 S3 대상 검증을 사용할 때 적용되는 아래의 추가적인 제한 사항을 확인합니다. 모든 검증에 적용되는 제한 사항은 [제한 사항](CHAP_Validating.md#CHAP_Validating.Limitations) 섹션을 참조하세요. + `DatePartitionSequence` 값에는 '일' 구성 요소가 필요합니다. S3 대상 검증은 `YYYYMM` 형식을 지원하지 않습니다. + CDC 중에 간격 검증을 실행하면 `awsdms_validation_failures_v1` 표에 거짓 검증 오류가 표시될 수 있습니다. 이러한 오류는가 간격 검증 중에 도착한 변경 사항을 다음 날의 파티션 폴더로 AWS DMS 마이그레이션하기 때문에 발생합니다. 일반적으로 이러한 변경 사항은 당일의 파티션 폴더에 작성됩니다. 이러한 거짓 오류는 동적 소스 데이터베이스에서 정적 대상(예: Amazon S3)으로 복제된 항목을 검증하는 과정에서 발생하는 제한 사항입니다. 이러한 거짓 오류를 조사하려면 이런 오류가 일반적으로 나타나는 검증 기간이 종료되는 시점에(00:00 UTC) 레코드를 확인합니다. 거짓 오류의 수를 최소화하려면 태스크에 대한 `CDCLatencySource`가 낮아야 합니다. 모니터링 지연 시간에 대한 내용은 [복제 작업 지표](CHAP_Monitoring.md#CHAP_Monitoring.Metrics.Task) 섹션을 참조하세요. + `failed` 또는 `stopped` 상태의 태스크는 전날의 변경 사항을 검증하지 않습니다. 예상치 못한 실패로 인한 검증 오류를 최소화하려면 동일한 테이블 매핑, 소스 및 대상 엔드포인트가 포함된 별도의 검증 전용 태스크를 생성합니다. 검증 전용 태스크에 대한 자세한 내용은 [S3 대상 검증과 함께 검증 전용 태스크 사용](#CHAP_Validating_S3_only) 섹션을 참조하세요. + 테이블 통계의 **검증 상태** 열에는 가장 최근의 간격 검증 상태가 반영됩니다. 따라서 불일치 항목이 있는 테이블은 다음 날 간격 검증이 끝난 후에 검증된 것으로 표시될 수 있습니다. 대상 Amazon S3 버킷의 `s3_validation_failures folder`를 검사하여 하루 이상 전에 발생한 불일치 항목이 있는지 확인합니다. + S3 검증은 Amazon Athena의 버킷 테이블 기능을 사용합니다. 이렇게 하면 S3 검증이 대상 테이블 데이터의 버킷 복사본을 만들 수 있습니다. 즉, 테이블 데이터의 사본이 DMS 검증의 내부 파티셔닝과 일치하는 하위 집합으로 분할됩니다. Athena 버킷 테이블의 한도는 버킷 100,000개입니다. 이 제한을 초과하는 테이블에 대한 S3 검증 시도는 검증 실패로 나타납니다. S3 Validation에서 생성하려고 시도하는 버킷 수는 다음과 같습니다. ``` (#records in the table) / (validation partition size setting) ``` 이 제한을 해결하려면 S3 Validation에서 생성한 버킷 수가 100,000개 미만이 되도록 검증 파티션 크기 설정을 늘리세요. 버킷화에 대한 자세한 내용은 *Amazon Athena 사용 설명서*의 [Athena에서 파티셔닝 및 버킷화](https://docs.aws.amazon.com/athena/latest/ug/ctas-partitioning-and-bucketing.html)를 참조하세요. + 테이블 이름에는 밑줄을 제외한 특수 문자가 포함되어서는 안 됩니다. S3 검증은 테이블 이름에 특수 문자(밑줄 제외)를 지원하지 않는 Amazon Athena를 사용합니다. 자세한 내용은 *Amazon Athena 사용 설명서*의 [CREATE TABLE](https://docs.aws.amazon.com/athena/latest/ug/create-table.html) 주제를 참조하세요. + AWS Lake Formation에서 관리하는 Amazon S3 대상과 함께 AWS DMS 데이터 검증 기능을 사용하면 검증 프로세스가 실패합니다. 이로 인해 데이터 일관성 문제가 발생할 수 있습니다. ## S3 대상 검증과 함께 검증 전용 태스크 사용 *검증 전용 태스크*는 마이그레이션을 실행하지 않고 마이그레이션할 데이터에 대한 검증을 실행합니다. 마이그레이션 작업이 중지되더라도 검증 전용 작업은 계속 실행되므로가 00:00 UTC 간격 검증 기간을 놓치지 AWS DMS 않습니다. Amazon S3 대상 엔드포인트에서 검증 전용 태스크를 사용할 경우 다음과 같은 제한 사항이 적용됩니다. + 검증 전용 설정이 활성화된 전체 로드 작업에 대해 Amazon S3 검증이 지원되지만, 다른 엔드포인트의 전체 로드 및 검증 전용 작업과는 다르게 작동합니다. S3를 대상으로 하는 경우, 이 유형의 태스크는 S3 대상의 전체 로드 데이터에 대해서만 검증을 수행하며 CDC 마이그레이션의 일부로 마이그레이션된 데이터에 대해서는 검증을 수행하지 않습니다. 이 기능은 전체 로드 전용 태스크로 생성된 데이터를 검증할 때만 사용하세요. 이 모드를 사용하여 활성 CDC 태스크가 실행 중인 대상의 데이터를 검증하면 효과적인 검증이 이루어지지 않습니다. + 검증 전용 태스크는 마지막 간격 검증 기간(00:00 UTC) 이후의 변경 사항만 검증합니다. 검증 전용 태스크는 전날의 전체 로드 데이터 또는 CDC 데이터를 검증하지 않습니다. # AWS DMS 데이터 재동기화 AWS Database Migration Service (AWS DMS) 데이터 재동기화는 소스 데이터베이스와 대상 데이터베이스 간의 데이터 검증을 통해 식별된 데이터 불일치를 자동으로 수정합니다. 이 기능은 기존 DMS 마이그레이션 작업의 일부로 작동하여 작업 구성, 연결 설정, 테이블 매핑 및 변환에 따라 적절한 업데이트가 이루어지도록 합니다. 데이터 재동기화 기능은 대상 데이터베이스의 제어 테이블에서 검증 실패를 읽고 적절한 수정 작업을 실행하여 작동합니다. 불일치가 감지되면 현재 데이터는 실패 레코드에 저장된 프라이머리 키를 사용하여 소스에서 검색되고 구성된 변환을 준수하면서 대상에 적용됩니다. 자세한 내용은 [`awsdms_validation_failures_v2` 제어 테이블](CHAP_Validating.md#CHAP_DataResync.Troubleshooting.v2table) 단원을 참조하십시오. 동작은 마이그레이션 유형에 따라 다릅니다. full-load-only 작업의 경우 데이터 재동기화는 초기 로드 및 검증이 완료된 후 한 번 실행됩니다. 변경 데이터 캡처(CDC)가 있는 작업의 경우 데이터 재동기화는 구성된 일정에 따라 작동하며 수정 사항이 적용되는 동안 복제 및 검증을 일시적으로 일시 중지합니다. CDC 재동기화 작업 중: + 복제 및 검증이 일시적으로 일시 중지됩니다. + 데이터 재동기화는 기존 검증 실패를 처리합니다. + 일반 복제 및 검증이 재개됩니다. + 구성된 일정에 따라 프로세스가 반복됩니다. 데이터 재동기화는 각 수정 작업의 상태를 자동으로 추적하고 테이블 통계를 통해 자세한 지표를 제공합니다. **사전 조건**: 데이터 재동기화 기능에는 다음과 같은 사전 조건이 필요합니다. + AWS DMS 엔진 버전 3.6.1 이상이 있어야 합니다. + 복제가 진행 중인 작업에 대한 일정 및 타이밍 기간 설정을 구성해야 합니다. 전체 로드 전용 작업에는 이러한 설정이 필요하지 않습니다. ## 제한 사항 데이터 재동기화 기능에는 다음과 같은 제한이 있습니다. + 데이터 재동기화는 Oracle 및 SQL Server만 소스 데이터베이스로 지원합니다. + 데이터 재동기화는 PostgreSQL 및 Amazon Aurora PostgreSQL 호환 엔진을 대상 데이터베이스로 지원합니다. + 소스 및 대상 데이터베이스의 모든 테이블에는 프라이머리 키가 있어야 합니다. 검증은 프라이머리 키 또는 고유 키가 없는 테이블을 지원하지 않습니다. 유효한 기본 또는 고유 키가 없는 모든 테이블은 검증이 일시 중지되고 검증 실패는 보고되지 않습니다. + Full-load-only 작업을 실행할 때는 데이터 검증을 활성화해야 합니다. + 검증 전용 작업은 데이터를 복제하지 않으므로 데이터 재동기화를 활성화할 수 없습니다. 검증 전용 `taskID`만 제공하여 상위 복제 작업에서 재동기화를 활성화할 수 있습니다. 자세한 내용은 [검증 전용 작업](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.ValidationOnly) 섹션을 참조하세요. + 검증 전용 작업에 작업 설정에 `ControlSchema` 파라미터 설정이 구성되어 있는 경우 데이터 재동기화가 올바른 검증 실패를 찾으려면 복제 작업에도 동일한 파라미터 구성이 있어야 합니다. + CDC 작업에 대한 일정 및 타이밍 기간 설정을 구성해야 합니다. + 재동기화 기간 동안 데이터 재동기화는 DMS의 복제 지연 시간에 영향을 미칠 수 있습니다. 데이터 재동기화 AWS DMS 중의 검증 문제 해결에 대한 자세한 내용은 [AWS DMS 데이터 검증](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html) 아래의 [문제 해결](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting) 섹션을 참조하세요. ## 예약 및 타이밍 CDC 작업의 경우 데이터 재동기화가 작동하는 시기와 기간을 구성해야 합니다. 이렇게 하면 정상적인 복제 작업에 미치는 영향을 방지할 수 있습니다. 다음을 지정합니다. + cron 형식을 사용하여 재동기화 작업이 발생할 수 있는 시기를 정의하는 일정입니다. + 재동기화 작업이 최대 사용 기간으로 연장되지 않도록 하기 위한 최대 기간입니다. 사용량이 적은 시간 또는 소스 데이터베이스에 변경이 거의 또는 전혀 없는 기간 동안 재동기화 작업을 예약하는 것이 좋습니다. **참고** 데이터 재동기화와 일반 복제를 동시에 실행할 수 없으므로 예약된 시간에는 대상 적용 스트림이 비어 있을 때까지 기다리는 것이 포함됩니다. ## 사용 사례 데이터 재동기화 기능을 사용하면 사용자가 소스 시스템과 대상 시스템 간의 데이터 불일치를 조정할 수 있습니다. 일치하지 않는 레코드를 식별하고 동기화하여 분산 환경 간에 데이터 일관성을 유지합니다. 다음 사용 사례는 데이터 재동기화 기능이 데이터 일관성 문제를 해결하는 일반적인 시나리오를 보여줍니다. **시나리오 1: 전체 로드 작업 - 동일한 DMS 작업을 사용하여 재동기화 실행** 기존 DMS 전체 로드 마이그레이션 작업에서 다음을 수행할 수 있습니다. + 검증 활성화: `Validation with data migration = true`. + 재동기화 활성화: `Data resync = true` **시나리오 2: 전체 로드 및 CDC, CDC 전용 작업 - 동일한 DMS 작업을 사용하여 재동기화 실행** 기존 DMS CDC 마이그레이션 작업에서 다음을 수행할 수 있습니다. + 검증 활성화: `Validation with data migration = true`. + 재동기화 활성화: `Data resync = true` + 재동기화 일정 지정: `"ResyncSchedule": "0 0,2,4,6 * * *"`. + 재동기화 시간 지정: `MaxResyncTime": 60` **시나리오 3: 검증 전용 작업과 함께 복제 및 재동기화를 위한 전체 로드 및 CDC 또는 CDC 전용 작업** 재동기화를 사용할 때 다른 DMS 작업에서 검증 전용 작업을 수행하려면 다음을 수행할 수 있습니다. + 검증 전용 DMS CDC 작업을 생성합니다. **참고** 데이터 재동기화 중에 이 작업의 ID를 기록하고 지정해야 합니다. + 기본 CDC 작업에서 `Data validation = false` 검증을 비활성화합니다. + 재동기화 활성화: `Data resync = true` + 재동기화 일정 지정: `"ResyncSchedule": "0 0,2,4,6 * * *"`. + 재동기화 시간 지정: `MaxResyncTime": 60`. + 검증 전용 DMS CDC 작업의 ID를 지정합니다. 검증 전용 작업 ID는 ARN 끝에 추가됩니다. 예제 ARN: `arn:aws:dms:us-west-2:123456789012:task:6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI` 및 예제 검증 전용 작업 ID: `6DG4CLGJ5JSJR67CFD7UDXFY7KV6CYGRICL6KWI`. ## 모범 사례 의 데이터 재동기 기능을 활용하여 복제 작업의 내구성 AWS Database Migration Service 을 개선하고 일관성을 확보할 수 있습니다. 데이터 재동기화 기능을 사용하는 모범 사례는 다음과 같습니다. + 데이터 재동기화의 일부로 불일치가 있는 레코드는 소스에서 가져와 대상 데이터베이스에 적용하여 수정됩니다. 재동기화 기간 중에 소스 데이터베이스가 업데이트되면 재동기화는 최신 레코드 값을 읽어 대상에 적용합니다. 이로 인해 CDC가 이벤트를 적용하지 못하고 대상 데이터베이스에 일시적인 불일치가 발생할 수 있습니다. 이를 방지하려면 업무 외 시간 또는 소스 데이터베이스의 변경 사항이 0이거나 최소인 기간에 재동기화 기간을 예약해야 합니다. + 최소 소스 데이터베이스 활동 기간 동안 허용 가능한 목표 지연 시간 임계값 내에서 재동기화 기간을 설정합니다. 재동기화 간격이 작으면 처리되지 않은 검증 불일치가 누적될 수 있는 반면, 확인 실패가 많을 경우 기간이 클수록 복제 지연 시간이 늘어날 수 있습니다. 검증 실패 및 재동기화 속도를 모니터링하여 소스 비활성 기간 동안 최적의 재동기화 기간을 결정합니다. 재동기화 기간을 설정하는 몇 가지 예는 다음과 같습니다. + 여러 짧은 기간 구성: ``` "ResyncSchedule": "0 0,2,4,6 * * *", "MaxResyncTime": 60 ``` + 단일 일일 기간 구성: ``` "ResyncSchedule": "0 0 * * *", "MaxResyncTime": 360 ``` + 재동기화 기간 동안 DMS의 복제 지연 시간을 모니터링하고 그에 따라 일정을 조정하여 대규모 급증을 완화합니다. + 테이블 통계를 통해 또는 대상 데이터베이스에서 `awsdms_validation_failures_v2` 테이블을 쿼리하여 재동기화 결과를 검토할 수 있습니다. 자세한 내용은 [Amazon CloudWatch를 사용하여 복제 지표 모니터링](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Monitoring.html#CHAP_Monitoring.CloudWatch)을 참조하세요. + 작업이 지속적 복제 단계에 있는 경우 재동기화 기간 동안 개별 테이블에 대한 재로드를 시작하지 마세요. + CDC 복제 작업 모범 사례: + 데이터베이스의 모든 테이블이 로드 프로세스를 완료합니다. + 불일치는 진행 중인 검증 프로세스에서 식별됩니다. + 재동기화 예약 기간에 따라 복제 작업이 잠시 일시 중지됩니다. + 데이터 재동기화는 검증 프로세스 중에 식별된 문제를 해결합니다. + 복제 프로세스가 재개되고 일정에 따라 반복됩니다. ## 데이터 재동기화 구성 및 예제 **데이터 재동기화 설정 구성**: DMS에서 복제 작업에 대한 재동기화를 구성할 수 있습니다. 다음은 작업에서 데이터 재동기화 설정 구성의 예입니다. ``` "ResyncSettings": { "EnableResync": true, "ResyncSchedule": "0 0,2,4,6 * * *", // Run at 12AM, 2AM, 4AM, and 6AM daily "MaxResyncTime": 60, // Run for maximum of 60 minutes, or 1 hour "ValidationTaskId": "TASK-ID-IF-NEEDED" //Optional, used only if validation is performed as a separate Validation only task } ``` **일반적인 재동기화 예약 패턴의 예**: + `0 0 * * *`: 매일 자정에 한 번 실행합니다. + `0 0,12 * * *`: 매일 자정과 정오에 두 번 실행합니다. + `0 0,2,4,6, * * *`: 자정부터 오전 6시 사이에 2시간마다 실행합니다. + `0 1 * * 1`: 매주 월요일 오전 1시에 실행합니다. **참고** 0부터 6까지 매일 숫자를 지정해야 합니다. 자세한 내용은 [cron 표현식](#CHAP_DataResync.cron) 섹션을 참조하세요. **재동기화 작업 모니터링**: 테이블 통계를 통해 재동기화 작업을 모니터링할 수 있습니다. 다음은 예시 출력입니다. ``` { "TableStatistics": { ... "ValidationFailedRecords": 1000, ... "ResyncRowsAttempted": 1000, "ResyncRowsSucceeded": 995, "ResyncRowsFailed": 5, "ResyncProgress": 99.5, // ratio of ResyncRowsSucceeded/ValidationFailedRecords "ResyncState": "Last resync at: 2024-03-14T06:00:00Z" } } ``` 에서 데이터 재동기화 기능을 구성하려면 다양한 재동기화 파라미터와 해당 구성 설정을 검토할 AWS DMS수 있습니다. 자세한 내용은 [데이터 재동기 설정](CHAP_Tasks.CustomizingTasks.TaskSettings.DataResyncSettings.md) 단원을 참조하십시오. 데이터 재동기 로깅 설정에 대한 자세한 내용은 [작업 설정 로깅](CHAP_Tasks.CustomizingTasks.TaskSettings.Logging.md) 섹션을 참조하세요. ## 검증 및 문제 해결 **검증**: 데이터 평가 기능이 활성화되면는 다음 구조를 사용하여 대상 데이터베이스에 검증 실패 테이블을 AWS DMS 생성합니다. ``` CREATE TABLE awsdms_validation_failures_v2 ( "RESYNC_ID" bigint NOT NULL, "TASK_NAME" varchar(128) NOT NULL, "TABLE_OWNER" varchar(128) NOT NULL, "TABLE_NAME" varchar(128) NOT NULL, "FAILURE_TIME" timestamp NOT NULL, "KEY_TYPE" varchar(128) NOT NULL, "KEY" varchar(7800) NOT NULL, "FAILURE_TYPE" varchar(128) NOT NULL, "DETAILS" varchar(7000) NOT NULL, "RESYNC_RESULT" varchar(128) NULL, "RESYNC_TIME" timestamp NULL, "RESYNC_ACTION" varchar(128) NULL ); ``` 이 테이블에 쿼리를 작성하여 발견된 데이터 불일치와 불일치 해결 방법을 이해할 수 있습니다. 검증이 활성화되면는 대상 데이터베이스에 검증 실패 테이블을 AWS DMS 생성합니다. 문제가 있는 경우 `awsdms_control.awsdms_validation_failures_v2` 테이블을 쿼리하여 발견된 데이터 불일치와 불일치 해결 방법을 이해할 수 있습니다. 자세한 내용은 [AWS DMS 데이터 검증](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html)의 [문제 해결](https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Validating.html#CHAP_Validating.Troubleshooting) 섹션을 참조하세요. **일반적인 워크플로**: 데이터 재동기화에서 검증하는 동안 표준 워크플로는 다음과 같습니다. **전체 로드 전용 작업**: 1. 데이터베이스의 모든 테이블이 로드 프로세스를 완료합니다. 1. 불일치는 진행 중인 검증 프로세스에서 식별됩니다. 1. 데이터 재동기화는 검증 프로세스 중에 식별된 문제를 해결합니다. 1. 검증 프로세스는 수정을 검증합니다. 1. 마이그레이션 작업이 성공적으로 완료되었습니다. **CDC 작업**: 1. 데이터베이스의 모든 테이블이 로드 프로세스를 완료합니다. 1. 불일치는 진행 중인 검증 프로세스에서 식별됩니다. 1. 재동기화 예약 기간에 따라 복제 작업이 잠시 일시 중지됩니다. 1. 데이터 재동기화는 검증 프로세스 중에 식별된 문제를 해결합니다. 1. 복제 프로세스가 재개되고 일정에 따라 반복됩니다. 재동기화 작업 중에 복제 작업을 중지하거나 테이블을 다시 로드하고 재검증하는 등 작업을 수정하면 작업의 동작과 결과에 영향을 미칠 수 있습니다. 알려진 동작 변경 사항 중 일부는 다음과 같습니다. **재동기화 작업이 진행되는 동안 복제 작업을 중지하는 경우**: + 재동기화 작업은 자동으로 재개되지 않습니다. 다시 시작해야 합니다. + 향후 재동기화 작업은 구성된 일정에 따라 수행됩니다. + 완료되지 않은 수정은 다음 재동기화 일정 창에서 시도됩니다. **데이터베이스에서 테이블을 다시 로드하는 경우**: + 재동기화 작업은 재로드 중인 테이블을 건너뜁니다. + 다시 로드된 테이블에 대한 이전 검증 실패는 무시됩니다. + 재로드 작업이 완료된 후 새 검증이 시작됩니다. **데이터베이스에서 테이블을 재검증하는 경우**: + 재동기화 작업에 대한 모든 통계가 재설정됩니다. + 재검증된 테이블에 대한 이전 검증 실패는 무시됩니다. **참고** 작업을 DMS 버전 3.6.1 이상으로 업그레이드하거나 이동할 때 `awsdms_control.awsdms_validation_failures_v1` 테이블의 장애가 다시 동기화되지 않습니다. `awsdms_validation_failures_v2` 테이블의 실패만 다시 동기화됩니다. `awsdms_control.awsdms_validation_failures_v2` 테이블에서 실패를 다시 동기화하려면 작업을 다시 로드하거나, 작업에 하나 이상의 테이블을 다시 로드하거나, 하나 이상의 테이블을 다시 검증해야 합니다. 자세한 내용은 다음 링크를 참조하세요. 작업을 다시 로드하려면 [`StartReplicationTask` API 참조](https://docs.aws.amazon.com/dms/latest/APIReference/API_StartReplicationTask.html)를 참조하세요. 작업에서 하나 이상의 테이블을 다시 로드하려면 *AWS CLI 명령 참조* 설명서의 [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html) 섹션을 참조하세요. 하나 이상의 테이블을 다시 검증하려면 *AWS CLI 명령 참조* 설명서의 [https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html](https://docs.aws.amazon.com/cli/latest/reference/dms/reload-tables.html) 섹션에 있는 `validate-only` 옵션을 참조하세요. . ## Cron 표현식 규칙 에서 복제 작업 중에 데이터 재동기화 작업을 구성하려면 cron 표현식 규칙을 사용할 AWS DMS 수 있습니다. 이러한 규칙을 사용하면 재동기화 기간을 사용자 지정하고 비즈니스 요구 사항에 따라 예약할 수 있습니다. 분, 시간, 일, 월, 요일과 같은 다양한 파라미터를 사용할 수 있습니다. 각 파라미터에 대한 cron 표현식 규칙은 다음과 같습니다. **분**: + 분 범위는 0\$159입니다. + (`-`), `or`/`and`를 사용하여 범위를 지정할 수 있습니다. 쉼표(`,`)로 구분된 최대 10개의 항목. + **예**: + `2-5`는 `2,3,5,5`와 같습니다. + `1-2,3-4,5,7-10`은 유효한 범위입니다. + `1,2,3,4,5,6,7,8,9,10`은 유효한 범위입니다. + `1,2,3,4,5,6,7,8,9,10,11`은 유효한 범위가 아닙니다. 재동기화 작업은 10번째 범위 항목 이후에 건너뜁니다. + (`*`)를 사용할 수 있습니다. 예: `*`는 `0-59`와 같습니다. + (`/`)는 (`-`) 또는 (`*`)와 함께만 사용할 수 있습니다. **예**: + `2-7/2`는 `2,4,6`과 같습니다. + `*/15`는 `0,15,30,45`와 같습니다. **시간**: ‘**분**’과 동일하지만 유효한 범위는 `0` \$1 `23`입니다. **일**: + ‘**분**’과 동일하지만 유효한 범위는 `1` \$1 `31`입니다. + `L`의 사용은 재동기화 구성에서 지원됩니다. 해당 월의 마지막 날로 통합됩니다. 다른 구문과 함께 사용해서는 안 됩니다. **월**: "**분**"과 동일하지만 유효한 범위는 `1` \$1 `12`입니다. **요일**: + "**분**"과 동일하지만 유효한 범위는 `0` \$1 `6`입니다. + 해당 주의 이름에 문자열 값을 추가할 수 없습니다.