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)에 따라 온라인 또는 아카이브 redo 로그에서 지속적 변경 사항을 읽습니다.

• 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시간이면 충분) 소스 데이터베이스가 변경 로그를 유지하도록 구성하는 것이 좋습니다. 엔드포인트에 대한 특정 설정은 다음을 참조하세요.

  • Amazon RDS for Oracle: AWS관리형 Oracle 소스 구성 대상 AWS DMS.

  • Amazon RDS for MySQL 및 Aurora MySQL: AWS DMS 소스로 AWS 관리형 MySQL 호환 데이터베이스 사용.

  • Amazon RDS for SQL Server: 클라우드 SQL Server DB 인스턴스에서 지속적 복제 설정.

  • Amazon RDS for PostgreSQL 및 Aurora PostgreSQL: PostgreSQL은 필요한 WAL을 자동으로 유지합니다.

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

• 전체 로드+CDC – 이 작업은 기존 데이터를 마이그레이션한 다음, 소스 데이터베이스의 변경 내용을 기반으로 대상 데이터베이스를 업데이트합니다.

• CDC만 해당 – 대상 데이터베이스에 데이터를 확보한 후 진행 중인 변경 내용을 마이그레이션하는 작업입니다.

CDC 시작 지점에서 복제를 시작

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

• 사용자 지정 CDC 시작 시간부터 – AWS Management Console 또는 AWS CLI를 사용하여 복제를 시작하고 싶은 지점에 타임스탬프로 AWS DMS를 제공합니다. AWS DMS는 사용자 지정 CDC 시작 시간부터 지속적 복제 작업을 시작합니다. AWS DMS는 주어진 타임스탬프(UTC 시간)를 SQL 서버용 LSN 또는 Oracle용 SCN과 같은 기본 시작점으로 변환합니다. AWS DMS는 엔진별 방법을 사용하여 소스 엔진의 변경 스트림에 따른 마이그레이션 작업을 어디서 시작할지 결정합니다.

  참고

  StartFromContext 연결 속성을 필수 타임스탬프로 설정해야만 원본인 Db2는 사용자 지정된 CDC 시작 시간을 제공할 수 있습니다.

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

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

  • SQL Server

  • PostgreSQL

  • Oracle

  • MySQL

  • MariaDB

작업이 생성되면 AWS DMS는 CDC 시작 지점을 표시하며 이 시작 지점은 변경할 수 없습니다. 다른 CDC 시작 지점을 사용하려면 새 작업을 만드세요.

CDC 기본 시작점 결정

CDC 기본 시작점은 CDC를 시작할 수 있는 시간을 정의하는 데이터베이스 엔진 로그의 지점입니다. 예를 들어, 대량 데이터 덤프가 이미 대상에 적용된 경우를 생각해볼 수 있습니다. 진행 중인 복제 전용 작업의 기본 시작점을 찾아볼 수 있습니다. 데이터 불일치를 방지하려면 복제 전용 작업의 시작 지점을 신중하게 선택하십시오. DMS는 선택한 CDC 시작 지점 이후에 시작된 트랜잭션을 캡처합니다.

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

SQL Server

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

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

• 로그 블록의 시작 오프셋

• 슬롯 번호

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

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

SQL Server에서 CDC 기본 시작점을 사용하려면 진행 중인 복제에 참여하는 테이블에 게시를 만드십시오. AWS DMS는 CDC 기본 시작점을 사용하지 않고 CDC를 사용하면 자동으로 간행물을 만듭니다.

PostgreSQL

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

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

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

1. AWS Management Console에 로그인하고 https://console.aws.amazon.com/dms/v2/에서 AWS DMS 콘솔을 엽니다.

   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 작업을 만드는 방법에 관한 자세한 내용은 AWS DMS를 사용하여 AWS 관리형 PostgreSQL DB 인스턴스에서 CDC 활성화 단원을 참조하십시오.

Oracle

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

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

SELECT CURRENT_SCN FROM V$DATABASE

SCN 또는 타임스탬프를 사용하여 CDC 작업을 시작하면 열린 트랜잭션의 결과를 놓치고 해당 결과를 마이그레이션하지 못하게 됩니다. 열린 트랜잭션은 작업 시작 지점 이전에 시작되고 작업 시작 지점 이후에 커밋된 트랜잭션입니다. SCN과 타임스탬프를 식별하여 모든 열린 트랜잭션이 포함된 시점에서 CDC 작업을 시작할 수 있습니다. 자세한 내용은 Oracle 온라인 설명서의 트랜잭션을 참조하세요. 버전 3.5.1 및 이후 버전에서는 SCN 또는 타임스탬프를 사용하여 작업을 시작하는 경우 AWS DMS가 openTransactionWindow 엔드포인트 설정을 사용하여 CDC 전용 작업에 대한 열린 트랜잭션을 지원합니다.

openTransactionWindow 설정을 사용할 때는 열린 트랜잭션을 처리할 수 있는 창을 분 단위로 제공해야 합니다. AWS DMS는 캡처 위치를 이동하고 새 위치를 찾아 데이터 캡처를 시작합니다. AWS DMS는 새 시작 위치를 사용하여 필수 Oracle redo 로그 또는 보관된 redo 로그에서 열린 트랜잭션을 모두 스캔합니다.

MySQL

MySQL 버전 5.6.3이 출시되기 전에는 MySQL 로그 시퀀스 번호(LSN)는 4바이트의 부호 없는 정수였습니다. redo 로그 파일 크기 한도가 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 서버리스 복제를 처음 시작할 때 모든 리소스를 초기화하는 데 최대 40분이 걸릴 수 있습니다. 단, 이 server_time 옵션은 리소스 초기화가 완료된 후에만 적용할 수 있습니다.

양방향 복제 수행

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

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

참고

AWS DMS 양방향 복제는 프라이머리 노드, 충돌 해결 등을 포함해 완전한 멀티 마스터 솔루션으로 사용할 수 없습니다.

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

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

• Oracle

• SQL Server

• MySQL

• PostgreSQL

• Amazon Aurora MySQL 호환 버전

• 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 테이블을 포함하는 작업의 각 소스 데이터베이스 및 대상 데이터베이스에 대한 스키마를 지정합니다.

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

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

작업 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 문을 필터링합니다.

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

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