AWS DMS를 사용하여 지속 복제를 위한 작업 생성 - AWS Database Migration Service

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

AWS DMS를 사용하여 지속 복제를 위한 작업 생성

를 생성할 수 있습니다.AWS DMS원본 데이터 스토어의 지속적 변경 사항을 캡처하는 작업 데이터를 마이그레이션하는 동안에도 이 변경 사항을 캡처할 수 있습니다. 작업을 생성하여 지원된 대상 데이터 스토어로 초기(전체 로드) 마이그레이션을 완료한 후 지속적 변경 사항을 캡처할 수도 있습니다. 이 프로세스를 진행 중인 복제 또는 변경 데이터 캡처(CDC)라고 합니다. AWS DMS에서는 원본 데이터 스토어에서 지속적 변경 사항을 복제할 때 이 프로세스를 사용합니다. 이 프로세스는 데이터베이스 엔진의 기본 API를 사용하여 데이터베이스 로그에 대한 변경 사항을 수집합니다.

참고

뷰는 전체 로드 작업만 사용하여 마이그레이션할 수 있습니다. 작업이 CDC 전용 작업이거나 완료된 후 CDC를 시작하는 전체 로드 작업인 경우, 소스의 테이블만 마이그레이션에 포함됩니다. 전체 로드 전용 작업을 사용하면 뷰 또는 테이블 및 뷰 조합을 마이그레이션할 수 있습니다. 자세한 정보는 JSON을 사용하여 테이블 선택 및 변환 규칙 지정을 참조하십시오.

각 소스 엔진에는 이 변경 스트림을 지정된 사용자 계정에 노출하기 위한 특정 구성 요구 사항이 있습니다. 대다수 엔진에서는 데이터 손실 없이 캡처 프로세스를 지원할 수 있도록 유의미한 방식으로 변경 데이터를 소모하도록 해주는 일부 추가 구성이 필요합니다. 예를 들어, Oracle은 보충 로깅 추가를 필요로 하고, MySQL은 행 수준의 2진법 로깅(빈 로깅)을 필요로 합니다.

AWS DMS에서는 소스 데이터베이스의 지속적 변경 사항을 읽기 위해 엔진별 API 작업을 사용하여 소스 엔진의 트랜잭션 로그에서 변경 사항을 읽습니다. 다음은 AWS DMS 작동 방식에 대한 몇 가지 예입니다.

  • Oracle의 경우 AWS DMS는 Oracle LogMiner API나 bfile API(binary reader API) 중 하나를 사용하여 지속적 변경 사항을 읽습니다. AWS DMS는 시스템 변경 수(SCN)에 따라 온라인 또는 아카이브 다시 실행 로그에서 지속적 변경 사항을 읽습니다.

  • Microsoft SQL Server의 경우 AWS DMS는 MS-Replication 또는 MS-CDC를 사용해 SQL 서버 트랜잭션 로그에 정보를 기록합니다. 그러면 SQL 서버에서 fn_dblog() 또는 fn_dump_dblog() 함수를 사용해 로그 시퀀스 번호(LSN)에 토대를 둔 트랜젝션 로그의 변경 사항을 읽습니다.

  • MySQL의 경우, AWS DMS는 행 기반 바이너리 로그(binlogs)의 변경 사항을 읽고, 이 변경 사항을 대상으로 마이그레이션합니다.

  • PostgreSQL의 경우, AWS DMS는 논리적 복제 슬롯을 설정하고, test_decoding 플러그인을 사용해 원본의 변경 사항을 읽고, 이를 대상으로 마이그레이션합니다.

  • Amazon RDS를 소스로 할 경우, CDC를 설정할 수 있는 백업을 권장합니다. 충분한 시간 (대개 24시간이면 충분함) 동안 원본 데이터베이스가 변경 로그를 유지하도록 구성하는 것이 좋습니다.

다음은 진행 중인 복제 작업의 두 가지 유형입니다.

  • 전체 로드+CDC — 이 작업은 기존 데이터를 마이그레이션한 다음 원본 데이터베이스의 변경 사항을 기반으로 대상 데이터베이스를 업데이트합니다.

  • CDC만 해당 — 대상 데이터베이스에 데이터가 있는 후 진행 중인 변경 사항을 마이그레이션합니다.

