트랜잭션 복제Transactional Replication

트랜잭션 복제는 일반적으로 게시 데이터베이스 개체 및 데이터의 스냅숏으로 시작됩니다.Transactional replication typically starts with a snapshot of the publication database objects and data. 일반적으로 초기 스냅숏이 사용되자마자 게시자에서의 후속 데이터 변경 내용 및 스키마 수정 내용이 구독자로 배달됩니다. 이러한 작업은 거의 실시간으로 수행됩니다.As soon as the initial snapshot is taken, subsequent data changes and schema modifications made at the Publisher are usually delivered to the Subscriber as they occur (in near real time). 데이터 변경 내용은 게시자에서 발생한 것과 같은 순서 및 같은 트랜잭션 경계 내에서 구독자에 적용되므로 게시 내에서는 트랜잭션 일관성이 보장됩니다.The data changes are applied to the Subscriber in the same order and within the same transaction boundaries as they occurred at the Publisher; therefore, within a publication, transactional consistency is guaranteed.

트랜잭션 복제는 일반적으로 서버 간 환경에 사용되며 다음과 같은 경우에 적합합니다.Transactional replication is typically used in server-to-server environments and is appropriate in each of the following cases:

  • 증분 변경 내용을 발생과 동시에 구독자로 전파하려고 합니다.You want incremental changes to be propagated to Subscribers as they occur.

  • 응용 프로그램이 게시자에서 변경이 수행된 시점과 해당 변경 내용이 구독자에 도달한 시점 간의 짧은 대기 시간이 필요합니다.The application requires low latency between the time changes are made at the Publisher and the changes arrive at the Subscriber.

  • 응용 프로그램이 중간 데이터 상태에 액세스해야 합니다.The application requires access to intermediate data states. 예를 들어 한 행이 5번 변경될 경우 트랜잭션 복제를 사용하면 응용 프로그램은 행의 실질적인 데이터 변경만이 아닌 모든 변경(예: 트리거 실행)에 응답할 수 있습니다.For example, if a row changes five times, transactional replication allows an application to respond to each change (such as firing a trigger), not simply the net data change to the row.

  • 게시자가 많은 양의 삽입, 업데이트 및 삭제 작업을 수행합니다.The Publisher has a very high volume of insert, update, and delete activity.

  • 게시자 또는 구독자가 Oracle과 같은 SQL ServerSQL Server 이외의 데이터베이스입니다.The Publisher or Subscriber is a non- SQL ServerSQL Server database, such as Oracle.

    기본적으로 변경 내용은 게시자로 다시 전파되지 않기 때문에 트랜잭션 게시에 대한 구독자는 읽기 전용으로 취급됩니다.By default, Subscribers to transactional publications should be treated as read-only, because changes are not propagated back to the Publisher. 그러나 트랜잭션 복제는 구독자의 업데이트를 허용하는 다양한 옵션을 제공합니다.However, transactional replication does offer options that allow updates at the Subscriber.

    항목 내용In This Topic

    트랜잭션 복제 작동 방법How Transactional Replication Works

    초기 데이터 집합Initial Dataset

    스냅숏 에이전트Snapshot Agent

    로그 판독기 에이전트Log Reader Agent

    배포 에이전트Distribution Agent

트랜잭션 복제 작동 방법 How Transactional Replication Works

SQL ServerSQL Server 스냅숏 에이전트, 로그 판독기 에이전트 및 배포 에이전트가 트랜잭션 복제를 구현합니다.Transactional replication is implemented by the SQL ServerSQL Server Snapshot Agent, Log Reader Agent, and Distribution Agent. 스냅숏 에이전트는 게시된 테이블과 데이터베이스 개체의 스키마 및 데이터를 포함하는 스냅숏 파일을 준비하여 스냅숏 폴더에 저장하고 배포자의 배포 데이터베이스에 동기화 작업을 기록합니다.The Snapshot Agent prepares snapshot files containing schema and data of published tables and database objects, stores the files in the snapshot folder, and records synchronization jobs in the distribution database on the Distributor.

