AWS DMS 지속적복제(CDC) Table Error 발생

개요

AWS DMS로 CDC(luna → cellook) 진행 중인 상황에서 원본의 변경 사항이 타겟에 반영되지 않고 Table Error가 발생한 상황에 대해 정리하였습니다.

 

DMS 장애 상황 및 처리

DMS 구성이 되어있는 테이블에 대해 스키마 변경 요구사항이 있어 소스의 스키마 변경을 진행하였습니다.

• Source : Aurora MySQL
• Target : Aurora MySQL
• CDC 진행

 

Table Error 발생

AWS DMS 콘솔에서 해당 Task의 Status가 실행 중(오류 포함) 상태로 전환되었으며 이 시점 이후로 특정 테이블의 로드 상태가 Table error 상태로 전환되었으며 해당 테이블만 데이터가 연결되지 않는 상황이 발생하였습니다.

Table error 발생

 

이후 DMS 를 중지시킨 후에 다시 실행해보았지만 Stauts는 오류 포함 상태로 여전히 남아있었습니다. 우선 가장 먼저 Task DDL 핸들링 정책에 Alter 문의 실행이 CDC 진행에 포함되지 않았는지 확인하였습니다. "HandleSourceTableAltered": true로 Source에서 Alter 문 실행시 Target에도 반영되도록 설정이 잘 되어있었습니다. 이후 DMS Task 로그 상에는 별다른 이슈가 없어 테이블이 오류 상태로 전환된 내용에 대해 문서를 찾아보던 중 DMS의 Task TableErrorPolicy 정책에 대한 내용을 확인할 수 있었습니다.

 

TableErrorPolicy– Determines the action AWS DMS takes when an error occurs when processing data or metadata for a specific table.This error only applies to general table data and isn't an error that relates to a specific record. The default is SUSPEND_TABLE

 

현재 Task 정책의 TableErrorPolicy는 SUSPEND_TABLE로 설정되어 있었고 이 경우 테이블에 오류가 발생했을 때 오류 레코드에 있는 테이블의 데이터가 오류 상태로 이동되고 데이터가 복제되지 않습니다.
여기서 Table Error는 Failed 상태와는 다릅니다. Failed는 전체 작업이 실패하였을 때의 상황이며 Table Error는 문제가 발생한 테이블 외에는 마이그레이션이 지속됩니다. 그렇다면 Table Error인 상황을 해결하기 위해서는 우선 DMS의 프로세스를 알아야 합니다.

 

DMS 프로세스

DMS의 전체 로드 및 CDC 작업은 세 단계로 구성됩니다. 여기서 T1을 로드 시작시간, T2를 완료 시간이라 칭하겠습니다.

1. Full load - T1부터 T2에 끝나는 초기 벌크 로드
2. Applying cached changes - T1과 T2사이. 즉, 전체 로드 중 테이블에 발생한 변경 사항
3. Ongoing changes - 캐시 된 변경사항이 적용된 T2이후의 지속적 복제 (CDC)

 

우선 테이블의 전체 로드가 완료되면 캐시된 변경 사항을 적용하는 단계로 들어갑니다. 이 단계가 완료된 후에는 테이블 단위로 지속적 복제가 이루어지며 이때 다른 테이블의 상태 여부는 고려하지 않습니다. 오류가 발생한 테이블의 경우 Table Error상태로 진입합니다. 즉, Table Error는 전체 로드가 완료된 이후 특정 오류 시점으로부터 복제가 중단된 상황에 놓이게 됩니다. 이 경우 문제를 수정하고 오류가 발생한 테이블만 다시 로드를 진행하면 됩니다.
여기서 테이블 다시 로드란 Target의 데이터를 자르고 로드하는 것이 아닌 중단 시점 이후 변경된 사항을 적용하는 것을 의미합니다.

 

이후 문제가 정상적으로 해결되어 로드되지 않은 작업이 반영되었을 Task의 상태가 정상화됩니다.

 

변경 사항 관리

그렇다면 오류가 발생한 테이블의 경우 어떻게 관리가 되는 것일까?

AWS DMS는 소스 및 대상에 대한 스트림을 생성하고 복제 인스턴스의 메모리에 있는 스트림 버퍼에 정보를 저장합니다. 이 점에 유의해서 CDC 작업의 프로세스를 확인해보겠습니다.

1. 복제 API를 사용해 원본의 트랜잭션 로그에서 변경 사항을 읽고 복제 인스턴스의 메모리 버퍼에 저장합니다.
   (변경 사항의 내용이 클 경우 디스크가 사용될 수 있습니다.
2. Target 데이터베이스 엔진에 따라 로드되지 않은 변경 트랜잭션을 처리하고 변환합니다.
3. 변경 사항을 Target에 적용할 준비가 되면 대상으로 전송을 시작합니다.

 

정리하자면 DMS는 Task 가 중지되거나 일부 테이블에 오류가 발생하여도 복제 인스턴스에서 변경 내역을 지속적으로 수집하고 저장합니다. 이후 작업이 재시작되었을 경우 로드되지 않은 변경 사항에 대해 처리가 진행됩니다.

 

마무리

DMS의 Table Error 상황의 경우 테이블 스키마 오류부터 CPU, Memory, Table Lock 등 다양한 원인에 의해 발생한다고 합니다. 이러한 경우를 전부 방지하기는 어렵다고 하며 DMS Error 정책을 유동적으로 변경할 수 있다고 합니다.

 

참고

Debugging Your AWS DMS Migrations: What to Do When Things Go Wrong (Part 1) | Amazon Web Services

Debugging Your AWS DMS Migrations: What to Do When Things Go Wrong (Part 2) | Amazon Web Services

Debugging Your AWS DMS Migrations: What to Do When Things Go Wrong? (Part 3) | Amazon Web Services