CDC 시작 포인트에서 복제를 시작합니다.

몇몇 지점에서 AWS DMS 지속적 복제 작업(변경 데이터 캡처만 해당)을 시작할 수 있습니다. 다음을 포함합니다.

  • [Custom CDC 시작 시간]— 를 사용해도 됩니다.AWS Management Console또는AWS CLI를 제공하려면AWS DMS복제를 시작할 타임스탬프가 있습니다.AWS DMS이 사용자 지정 CDC 시작 시간부터 진행 중인 복제 작업을 시작합니다.AWS DMS는 지정된 타임스탬프 (UTC) 를 SQL Server의 경우 LSN이나 Oracle의 경우 SCN과 같은 기본 시작점으로 변환합니다.AWS DMS에서는 엔진별 메서드를 사용하여 소스 엔진의 변경 스트림을 기반으로 마이그레이션 작업을 시작할 위치를 결정합니다.

    참고

    PostgreSQL을 소스로 사용할 경우 사용자 지정 CDC 시작 시간을 지원하지 않습니다. PostgreSQL 데이터베이스 엔진에는 타임스탬프를 SCN 또는 SCN으로 매핑하는 방법이 없기 때문입니다. Oracle 및 SQL Server에는 그러한 방법이 있습니다.

  • CDC 네이티브 시작 시점부터— 원본 엔진 트랜잭션 로그의 원래 포인트에서 시작할 수도 있습니다. 타임스탬프는 트랜잭션 로그에 여러 네이티브 지점을 나타낼 수 있기 때문에 경우에 따라 이 접근 방식이 좋을 수 있습니다. AWS DMS는 다음 소스 엔드포인트에 대해 이 기능을 지원합니다.

    • SQL 서버

    • PostgreSQL

    • Oracle

    • MySQL

작업이 생성되면AWS DMSCDC 시작점을 표시하며 변경할 수 없습니다. 다른 CDC 시작점을 사용하려면 새 작업을 만듭니다.

CDC 네이티브 시작 지점 결정

CDC 네이티브 시작 지점은 CDC를 시작할 수 있는 시간을 정의하는 데이터베이스 엔진 로그의 지점입니다. 대량 데이터 덤프가 대상에 이미 적용되었다고 가정합니다. 네이티브 시작 지점을 찾아 진행 중인 복제 전용 작업을 확인할 수 있습니다. 데이터 불일치를 방지하려면 복제 전용 작업의 시작점을 신중하게 선택하십시오. DMS는 선택한 CDC 시작 지점 이후에 시작된 트랜잭션을 캡처합니다.

다음은 지원되는 소스 엔진에서 CDC 네이티브 시작 지점을 찾는 방법에 대한 예입니다.

SQL 서버

SQL Server의 로그 시퀀스 번호(LSN)는 세 부분으로 구성되어 있습니다.

  • 가상 로그 파일(VLF) 시퀀스 번호

  • 로그 블록의 시작 오프셋

  • 슬롯 번호

LSN의 예는 다음과 같습니다. 00000014:00000061:0001

트랜잭션 로그 백업 설정에 따라 SQL Server 마이그레이션 작업의 시작 지점을 확인하려면 SQL Server의 fn_dblog() 또는 fn_dump_dblog() 함수를 사용합니다.

SQL Server와 함께 CDC 네이티브 시작 시점을 사용하려면 지속 복제에 참여하는 모든 테이블에 대한 게시를 생성합니다.AWS DMSCDC 네이티브 시작 지점을 사용하지 않고 CDC를 사용할 경우 는 게시를 자동으로 생성합니다.

PostgreSQL

PostgreSQL 원본 데이터베이스에 CDC 복구 체크포인트를 사용할 수 있습니다. 이 체크포인트 값은 다양한 지점에서 원본 데이터베이스에 대해 지속적 복제 작업(상위 작업)으로 생성됩니다. 일반적으로 체크포인트에 대한 자세한 내용은 단원을 참조하십시오.체크포인트를 CDC 시작 지점으로 사용.

