다음을 통해 공유


트랜잭션 복제

적용 대상: SQL Server Azure SQL Database Azure SQL Managed Instance

트랜잭션 복제는 일반적으로 게시 데이터베이스 개체 및 데이터의 스냅샷으로 시작됩니다. 초기 스냅샷이 생성되는 즉시 게시자에서 수행된 후속 데이터 변경 및 스키마 수정은 대개 거의 실시간으로 구독자에게 전달됩니다. 데이터 변경 내용은 게시자에서 발생한 것과 동일한 순서 및 동일한 트랜잭션 경계 내에서 구독자에 적용됩니다. 따라서 게시 내에서 트랜잭션 일관성이 보장됩니다.

트랜잭션 복제는 일반적으로 서버 간 환경에 사용되며 다음과 같은 경우에 적합합니다.

  • 증분 변경 내용이 발생하면 구독자로 전파하려고 합니다.

  • 애플리케이션은 게시자에서 변경된 시간과 변경 내용이 구독자에 도착하는 시간 사이에 짧은 대기 시간이 필요합니다.

  • 애플리케이션은 중간 데이터 상태에 액세스해야 합니다. 예를 들어 행이 다섯 번 변경되면 트랜잭션 복제를 사용하면 애플리케이션이 단순히 행에 대한 순 데이터 변경이 아니라 각 변경 내용(예: 트리거 발생)에 응답할 수 있습니다.

  • 게시자에는 매우 많은 양의 삽입, 업데이트 및 삭제 작업이 있습니다.

  • 게시자 또는 구독자가 Oracle처럼 비 SQL Server 데이터베이스입니다.

기본적으로 트랜잭션 게시 구독자는 변경 내용이 게시자로 다시 전파되지 않으므로 읽기 전용으로 처리되어야 합니다. 그러나 트랜잭션 복제는 구독자에서 업데이트를 허용하는 옵션을 제공합니다.

참고 항목

Azure SQL Managed Instance는 스냅샷 및 트랜잭션 복제를 위한 게시자, 배포자 및 구독자일 수 있습니다. Azure SQL Database의 데이터베이스는 스냅샷과 트랜잭션 복제를 위한 밀어넣기 구독자만 될 수 있습니다. 자세한 내용은 Azure SQL 데이터베이스Azure SQL Managed Instance를 사용하는 트랜잭션 복제를 참조하세요.

트랜잭션 복제 작동 방법

트랜잭션 복제는 SQL Server 스냅샷 에이전트, 로그 판독기 에이전트 및 배포 에이전트 의해 구현됩니다. 스냅샷 에이전트는 게시된 테이블 및 데이터베이스 개체의 스키마 및 데이터를 포함하는 스냅샷 파일을 준비하며, 스냅샷 폴더에 스냅샷 파일을 저장하고 배포자의 배포 데이터베이스에 동기화 작업을 기록합니다.

로그 판독기 에이전트는 트랜잭션 복제를 위해 구성된 각 데이터베이스의 트랜잭션 로그를 모니터링하고 트랜잭션 로그에서 복제하도록 표시된 트랜잭션을 안정적인 저장 및 전달 큐 역할을 하는 배포 데이터베이스로 복사합니다. 배포 에이전트 스냅샷 폴더의 초기 스냅샷 파일과 배포 데이터베이스 테이블에 보관된 트랜잭션을 구독자에게 복사합니다.

게시자 흐름에서 배포 에이전트 일정에 따라 구독자에 대한 증분 변경으로, 대기 시간을 최소화하거나 예약된 간격으로 지속적으로 실행할 수 있습니다. 게시자에서 데이터를 변경해야 하므로(즉시 업데이트하거나 지연된 업데이트 옵션 없이 트랜잭션 복제를 사용하는 경우) 업데이트 충돌이 방지됩니다. 궁극적으로 모든 구독자는 게시자와 동일한 값을 얻을 수 있습니다. 즉시 업데이트 또는 대기 중인 업데이트 옵션을 트랜잭션 복제와 함께 사용하는 경우 구독자에서 업데이트를 수행할 수 있으며 지연 업데이트로 인해 충돌이 발생할 수 있습니다.

다음 그림에서는 트랜잭션 복제의 주 구성 요소를 보여 줍니다.

데이터 동기화 구성 요소 및 데이터 흐름

초기 데이터 세트

새 트랜잭션 복제 구독자가 게시자에서 증분 변경 내용을 받으려면 구독자의 테이블에 게시자의 테이블과 같은 스키마 및 데이터가 포함되어야 합니다. 초기 데이터 세트는 일반적으로 스냅샷 에이전트에서 만들고 배포 에이전트에서 배포 및 적용한 스냅샷입니다. 초기 데이터 세트는 백업 또는 SQL Server Integration Services와 같은 다른 수단을 통해 제공할 수도 있습니다.

스냅샷이 배포되어 구독자에 적용되는 경우 초기 스냅샷을 기다리는 구독자만 영향을 받습니다. 해당 게시의 다른 구독자(이미 초기화된 구독자)는 영향을 받지 않습니다.

동시 스냅샷 처리

