AWS 기술 블로그

AWS DMS의 data resync 기능을 이용한 데이터 일관성 구현하기

이 글은 AWS Database Blog에 게시된 Data consistency with AWS DMS data resync by Suchindranath Hegde, Mahesh Kansara, Sridhar Ramasubramanian을 한국어 번역 및 편집하였습니다.

이 글에서는 AWS Database Migration Service의 데이터 재동기화(Data Resync) 기능에 대해 자세히 살펴보겠습니다. 이 기능은 DMS 3.6.1버전에 도입되어 데이터베이스 마이그레이션 도중 데이터 불일치를 감지하고 해결함으로써 수동 개입을 없애 줍니다. 데이터 재동기화(Data Resync)를 사용하면 소스 데이터베이스와 타겟 데이터베이스 간의 데이터 검증(Validation)을 통해 확인된 모든 데이터 불일치를 식별하고 해결할 수 있습니다. 데이터 재동기화 기능을 활성화하는 단계와 데이터 불일치를 식별하는 방법의 예를 살펴보겠습니다. 데이터 재동기화 기능이 도입되기 전까지는 데이터 불일치가 발생하면 전체로드(Full load)나 변경 데이터 캡처(CDC) 작업 시 테이블 Reload를 실행하거나 타겟의 레코드를 수동으로 수정하는 등 사용자 수동 개입이 필요했습니다. 데이터 재동기화의 지원은 DMS에서 소스가 Oracle 이나 SQL Server 그리고 타겟은 PostgreSQL 또는 Amazon Aurora PostgreSQL 호환 버전(Amazon Aurora PostgreSQL-Compatible Edition)에서 지원되며 마이그레이션되는 모든 리전에서 사용할 수 있습니다.

DMS 데이터 재동기화(Data Resync) 설정

데이터 재동기화는 DMS 데이터 검증(Validation) 기능을 통해 식별된 불일치 데이터를 읽어 소스에서 현재 값을 검색하여 타겟에 적용하여 타겟의 레코드를 동기화하는 방식으로 작동합니다. 전체 로드 전용(Full-load only)의 경우 재동기화(Resync)가 활성화되면 모든 테이블의 검증(Validation)이 완료된 직후 실행됩니다. CDC가 포함된 Task의 경우 Task 설정을 통해 재동기화를 예약해야 하며, 이 시점에서 쓰기 작업 충돌을 최소화하기 위해 Task는 CDC 및 검증(Validation)을 일시 중지합니다. 모범 사례에서 권장하는 대로 소스 데이터베이스 워크로드가 최소인 기간에 대해 짧은 시간 동안 재동기화 스케쥴을 예약하는 것이 좋습니다. 이렇게 하면 CDC 일시 중지로 인해 발생되는 지연 시간 급증을 최소화할 수 있습니다. 데이터 재동기화를 구성하려면 Task를 생성하거나 수정하는 동안 활성화해야 합니다. 다음 스크린샷과 같이 AWS DMS 콘솔의 데이터 재동기화(Data Resync) 에서 재동기화 예약(Schedule Resync)을 선택합니다.

재동기화(Resync) 일정은 Cron 표현식을 사용하여 데이터 재동기화(Resync) 실행 일정을 예약합니다:

* * * * * 
| | | | | 
| | | | | 
| | | | +---- Day of Week (0-6) 
| | | +------ Month (1-12)
| | +-------- Day of Month (1-31)
| +---------- Hour (0-23)
+------------ Minute (0-59)

다음 설정은 토요일 자정에 데이터 재동기화(Resync)를 실행하도록 예약하는 예입니다:

"ResyncSettings": 
{
    "EnableResync": true,
    "ResyncSchedule": "0 0 * * 6", // 토요일 자정에 실행
    "MaxResyncTime": 360,  // 최대 360분 또는 6시간 동안 실행
    "ValidationTaskId": "" // 선택 사항이며 검증(validation) 이 별도의 Validation only Task 로 수행 하는 경우만 사용됩니다 
}

자세한 예제는 다음의 Data resync configuration and examples 을 참고하십시오.

데이터 재동기화(Resync)를 통해 AWS DMS 는PostgreSQL 엔드포인트 타겟에 다음의 스크린샷에 표시된 구조로 awsdms_validation_failures_v2 테이블을 생성합니다.

이 테이블은 Primary Key를 사용하여 소스의 데이터를 조회하여 검증 프로세스 중에 타겟 테이블의 불일치를 추적하고 해결하기 위해 참조됩니다. Task를 AWS DMS 버전 3.6.1 이상으로 업그레이드하거나 Move 하는 경우에는 업그레이드 이전에 발생한 검증 실패는 자동으로 재동기화 하지 않습니다. 업그레이드 검증 실패를 해결하려면 테이블 Reload 나 Re-validation을 시작해야 합니다. 업그레이드 이후에 발생하는 새로운 검증 실패는 awsdms_validation_failures_v2 테이블을 통해 추적되고 재동기화됩니다.