네이티브 시작 시점으로 사용할 체크포인트를 식별하려면 데이터베이스를 사용합니다.pg_replication_slots상위 작업의 개요 세부 정보 보기 또는AWS Management Console

콘솔에서 상위 작업에 대한 개요 세부 정보를 찾으려면

  1. 에 로그인합니다.AWS Management Console를 열려면AWS DMS에서 콘솔https://console.aws.amazon.com/dms/v2/.

    IAM 사용자로 로그인한 경우 에 액세스하기 위한 적절한 권한이 있어야 합니다.AWS DMS. 필요한 권한에 대한 자세한 내용은 AWS DMS 사용에 필요한 IAM 권한 단원을 참조하십시오.

  2. 탐색 창에서 데이터베이스 마이그레이션 작업을 선택합니다.

  3. 데이터베이스 마이그레이션 작업 페이지의 목록에서 상위 작업을 선택합니다. 그러면 개요 세부 정보가 표시된 상위 작업 페이지가 열립니다.

  4. 변경 데이터 캡처(CDC), 변경 데이터 캡처(CDC) 시작 위치변경 데이터 캡처(CDC) 복구 체크포인트 아래에서 체크포인트 값을 찾습니다.

    이 값은 다음과 유사합니다.

    checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

    여기서 4AF/B00000D0 구성 요소는 이 CDC 네이티브 시작 지점을 지정하는 데 필요한 것입니다. PostgreSQL 원본의 이 시작 지점에서 복제를 시작하는 CDC 작업을 만들 때 DMS API CdcStartPosition 파라미터를 이 값으로 설정합니다. AWS CLI를 사용하여 이 CDC 작업을 만드는 방법에 대한 자세한 내용은 다음 작업을 통해 CDC 활성화AWS- 관리형 PostgreSQL DB DB 인스턴스AWS DMS 단원을 참조하십시오.

Oracle

시스템 변경 번호(SCN)은 Oracle 데이터베이스에서 사용하는 논리적 내부 타임스탬프입니다. SCN은 트랜젝션의 ACID 속성을 충족하는 데 필요한 (데이터베이스 내부에서 발생하는)이벤트를 배열합니다. Oracle 데이터베이스는 SCN를 사용하여 디스크에 작성된 모든 변화가 진행된 위치를 표시합니다. 그리하여 복원 작업이 이미 작성된 변경 사항을 적용하지 않습니다. Oracle은 또한 SCN을 사용하여 복구가 중지되지 않도록 데이터 세트에 다시 실행이 없는 지점을 표시합니다.

다음을 실행해 Oracle 데이터베이스의 현재 SCN을 가져옵니다.

SELECT CURRENT_SCN FROM V$DATABASE

현재 SCN을 사용하여 CDC 작업을 시작하는 경우 열려 있는 트랜잭션의 결과를 놓치고 이러한 결과를 마이그레이션하지 못합니다. 열기 트랜잭션는 이전에 시작되었지만 아직 커밋되지 않은 트랜잭션입니다. SCN과 타임스탬프를 식별하여 열려 있는 모든 트랜잭션이 포함된 지점에서 CDC 작업을 시작할 수 있습니다. 자세한 내용은 단원을 참조하십시오.트랜잭션Oracle 온라인 설명서에 나와 있습니다.

MySQL

MySQL 버전 5.6.3이 출시되기 전에는 MySQL 로그 시퀀스 번호(LSN)는 4바이트의 부호 없는 정수였습니다. 다시 실행 로그 파일 크기 한도가 4GB에서 512GB로 증가한 MySQL 5.6.3부터 LSN이 8바이트의 부호 없는 정수가 되었습니다. 추가 사이즈 정보를 저장하기 위해 증가되면 바이트 추가가 요청됩니다. LSN 값을 사용하는 MySQL 5.6.3 이후 버전에 빌드된 애플리케이션은 LSN 값을 저장해 비교하기 위해 32비트 대신 64비트 변수를 사용해야 합니다. MySQL LSN에 대한 자세한 내용은 MySQL 설명서를 참조하십시오.