로그 판독기 에이전트는 트랜잭션 복제를 위해 구성한 각 데이터베이스의 트랜잭션 로그를 모니터링하고 복제용으로 표시된 트랜잭션을 트랜잭션 로그에서 배포 데이터베이스로 복사하여 안정적인 저장 후 전달 큐 역할을 합니다.The Log Reader Agent monitors the transaction log of each database configured for transactional replication and copies the transactions marked for replication from the transaction log into the distribution database, which acts as a reliable store-and-forward queue. 배포 에이전트는 스냅숏 폴더의 초기 스냅숏 파일과 배포 데이터베이스 테이블의 트랜잭션을 구독자로 복사합니다.The Distribution Agent copies the initial snapshot files from the snapshot folder and the transactions held in the distribution database tables to Subscribers.

게시자에서 적용한 증분 변경 내용은 최소한의 대기 시간을 위해 계속 실행하거나 예약된 간격마다 실행할 수 있는 배포 에이전트의 일정에 따라 구독자로 이동할 수 있습니다.Incremental changes made at the Publisher flow to Subscribers according to the schedule of the Distribution Agent, which can run continuously for minimal latency, or at scheduled intervals. 즉시 업데이트 또는 지연 업데이트 옵션 없이 트랜잭션 복제를 사용하는 경우 게시자에서 데이터를 변경해야 하기 때문에 업데이트 충돌이 방지됩니다.Because changes to the data must be made at the Publisher (when transactional replication is used without immediate updating or queued updating options), update conflicts are avoided. 최종적으로 모든 구독자는 게시자와 같은 값을 갖게 됩니다.Ultimately, all Subscribers will achieve the same values as the Publisher. 즉시 업데이트 또는 지연 업데이트 옵션을 트랜잭션 복제와 함께 사용하면 구독자에서 업데이트를 할 수 있고 지연 업데이트의 경우에는 충돌이 발생할 수 있습니다.If immediate updating or queued updating options are used with transactional replication, updates can be made at the Subscriber, and with queued updating, conflicts might occur.

다음 그림에서는 트랜잭션 복제의 주요 구성 요소를 보여 줍니다.The following illustration shows the principal components of transactional replication.

트랜잭션 복제 구성 요소 및 데이터 흐름Transactional replication components and data flow

초기 데이터 집합 Initial Dataset

새 트랜잭션 복제 구독자가 게시자에서 증분 변경 내용을 받으려면 구독자의 테이블에 게시자의 테이블과 같은 스키마 및 데이터가 포함되어야 합니다.Before a new transactional replication Subscriber can receive incremental changes from a Publisher, the Subscriber must contain tables with the same schema and data as the tables at the Publisher. 초기 데이터 집합은 일반적으로 스냅숏 에이전트에서 만들고 배포 에이전트에서 배포 및 적용한 스냅숏입니다.The initial dataset is typically a snapshot that is created by the Snapshot Agent and distributed and applied by the Distribution Agent. 초기 데이터 집합은 백업이나 SQL ServerSQL Server Integration Services와 같은 다른 방법으로 지정할 수도 있습니다.The initial dataset can also be supplied through a backup or other means, such as SQL ServerSQL Server Integration Services.

스냅숏을 구독자에게 배포 및 적용한 경우 초기 스냅숏을 기다리는 구독자만 영향을 받습니다.When snapshots are distributed and applied to Subscribers, only those Subscribers waiting for initial snapshots are affected. 해당 게시에 대한 다른 구독자(이미 초기화된 구독자)는 영향을 받지 않습니다.Other Subscribers to that publication (those that have already been initialized) are unaffected.

동시 스냅숏 처리Concurrent Snapshot Processing

스냅숏 복제는 스냅숏을 생성하는 동안 복제의 일부로 게시된 모든 테이블에 공유 잠금을 배치합니다.Snapshot replication places shared locks on all tables published as part of replication for the duration of snapshot generation. 이렇게 하면 업데이트가 게시 중인 테이블에서 이루어지는 것을 방지할 수 있습니다.This can prevent updates from being made on the publishing tables. 트랜잭션 복제의 기본값인 동시 스냅숏 처리는 전체 스냅숏 생성 과정 동안 공유 잠금을 보유하지 않기 때문에 복제에서 초기 스냅숏 파일을 만드는 동안 사용자는 중단 없이 작업을 계속할 수 있습니다.Concurrent snapshot processing, the default with transactional replication, does not hold the share locks in place during the entire snapshot generation, which allows users to continue working uninterrupted while replication creates initial snapshot files.

스냅숏 에이전트 Snapshot Agent

스냅숏 에이전트가 트랜잭션 복제에서 초기 스냅숏을 구현하는 프로시저는 스냅숏 복제에서 사용하는 프로시저와 같습니다. 앞에서 설명한 것처럼 동시 스냅숏 처리에 대해서는 제외합니다.The procedures by which the Snapshot Agent implements the initial snapshot in transactional replication are the same procedures used in snapshot replication (except as outlined above with regard to concurrent snapshot processing).