재동기화 작업 중에 AWS DMS는 Task 유형에 따라 다음과 같은 일련의 단계를 완료합니다. Task 유형에 따라 각 단계의 CloudWatch 로그 또는 Task log 에서 다음 메시지를 확인할 수 있습니다.

Full Load 및 CDC 또는 CDC Task 의 경우:

1. Resync 작업 트리거:

[DATA_RESYNC ]I: Data Resync Manager schedule window time matched to start resync

2. 검증(Validation) 멈춤:

[DATA_RESYNC ]I: Trying to STOP validation before resync process. (resync_manager.c:331)

3. CDC 멈춤:

[DATA_RESYNC ]I: Data Resync Manager sending command to sorter to PAUSE applying changes to target.

4. Table 재동기화(Resync):

[RESYNC_UNLOAD ]I: Sent ctrl command for Resync Unload of table with id: 1

5. CDC 재개(resume):

[DATA_RESYNC ]I: Data Resync Manager sending command to sorter to RESUME applying changes to target

6. 검증(Validation) 재개:

[DATA_RESYNC ]I: Trying to RESUME validation after resync process

FULL LOAD Only Task 의 경우 Validation 프로세스가 완료된 후 바로 재동기화(Resync) 관리자가 트리거되어 스케쥴을 별도로 지정할 필요가 없습니다:

1. 재동기화(Resync) 작업 트리거:

[DATA_RESYNC     ]I:  Data Resync Manager sending command to start up resync subtasks

2. Resync table:

[TASK_MANAGER ]I:  All tables are loaded. Validation is finished. Waiting for resync to finish...  (replicationtask.c:4953)
[DATA_RESYNC ]I:  Stopped Data Resync Manager, exiting thread

데이터 재동기화(Resync)의 사용 사례

DMS 데이터 재동기화(Resync)는 유용한 사례가 여러 가지가 있습니다. 이 섹션에서는 두 가지 사례를 살펴보겠습니다.

타겟에서 실수로 레코드를 삭제      

첫 번째 사용 사례는 타겟의 레코드가 실수로 삭제된 경우입니다. 이 사례를 설명하기 위해 REVIEWS라는 테이블을 Oracle에서 PostgreSQL로 마이그레이션하는 경우입니다. Full load 가 완료된 후, 타겟에서 실수로 몇 개의 레코드를 삭제합니다. 다음 예에서는 타겟에서 데이터 조작 언어(DML) 문을 실행하여 타겟의 특정 레코드를 삭제하겠습니다.

dmsdb=> delete from dms_test.reviews where review_id=8193;
DELETE 1

이 시나리오에서 테이블을 다시 검증(Revalidation) 하려고 하면 불일치가 발생하는데, 이는 다음 cli 명령을 실행하거나 AWS 콘솔을 통해서 확인할 수 있습니다:

aws dms describe-table-statistics --replication-task-arn arn:aws:dms:us-east-1:xxxxxxxxxxxx:task:xxxxxxxxxxxx --filters Name=table-name,Values="REVIEWS"

{
    "TableStatistics": [
        {
            "SchemaName": "DMS_TEST",
            "TableName": "REVIEWS",
            "Inserts": 0,
            "Deletes": 0,
            "Updates": 0,
            "Ddls": 0,
            "AppliedInserts": 0,
            "AppliedDeletes": 0,
            "AppliedUpdates": 0,
            "AppliedDdls": 0,
            "FullLoadRows": 3500,
            "FullLoadCondtnlChkFailedRows": 0,
            "FullLoadErrorRows": 0,
            "FullLoadStartTime": "2025-06-03T14:24:23.062000-05:00",
            "FullLoadEndTime": "2025-06-03T14:24:25.408000-05:00",
            "FullLoadReloaded": false,
            "LastUpdateTime": "2025-06-03T14:35:12.009000-05:00",
            "TableState": "Table completed",
            "ValidationPendingRecords": 0,
 "ValidationFailedRecords": 1,
            "ValidationSuspendedRecords": 0,
 "ValidationState": "Mismatched records"
        }
    ]
}

데이터 재동기화(Resync)가 활성화되면 이러한 불일치는 소스에서 확인한 후 타겟에 다시 적용되어 처리됩니다. 다음 예에서 RESYNC_ACTION 컬럼에서 UPSERT로 볼 수 있듯이 public.awsdms_validation_failures_v2 테이블에 반영된 레코드가 타겟에 다시 적용된 것을 확인할 수 있습니다. RESYNC_TIME컬럼은 작업이 수행된 타임스탬프를 보여줍니다.

dmsdb=> select * from public.awsdms_validation_failures_v2;
-[ RECORD 1 ]-+---------------------------
RESYNC_ID     | 1029
TASK_NAME     | BESR3KWW2FCLLH4AJBFSEYSNW4
TABLE_OWNER   | dms_test
TABLE_NAME    | reviews
FAILURE_TIME  | 2025-06-03 19:33:26.410998
KEY_TYPE      | Row
KEY           | {                         +
              |         "key":  ["8193"]  +
              | }