다음 명령을 실행해 MySQL 데이터베이스의 현재 LSN을 가져옵니다.

mysql> show master status;

쿼리는 binlog 파일 이름, 위치 및 기타 값을 반환합니다. CDC 네이티브 시작 지점은 binlogs 파일 이름과 위치가 조합되어 있습니다. 예를 들어, mysql-bin-changelog.000024:373입니다. 이 예제에서 mysql-bin-changelog.000024는 binlogs 파일 이름이고, 373은 AWS DMS가 변경 캡처를 시작하는 데 필요한 위치입니다.

체크포인트를 CDC 시작 지점으로 사용

지속적 복제 작업이 변경 사항을 마이그레이션하고 AWS DMS는 AWS DMS에 대한 체크포인트 정보를 캐싱하는 경우가 있습니다. AWS DMS가 생성한 체크포인트에는 정보가 포함되어 있으므로 복제 엔진이 변경 스트림의 복구 지점을 파악할 수 있습니다. 체크포인트를 사용하여 변경 타임라인으로 되돌아가거나 실패한 마이그레이션 작업을 복구합니다. 또한 이 체크포인트를 사용해 특정 시간에 다른 대상으로 다른 지속적 복제 작업을 시작할 수 있습니다.

다음 방법 중 하나로 체크포인트 정보를 얻을 수 있습니다.

  • API 작업 실행DescribeReplicationTasks결과를 검토합니다. 작업 별로 정보를 필터링을 하고, 체크포인트를 검색할 수 있습니다. 작업이 중지/실패 상태일 때 마지막 체크포인트를 검색할 수 있습니다. 작업이 삭제되면 이 정보는 없어집니다.

  • 대상 인스턴스에 awsdms_txn_state이라는 메타데이터를 봅니다. 테이블을 쿼리하여 체크포인트 정보를 얻을 수 있습니다. 메타데이터 테이블을 생성하기 위해서 작업을 생성할 때 TaskRecoveryTableEnabled 파라미터를 Yes로 설정합니다. 이 설정은 AWS DMS가 대상 메타데이터 테이블에 체크포인트 정보를 계속 기록하도록 합니다. 작업이 삭제되면 이 정보는 없어집니다.

    예를 들어, 다음은 메타데이터 테이블의 체크포인트 예입니다.checkpoint:V1#34#00000132/0F000E48#0#0#*#0#121

  • 탐색 창에서 다음을 선택합니다.데이터베이스 마이그레이션 작업를 클릭하고 데이터베이스 마이그레이션 작업 페이지에 나타나는 목록에서 상위 작업을 선택합니다. 개요 세부 정보가 표시된 상위 작업 페이지가 열립니다. 변경 데이터 캡처(CDC), 변경 데이터 캡처(CDC) 시작 위치 및 변경 데이터 캡처(CDC) 복구 체크포인트 아래에서 체크포인트 값을 찾습니다. 체크포인트 값은 다음과 유사합니다.

    checkpoint:V1#1#000004AF/B00000D0#0#0#*#0#0

커밋 또는 서버 시점에서 작업 중지

CDC 네이티브 시작 지점의 소개와 함께, AWS DMS는 다음 지점에서 작업을 중지할 수도 있습니다.

  • 소스의 약정 시간

  • 복제 인스턴스의 서버 시간

필요에 따라 작업을 중지할 수 있도록 작업을 수정하고 시간을 UTC로 설정할 수 있습니다. 설정한 약정 또는 서버 시간에 따라 작업은 자동적으로 중지됩니다. 또는 작업 생성 시 마이그레이션 작업을 중지할 적절한 시점을 알고 있다면 작업을 생성할 때 중지 시간을 설정할 수 있습니다.

양방향 복제 수행

AWS DMS 작업을 사용하여 두 시스템 간에 양방향 복제를 수행할 수 있습니다. 양방향 복제에서는 두 시스템 간에 동일한 테이블(또는 테이블 집합)의 데이터를 두 방향 모두로 복제할 수 있습니다.