스냅샷 복제는 스냅샷을 생성하는 동안 복제의 일부로 게시된 모든 테이블에 공유 잠금을 배치합니다. 이렇게 하면 게시 테이블에 대한 업데이트가 수행되지 않도록 할 수 있습니다. 트랜잭션 복제의 기본값인 동시 스냅샷 처리는 전체 스냅샷 생성 중에 공유 잠금을 유지하지 않으므로 복제에서 초기 스냅샷 파일을 만드는 동안 사용자가 중단 없이 작업을 계속할 수 있습니다.

스냅샷 에이전트

스냅샷 에이전트 트랜잭션 복제에서 초기 스냅샷을 구현하는 절차는 스냅샷 복제에 사용되는 것과 동일한 프로시저입니다(동시 스냅샷 처리와 관련하여 위에서 설명한 경우 제외).

스냅샷 파일이 생성되면 Microsoft Windows 탐색기를 사용하여 스냅샷 폴더에서 볼 수 있습니다.

데이터 수정 및 로그 판독기 에이전트

로그 판독기 에이전트는 배포자에서 실행됩니다. 일반적으로 지속적으로 실행되지만 설정한 일정에 따라 실행할 수도 있습니다. 실행할 때 로그 판독기 에이전트는 먼저 게시 트랜잭션 로그(일반 SQL Server 데이터베이스 엔진 작업 중 트랜잭션 추적 및 복구에 사용되는 동일한 데이터베이스 로그)를 읽고 INSERT, UPDATE 및 DELETE 문 또는 복제용으로 표시된 트랜잭션의 데이터에 대한 기타 수정 사항을 식별합니다. 다음으로 에이전트는 이러한 트랜잭션을 배포자의 배포 데이터베이스에 일괄 처리로 복사합니다. 로그 판독기 에이전트는 내부 저장 프로시저 sp_replcmds 사용하여 로그에서 복제하도록 표시된 다음 명령 집합을 가져옵니다. 그러면 배포 데이터베이스는 변경 내용이 구독자에게 전송되는 저장소 및 전달 큐가 됩니다. 커밋된 트랜잭션만 배포 데이터베이스로 전송됩니다.

전체 트랜잭션 일괄 처리는 배포 데이터베이스로 성공적으로 기록된 다음 커밋됩니다. 배포자에 대한 각 명령 일괄 처리가 커밋되면 로그 판독기 에이전트는 sp_repldone 을 호출하여 복제가 마지막으로 완료된 곳을 표시합니다. 마지막으로 에이전트는 제거할 준비가 된 트랜잭션 로그의 행을 표시합니다. 복제 대기 중인 행은 제거되지 않습니다.

트랜잭션 명령은 모든 구독자에게 전파되거나 최대 배포 보존 기간에 도달할 때까지 배포 데이터베이스에 저장됩니다. 구독자는 게시자에서 적용된 것과 동일한 순서로 트랜잭션을 받습니다.

배포 에이전트

배포 에이전트는 밀어넣기 구독을 위한 배포자 또는 끌어오기 구독을 위한 구독자에서 실행됩니다. 에이전트는 배포 데이터베이스에서 구독자로 트랜잭션을 이동합니다. 구독이 유효성 검사를 위해 표시된 경우 배포 에이전트 게시자와 구독자의 데이터가 일치하는지 여부도 확인합니다.

게시 유형

트랜잭션 복제는 다음과 같은 네 가지 게시 유형을 제공합니다.

게시 유형 설명
표준 트랜잭션 게시 구독자의 모든 데이터가 읽기 전용인 토폴로지에 적합합니다(트랜잭션 복제는 구독자에서 이를 적용하지 않음).

표준 트랜잭션 게시는 Transact-SQL 또는 RMO(복제 관리 개체)를 사용할 때 기본적으로 만들어집니다. 새 게시 마법사를 사용하는 경우 게시 유형 페이지에서 트랜잭션 게시를 선택하여 만들어집니다.

게시를 만드는 방법은 데이터 및 데이터베이스 개체 게시를 참조하세요.
업데이트 가능 구독이 있는 트랜잭션 게시 이 형식의 특성은 다음과 같습니다.

-각 위치에는 하나의 게시자와 하나의 구독자가 동일한 데이터를 가지고 있습니다.
-구독자에서 행을 업데이트할 수 있습니다.
-이 토폴로지는 고가용성 및 읽기 확장성이 필요한 서버 환경에 가장 적합합니다.

자세한 내용은 업데이트 가능 구독을 참조하세요.
피어 투 피어 토폴로지 이 형식의 특성은 다음과 같습니다.
- 각 위치가 동일한 데이터를 가지며 게시자와 구독자 역할을 합니다.
- 같은 행은 한 번에 한 위치에서만 변경될 수 있습니다.
- 충돌 검색 지원
- 이 토폴로지는 고가용성 및 읽기 확장성이 필요한 서버 환경에 가장 적합합니다.

자세한 내용은 피어 투 피어 트랜잭션 복제를 참조하세요.
양방향 트랜잭션 복제 이 형식의 특성은 다음과 같습니다.
양방향 복제는 피어 투 피어 복제와 유사합니다. 그러나 충돌 해결을 제공하지는 않습니다. 또한 양방향 복제는 2개의 서버로 제한됩니다.

자세한 내용은 양방향 트랜잭션 복제를 참조하세요.