FAILURE_TYPE  | MISSING_TARGET
DETAILS       |
RESYNC_RESULT | SUCCESS
RESYNC_TIME   | 2025-06-03 19:35:06.322
RESYNC_ACTION | UPSERT

CDC 중에 실수로 타겟 레코드를 몇 개 더 삭제하는 상황을 가정해보겠습니다. 예를 들어, 다음 SQL 문은 타겟 레코드 20개를 무작위로 삭제합니다.

dmsdb=> delete from dms_test.reviews where ctid in (select ctid from dms_test.reviews order by RANDOM() LIMIT 20);
DELETE 20

다음에서 데이터 재동기화(Resync)작업이 해당 레코드를 처리하고 타겟에 성공적으로 적용한 것을 확인할 수 있습니다.

dmsdb=> select "TABLE_OWNER", "TABLE_NAME","RESYNC_ACTION", "FAILURE_TYPE", "RESYNC_RESULT",count(*) from public.awsdms_validation_failures_v2 group by "TABLE_OWNER", "TABLE_NAME","RESYNC_ACTION", "FAILURE_TYPE", "RESYNC_RESULT";
-[ RECORD 1 ]-+---------------
TABLE_OWNER | dms_test
TABLE_NAME | reviews
RESYNC_ACTION | UPSERT FAILURE_TYPE | MISSING_TARGET RESYNC_RESULT | SUCCESS count | 21

앞서 설명한 Full load와 CDC 시나리오 모두에서 데이터 재동기화(Resync)를 위해서는 모든 데이터 불일치를 정확하게 식별하고 수정하기 위해 테이블의 유효성을 다시 검사(Re-Validation)해야 합니다. 이 재검증(Re-Validation)은 DMS에서 타겟에 대한 변경 사항을 적용하지 않았기 때문에 필수적입니다.

Table Error 이후에 CDC Resume

마이그레이션 중 테이블이 오류 인 상태에서 해당 테이블의 변경 사항이 타겟에 복제되지 않는 또 다른 사례가 발생할 수 있습니다. 이 경우 Task 가 실행되는 동안 테이블을 Reload 할 수 있습니다. 그러나 CDC-only Task의 경우 테이블에서 오류가 발생한 LSN에서 Task를 재시작(Restart) 해야 합니다. DMS Task에 여러 테이블이 있는 경우 특정 시점부터 DMS Task를 시작하면 변경 사항이 타겟에 다시 적용될 수 있습니다.

ADMIN 스키마를 사용하는 다섯 개의 테이블을 Oracle에서 PostgreSQL로 마이그레이션하는 시나리오를 가정해 보겠습니다. 다음 스크린샷에서 다섯 개의 테이블 중 세 개가 오류가 발생되었습니다.

CloudWatch 로그를 보면 다음의 테이블들이 서로 다른 타임스탬프에서 오류로 suspend 되었음을 알 수 있습니다. 테이블이 서로 다른 타임스탬프에서 실패했으므로 테이블에서 오류가 발생한 가장 빠른 타임스탬프 값을 CDC 시작 시간으로 사용하고 이 세 테이블을 CDC -Only Task 로 생성해야 합니다. 이 경우 가장 빠른 타임스탬프는 2025-06-05T03:40:13입니다.

2025-06-05T03:40:13 [TASK_MANAGER ]W: Table 'ADMIN'.'DMST1' was errored/suspended (subtask 0 thread 1). 

2025-06-05T03:47:53 [TASK_MANAGER ]W: Table 'ADMIN'.'DMST2' was errored/suspended (subtask 0 thread 1). 

2025-06-05T03:52:32 [TASK_MANAGER ]W: Table 'ADMIN'.'DMST5' was errored/suspended (subtask 0 thread 1).

Data Resync 동안에 감지된 충돌이 해결되었는지 확인할 수 있습니다(아래 스크린샷 참조).

dmsdb=> select * from public.awsdms_validation_failures_v2;
-[ RECORD 1 ]-+---------------------------
RESYNC_ID     | 9949
TASK_NAME     | 6LOQBMAKQFDELB5WQB5BPG5Q74
TABLE_OWNER   | admin
TABLE_NAME    | dmst1
FAILURE_TIME  | 2025-06-05 05:26:58.027987
KEY_TYPE      | Row
KEY           | {                         +
              |         "key":  ["101"]   +
              | }
FAILURE_TYPE  | MISSING_TARGET
DETAILS       |
RESYNC_RESULT | SUCCESS
RESYNC_TIME   | 2025-06-05 05:30:06.423
RESYNC_ACTION | UPSERT

결론

이 글에서는 데이터 재동기화(Resync) 기능을 소개하고 구성 방법과 검증 과정에서 데이터 재동기화를 사용하여 불일치를 확인하고 수정할 수 있는 두 가지 사용 사례를 살펴보았습니다. 자세한 내용은 AWS DMS data resync 를 참고해주십시오.

Dokeun Kim

Dokeun Kim

김도근 Cloud Support DB Expert는 Amazon Database 서비스에 대한 고객들의 기술적 문의 및 이슈 분석 등의 고객지원 업무를 수행하고 있습니다.