예를 들어 데이터베이스 A에서 데이터베이스 B로 EMPLOYEE 테이블을 복사하고 데이터베이스 A에서 데이터베이스 B로 테이블에 변경 사항을 복제할 수 있습니다. 또한 데이터베이스 B에서 A로 다시 EMPLOYEE 테이블에 변경 사항을 복제할 수 있습니다. 즉, 양방향 복제를 수행할 수 있습니다.

참고

AWS DMS 양방향 복제는 기본 노드, 충돌 해결 등을 포함해 완전한 멀티 마스터 솔루션으로 사용하기 위한 것은 아닙니다.

서로 다른 노드의 데이터가 운영상 분리되는 경우에 양방향 복제를 사용합니다. 즉, 노드 A에서 작동하는 애플리케이션에 의해 변경된 데이터 요소가 있고 노드 A가 노드 B와 양방향 복제를 수행하는 경우, 노드 A의 데이터 요소는 노드 B에서 작동하는 애플리케이션에 의해 변경되지 않습니다.

AWS DMS는 이러한 데이터베이스 엔진에서 양방향 복제를 지원합니다.

  • Oracle

  • SQL 서버

  • MySQL

  • PostgreSQL

  • Amazon Aurora MySQL-Compatible Edition

  • Aurora PostgreSQL 호환 버전

양방향 복제 작업 생성

AWS DMS 양방향 복제를 활성화하려면 두 데이터베이스(A 및 B)에 대해 소스 엔드포인트 및 대상 엔드포인트를 구성합니다. 예를 들어 데이터베이스 A의 소스 엔드포인트, 데이터베이스 B의 소스 엔드포인트, 데이터베이스 A의 대상 엔드포인트 및 데이터베이스 B의 대상 엔드포인트을 구성합니다.

그런 다음 두 가지 작업(데이터를 대상 B로 이동하기 위한 소스 A에 대한 작업과 데이터를 대상 A로 이동하기 위한 소스 B에 대한 작업)을 만듭니다. 또한 각 작업이 루프백 방지로 구성되어 있는지 확인합니다. 작업이 루프백 방지가 설정되어 있으면 동일한 변경 사항이 두 작업의 대상에 적용되지 않으므로 하나 이상의 작업에 대한 데이터가 손상됩니다. 자세한 정보는 루프백 방지을 참조하십시오.

가장 간단한 접근 방식은 데이터베이스 A와 데이터베이스 B 모두에서 동일한 데이터 세트로 시작합니다. 그런 다음 두 개의 CDC 전용 작업(A에서 B로 데이터를 복제하기 위한 작업과 B에서 A로 데이터를 복제하기 위한 작업)을 만듭니다.

노드 A에서 노드 B의 새 데이터 세트(데이터베이스)를 인스턴스화하는 데 AWS DMS를 사용하려면 다음을 수행합니다.

  1. 전체 로드 및 CDC 작업을 사용하여 데이터베이스 A에서 B로 데이터를 이동합니다. 이 때 데이터베이스 B의 데이터를 수정하는 애플리케이션이 없는지 확인합니다.

  2. 전체 로드가 완료되고 애플리케이션이 데이터베이스 B의 데이터를 수정할 수 있도록 허용되기 전에 데이터베이스 B의 시작 시간 또는 CDC 시작 위치를 기록해 둡니다. 자세한 내용은 CDC 시작 포인트에서 복제를 시작합니다. 단원을 참조하십시오.

  3. 이 시작 시간 또는 CDC 시작 위치를 사용하여 데이터베이스 B에서 A로 데이터를 다시 이동하는 CDC 전용 작업을 만듭니다.

참고

양방향 쌍에서 하나의 작업만 전체 로드 및 CDC일 수 있습니다.

루프백 방지

루프백 방지를 표시하기 위해, 작업 T1에서 AWS DMS가 원본 데이터베이스 A에서 변경 로그를 읽고 변경 사항을 대상 데이터베이스 B에 적용한다고 가정하겠습니다.