스냅숏 파일을 만든 후 MicrosoftMicrosoft Windows 탐색기를 사용하여 스냅숏 폴더에서 해당 파일을 볼 수 있습니다.After the snapshot files have been generated, you can view them in the snapshot folder using MicrosoftMicrosoft Windows Explorer.

데이터 수정 및 로그 판독기 에이전트 Modifying Data and the Log Reader Agent

로그 판독기 에이전트는 배포자에서 실행됩니다. 일반적으로 로그 판독기 에이전트는 계속해서 실행되지만 사용자가 설정한 일정에 따라 실행할 수도 있습니다.The Log Reader Agent runs at the Distributor; it typically runs continuously, but can also run according to a schedule you establish. 로그 판독기 에이전트는 실행 시 먼저 게시의 트랜잭션 로그(일반 SQL ServerSQL Server 데이터베이스 엔진 작업 중 트랜잭션 추적 및 복구에 사용되는 것과 같은 데이터베이스 로그)를 읽고 INSERT, UPDATE 및 DELETE 문 또는 복제용으로 표시된 트랜잭션의 데이터에 대한 다른 수정 사항을 식별합니다.When executing, the Log Reader Agent first reads the publication transaction log (the same database log used for transaction tracking and recovery during regular SQL ServerSQL Server Database Engine operations) and identifies any INSERT, UPDATE, and DELETE statements, or other modifications made to the data in transactions that have been marked for replication. 그 다음 에이전트는 일괄 작업으로 이러한 트랜잭션을 배포자의 배포 데이터베이스로 복사합니다.Next, the agent copies those transactions in batches to the distribution database at the Distributor. 로그 판독기 에이전트는 sp_replcmds 내부 저장 프로시저를 사용하여 복제용으로 표시된 다음 명령 집합을 로그에서 가져옵니다.The Log Reader Agent uses the internal stored procedure sp_replcmds to get the next set of commands marked for replication from the log. 그 다음 배포 데이터베이스는 변경 내용을 구독자로 전달하는 저장 후 전달 큐가 됩니다.The distribution database then becomes the store-and-forward queue from which changes are sent to Subscribers. 커밋된 트랜잭션만 배포 데이터베이스로 전달됩니다.Only committed transactions are sent to the distribution database.

전체 트랜잭션 일괄 처리는 배포 데이터베이스로 성공적으로 기록된 다음 커밋됩니다.After the entire batch of transactions has been written successfully to the distribution database, it is committed. 배포자에 대한 각 명령 일괄 처리가 커밋되면 로그 판독기 에이전트는 sp_repldone 을 호출하여 복제가 마지막으로 완료된 곳을 표시합니다.Following the commit of each batch of commands to the Distributor, the Log Reader Agent calls sp_repldone to mark where replication was last completed. 마지막으로 이 에이전트는 트랜잭션 로그에서 제거할 행을 표시합니다.Finally, the agent marks the rows in the transaction log that are ready to be purged. 복제되기를 계속 기다리는 행은 제거되지 않습니다.Rows still waiting to be replicated are not purged.

트랜잭션 명령은 모든 구독자에게 전파되거나 최대 배포 보존 기간에 도달할 때까지 배포 데이터베이스에 저장됩니다.Transaction commands are stored in the distribution database until they are propagated to all Subscribers or until the maximum distribution retention period has been reached. 게시자에서 적용된 것과 같은 순서로 구독자는 트랜잭션을 받습니다.Subscribers receive transactions in the same order in which they were applied at the Publisher.

배포 에이전트 Distribution Agent

배포 에이전트는 밀어넣기 구독을 위한 배포자 또는 끌어오기 구독을 위한 구독자에서 실행됩니다.The Distribution Agent runs at the Distributor for push subscriptions and at the Subscriber for pull subscriptions. 이 에이전트는 트랜잭션을 배포 데이터베이스에서 구독자로 이동합니다.The agent moves transactions from the distribution database to the Subscriber. 구독이 유효성 검사용으로 표시된 경우에 배포 에이전트는 게시자와 구독자의 데이터가 일치하는지 확인하는 작업도 수행합니다.If a subscription is marked for validation, the Distribution Agent also checks whether data at the Publisher and Subscriber match.