그런 다음 두 번째 작업 T2는 원본 데이터베이스 B에서 변경 로그를 읽고 변경 사항을 대상 데이터베이스 A에 다시 적용합니다. T2가 이를 수행하기 전에 DMS는 원본 데이터베이스 A의 대상 데이터베이스 B에 적용된 동일한 변경 사항이 원본 데이터베이스 A에 적용되지 않았는지 확인해야 합니다. 즉, DMS는 이러한 변경 사항이대상 데이터베이스 A로 다시 에코 (반복) 되지 않습니다. 그렇지 않으면 데이터베이스 A의 데이터가 손상될 수 있습니다.

변경 사항의 루프백을 방지하려면 각 양방향 복제 작업에 다음 작업 설정을 추가합니다. 이렇게 하면 루프백 데이터 손상이 어느 방향으로도 발생하지 않습니다.

{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention": Boolean, "SourceSchema": String, "TargetSchema": String }, . . . }

LoopbackPreventionSettings 작업 설정은 트랜잭션이 새 트랜잭션인지 또는 반대 복제 작업의 에코인지를 결정합니다. AWS DMS가 대상 데이터베이스에 트랜잭션을 적용하면 변경 표시와 함께 DMS 테이블(awsdms_loopback_prevention)을 갱신됩니다. 각 트랜잭션을 대상에 적용하기 전에 DMS는 이 awsdms_loopback_prevention 테이블에 대한 참조를 포함하는 모든 트랜잭션을 무시합니다. 따라서 변경 사항이 적용되지 않습니다.

양방향 쌍으로 된 각 복제 작업에 이러한 작업 설정을 포함합니다. 이러한 설정은 루프백 방지를 활성화합니다. 또한 각 엔드포인트에 대한 awsdms_loopback_prevention 테이블을 포함하는 작업의 각 원본 데이터베이스 및 대상 데이터베이스에 대한 스키마를 지정합니다.

각 작업에서 이러한 에코를 식별하고 무시하도록 하려면 EnableLoopbackPreventiontrue로 설정합니다. awsdms_loopback_prevention을 포함하는 소스에서 스키마를 지정하려면 SourceSchema를 원본 데이터베이스의 해당 스키마 이름으로 설정합니다. 동일한 테이블을 포함하는 대상에서 스키마를 지정하려면 TargetSchema를 대상 데이터베이스의 해당 스키마 이름으로 설정합니다.

다음 예제에서는 복제 작업 T1 및 해당 반대 복제 작업 T2에 대한 SourceSchemaTargetSchema 설정이 반대 설정으로 지정됩니다.

작업 T1에 대한 설정은 다음과 같습니다.

{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention": true, "SourceSchema": "LOOP-DATA", "TargetSchema": "loop-data" }, . . . }

반대 작업 T2에 대한 설정은 다음과 같습니다.

{ . . . "LoopbackPreventionSettings": { "EnableLoopbackPrevention": true, "SourceSchema": "loop-data", "TargetSchema": "LOOP-DATA" }, . . . }
참고

AWS CLI를 사용할 때는 create-replication-task 또는 modify-replication-task 명령만 사용하여 양방향 복제 작업에서 LoopbackPreventionSettings를 구성합니다.

양방향 복제의 제한 사항

AWS DMS에 대한 양방향 복제에는 다음과 같은 제한 사항이 있습니다.

  • 루프백 방지는 데이터 조작 언어(DML) 문만 추적합니다. AWS DMS는 데이터 정의 언어(DDL) 루프백 방지를 지원하지 않습니다. 이렇게 하려면 양방향 쌍의 작업 중 하나를 구성하여 DDL 문을 필터링합니다.

  • 루프백 방지를 사용하는 작업은 배치로 변경 사항을 커밋하는 것을 지원하지 않습니다. 루프백 방지로 작업을 구성하려면 BatchApplyEnabledfalse로 설정해야 합니다.

  • DMS 양방향 복제에는 충돌 감지 또는 충돌 해결이 포함되지 않습니다. 데이터 불일치를 감지하려면 두 작업 모두에서 데이터 검증을 사용합니다.