로그 전달 및 복제(SQL Server)Log Shipping and Replication (SQL Server)

로그 전달에는 일반적으로 서로 다른 컴퓨터에 있는 두 개의 단일 데이터베이스 복사본이 사용됩니다.Log shipping involves two copies of a single database that typically reside on different computers. 클라이언트는 항상 하나의 데이터베이스 복사본만 사용할 수 있습니다.At any given time, only one copy of the database is currently available to clients. 이 복사본을 주 데이터베이스라고 합니다.This copy is known as the primary database. 클라이언트가 주 데이터베이스에 업데이트한 내용은 로그 전달을 사용하여 보조 데이터베이스라고 부르는 다른 데이터베이스 복사본에 전달됩니다.Updates made by clients to the primary database are propagated by means of log shipping to the other copy of the database, known as the secondary database. 로그 전달에는 주 데이터베이스에 대해 수행된 모든 삽입, 업데이트 또는 삭제 작업의 트랜잭션 로그를 보조 데이터베이스에 적용하는 작업이 포함됩니다.Log shipping involves applying the transaction log from every insertion, update, or deletion made on the primary database onto the secondary database.

로그 전달은 다음과 같은 동작의 경우 복제와 함께 사용될 수 있습니다.Log shipping can be used in conjunction with replication, with the following behavior:

  • 로그 전달 장애 조치(Failover) 이후에는 복제가 계속되지 않습니다.Replication does not continue after a log shipping failover. 장애 조치가 발생하면 복제 에이전트가 보조 데이터베이스에 연결하지 않기 때문에 트랜잭션이 구독자에 복제되지 않습니다.If a failover occurs, replication agents do not connect to the secondary, so transactions are not replicated to Subscribers. 주 서버에 대한 장애 복구(Failback)가 발생하면 복제가 다시 시작됩니다.If a failback to the primary occurs, replication resumes. 로그 전달이 보조 서버에서 주 서버로 복사하는 모든 트랜잭션이 구독자에 복제됩니다.All transactions that log shipping copies from the secondary back to the primary are replicated to Subscribers.

  • 주 서버가 영구적으로 손실되면 보조 서버 이름을 바꿔서 복제를 계속할 수 있습니다.If the primary is permanently lost, the secondary can be renamed so that replication can continue. 이 항목의 남은 부분에서는 이러한 경우를 처리하기 위한 요구 사항과 절차에 대해 설명합니다.The remainder of this topic describes the requirements and procedures for handling this case. 제공된 예는 로그 전달에서 가장 일반적인 게시 데이터베이스이지만 구독 및 배포 데이터베이스에 더 간단한 프로세스를 적용할 수도 있습니다.The example given is the publication database, which is the most common database to log ship, but a similar process can also be applied to subscription and distribution databases.

    복제를 다시 구성할 필요 없이 복제에 관련된 데이터베이스를 복구하는 방법은 복제된 데이터베이스 백업 및 복원을 참조하세요.For information about recovering databases involved in replication without any need to reconfigure replication, see Back Up and Restore Replicated Databases.

참고

게시 데이터베이스의 가용성을 높이기 위해서는 로그 전달 대신 데이터베이스 미러링을 사용하는 것이 좋습니다.We recommend using database mirroring, rather than log shipping, to provide availability for the publication database. 자세한 내용은 데이터베이스 미러링 및 복제(SQL Server)을 참조하세요.For more information, see Database Mirroring and Replication (SQL Server).

주 서버가 손실된 경우 보조 서버로부터 복제하기 위한 요구 사항 및 절차Requirements and Procedures for Replicating from the Secondary If the Primary Is Lost

다음 요구 사항과 고려 사항에 주의하십시오.Be aware of the following requirements and considerations:

  • 주 서버에 하나 이상의 게시 데이터베이스가 포함된 경우 모든 게시 데이터베이스의 로그를 동일한 보조 서버로 전달합니다.If a primary contains more than one publication database, log ship all of the publication databases to the same secondary.

  • 보조 서버 인스턴스의 설치 경로는 주 서버와 동일해야 합니다.The installation path for the secondary server instance must be the same as the primary. 보조 서버의 사용자 데이터베이스 위치는 주 서버와 동일해야 합니다.User database locations on the secondary server must be the same as on the primary.

  • 주 서버에서 서비스 마스터 키를 백업합니다.Back up the service master key at the primary. 이 키는 보조 서버에서 복원됩니다.This key will be restored at the secondary. 자세한 내용은 BACKUP SERVICE MASTER KEY(Transact-SQL)를 참조하세요.For more information, see BACKUP SERVICE MASTER KEY (Transact-SQL).

  • 로그 전달은 데이터 손실 방지를 보장하지 않습니다.Log shipping does not guarantee against data loss. 보조 데이터베이스에 오류가 발생하면 아직 백업되지 않은 데이터가 손실되거나 오류 중에 손실된 백업의 데이터가 손실될 수 있습니다.A failure on the primary database can result in the loss of data that has not yet been backed up or for backups that are lost during the failure.

트랜잭션 복제의 로그 전달Log Shipping with Transactional Replication

트랜잭션 복제의 경우 로그 전달의 동작은 sync with backup 옵션에 따라 달라집니다.For transactional replication, the behavior of log shipping depends on the sync with backup option. 이 옵션은 게시 데이터베이스 및 배포 데이터베이스에 설정될 수 있으며, 게시자의 로드 전달의 경우에는 게시 데이터베이스의 설정만 관련이 있습니다.This option can be set on the publication database and distribution database; in log shipping for the Publisher, only the setting on the publication database is relevant.

게시 데이터베이스에 이 옵션을 설정하면 트랜잭션은 게시 데이터베이스에서 백업될 때까지 배포 데이터베이스로 배달되지 않습니다.Setting this option on the publication database ensures that transactions are not delivered to the distribution database until they are backed up at the publication database. 그러면 복원된 게시 데이터베이스에 없는 트랜잭션이 배포 데이터베이스에 있을 수 없으므로 보조 서버에서 마지막 게시 데이터베이스 백업을 복원할 수 있습니다.The last publication database backup can then be restored at the secondary server without any possibility of the distribution database having transactions that the restored publication database does not have. 이 옵션은 게시자가 보조 서버로 장애 조치되는 경우 게시자, 배포자 및 구독자 간의 일관성이 유지되도록 보장합니다.This option guarantees that if the Publisher fails over to a secondary server, consistency is maintained between the Publisher, Distributor, and Subscribers. 트랜잭션이 게시자에서 백업되기 전까지는 배포 데이터베이스로 트랜잭션을 전달할 수 없으므로 지연이 발생하거나 처리량이 줄어들 수 있습니다. 응용 프로그램에서 이러한 지연이 허용되는 경우 게시 데이터베이스에 이 옵션을 설정하는 것이 좋습니다.Latency and throughput are affected because transactions cannot be delivered to the distribution database until they have been backed up at the Publisher; if your application can tolerate this latency, we recommend that you set this option on the publication database. sync with backup 옵션을 설정하지 않으면 보조 서버에서 복구된 데이터베이스에는 포함되지 않는 변경 내용을 구독자가 받을 수 있습니다.If the sync with backup option is not set, Subscribers might receive changes that are no longer included in the recovered database at the secondary server. 자세한 내용은 Strategies for Backing Up and Restoring Snapshot and Transactional Replication을(를) 참조하세요.For more information, see Strategies for Backing Up and Restoring Snapshot and Transactional Replication.

sync with backup 옵션으로 트랜잭션 게시 및 로그 전달을 구성하려면To configure transactional replication and log shipping with the sync with backup option

  1. 게시 데이터베이스에 sync with backup 옵션이 설정되어 있지 않으면 sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'를 실행합니다.If the sync with backup option is not set on the publication database, execute sp_replicationdboption '<publicationdatabasename>', 'sync with backup', 'true'. 자세한 내용은 sp_replicationdboption(Transact-SQL)을 참조하세요.For more information, see sp_replicationdboption (Transact-SQL).

  2. 게시 데이터베이스에 대한 로그 전달을 구성합니다.Configure log shipping for the publication database. 자세한 내용은 로그 전달 구성(SQL Server)을 참조하세요.For more information, see Configure Log Shipping (SQL Server).

  3. 게시자에서 오류가 발생하면 RESTORE LOG의 KEEP_REPLICATION 옵션을 사용하여 데이터베이스의 마지막 로그를 보조 서버로 복원합니다.If the Publisher fails, restore the last log of the database to the secondary server, using the KEEP_REPLICATION option of RESTORE LOG. 이렇게 하면 데이터베이스에 대한 모든 복제 설정이 유지됩니다.This retains all replication settings for the database. 자세한 내용은 로그 전달 보조 데이터베이스로 장애 조치(Failover)(SQL Server)RESTORE(Transact-SQL)를 참조하세요.For more information, see Fail Over to a Log Shipping Secondary (SQL Server) and RESTORE (Transact-SQL).

  4. 주 서버에서 보조 서버로 msdb 데이터베이스와 master 데이터베이스를 복원합니다.Restore the msdb database and master databases from the primary to the secondary. 자세한 내용은 시스템 데이터베이스 백업 및 복원(SQL Server&#41를 참조하세요.For more information, see Back Up and Restore of System Databases (SQL Server). 주 서버가 배포자이기도 한 경우 배포 데이터베이스를 주 서버에서 보조 서버로 복원합니다.If the primary was also a Distributor, restore the distribution database from the primary to the secondary.

    이러한 데이터베이스의 복제 구성 및 설정은 주 서버의 게시 데이터베이스와 일치해야 합니다.These databases must be consistent with the publication database at the primary in terms of replication configuration and settings.

  5. 보조 서버에서 컴퓨터의 이름을 바꾼 후 주 서버 이름과 일치하도록 SQL ServerSQL Server 인스턴스의 이름을 바꿉니다.At the secondary server, rename the computer and then rename the SQL ServerSQL Server instance to match the primary server name. 컴퓨터의 이름을 바꾸는 방법은 Windows 설명서를 참조하십시오.For information about renaming the computer, see the Windows documentation. 서버 이름을 바꾸는 방법은 SQL Server의 독립 실행형 인스턴스를 호스팅하는 컴퓨터 이름 바꾸기SQL Server 장애 조치(Failover) 클러스터 인스턴스 이름 변경을 참조하세요.For information about renaming the server, see Rename a Computer that Hosts a Stand-Alone Instance of SQL Server and Rename a SQL Server Failover Cluster Instance.

  6. 보조 서버에서 주 서버로부터 백업한 서비스 마스터 키를 복원합니다.At the secondary server, restore the service master key that was backed up from the primary. 자세한 내용은 RESTORE SERVICE MASTER KEY(Transact-SQL)를 참조하세요.For more information, see RESTORE SERVICE MASTER KEY (Transact-SQL).

    sync with backup 옵션을 사용하지 않고 트랜잭션 게시 및 로그 전달을 구성하려면To configure transactional replication and log shipping without the sync with backup option

  7. 게시 데이터베이스에 대한 로그 전달을 구성합니다.Configure log shipping for the publication database. 자세한 내용은 로그 전달 구성(SQL Server)을 참조하세요.For more information, see Configure Log Shipping (SQL Server).

  8. 게시자에서 오류가 발생하면 RESTORE LOG의 KEEP_REPLICATION 옵션을 사용하여 데이터베이스의 마지막 로그를 보조 서버로 복원합니다.If the Publisher fails, restore the last log of the database to the secondary server, using the KEEP_REPLICATION option of RESTORE LOG. 이렇게 하면 데이터베이스에 대한 모든 복제 설정이 유지됩니다.This retains all replication settings for the database. 자세한 내용은 로그 전달 보조 데이터베이스로 장애 조치(Failover)(SQL Server)RESTORE(Transact-SQL)를 참조하세요.For more information, see Fail Over to a Log Shipping Secondary (SQL Server) and RESTORE (Transact-SQL).

  9. 주 서버에서 보조 서버로 msdb 데이터베이스와 master 데이터베이스를 복원합니다.Restore the msdb database and master databases from the primary to the secondary. 자세한 내용은 시스템 데이터베이스 백업 및 복원(SQL Server&#41를 참조하세요.For more information, see Back Up and Restore of System Databases (SQL Server). 주 서버가 배포자이기도 한 경우 배포 데이터베이스를 주 서버에서 보조 서버로 복원합니다.If the primary was also a Distributor, restore the distribution database from the primary to the secondary.

    이러한 데이터베이스의 복제 구성 및 설정은 주 서버의 게시 데이터베이스와 일치해야 합니다.These databases must be consistent with the publication database at the primary in terms of replication configuration and settings.

  10. 보조 서버에서 컴퓨터의 이름을 바꾼 후 주 서버 이름과 일치하도록 SQL ServerSQL Server 인스턴스의 이름을 바꿉니다.At the secondary server, rename the computer and then rename the SQL ServerSQL Server instance to match the primary server name. 컴퓨터의 이름을 바꾸는 방법은 Windows 설명서를 참조하십시오.For information about renaming the computer, see the Windows documentation. 서버 이름을 바꾸는 방법은 SQL Server의 독립 실행형 인스턴스를 호스팅하는 컴퓨터 이름 바꾸기SQL Server 장애 조치(Failover) 클러스터 인스턴스 이름 변경을 참조하세요.For information about renaming the server, see Rename a Computer that Hosts a Stand-Alone Instance of SQL Server and Rename a SQL Server Failover Cluster Instance.

    게시 데이터베이스 및 배포 데이터베이스가 동기화되지 않았다는 오류 메시지가 로그 판독기 에이전트에서 발생할 수 있습니다.You might receive an error message from the Log Reader Agent that the publication database and the distribution database are not synchronized.

  11. 보조 서버에서 주 서버로부터 백업한 서비스 마스터 키를 복원합니다.At the secondary server, restore the service master key that was backed up from the primary. 자세한 내용은 RESTORE SERVICE MASTER KEY(Transact-SQL)를 참조하세요.For more information, see RESTORE SERVICE MASTER KEY (Transact-SQL).

  12. sp_replrestart를 실행합니다.Execute sp_replrestart. 이 저장 프로시저를 사용하면 로그 판독기 에이전트가 게시 데이터베이스 로그에서 이전에 복제된 모든 트랜잭션을 강제로 무시하도록 할 수 있습니다.This stored procedure can be used to force the Log Reader Agent to ignore all the previous replicated transactions in the publication database log. 저장 프로시저가 완료된 후에 적용된 트랜잭션은 로그 판독기 에이전트에 의해 처리됩니다.Transactions applied after the completion of the stored procedure are processed by the Log Reader Agent. 자세한 내용은 sp_replrestart(Transact-SQL)를 참조하세요.For more information, see sp_replrestart (Transact-SQL).

  13. 저장 프로시저가 성공적으로 실행된 후에 로그 판독기 에이전트를 다시 시작합니다.Restart the Log Reader Agent after the stored procedure executes successfully. 자세한 내용은 복제 에이전트 시작 및 중지(SQL Server Management Studio)를 참조하세요.For more information, see Start and Stop a Replication Agent (SQL Server Management Studio).

  14. 구독자에 이미 배포된 트랜잭션은 게시자에 적용될 수 있습니다.Transactions that have already been distributed to Subscriber might be applied at the Publisher. 배포 에이전트에서 이러한 트랜잭션을 구독자에서 다시 적용할 때 오류가 발생하지 않도록 하려면 데이터 일관성 오류가 발생했지만 계속됩니다라는 에이전트 프로필을 지정합니다.To ensure that the Distribution Agent does not fail with an error when attempting to reapply these transactions at a Subscriber, specify the agent profile titled Continue On Data Consistency Errors.

병합 복제의 로그 전달Log Shipping with Merge Replication

병합 복제와 로그 전달을 구성하려면 아래 절차의 단계를 따르십시오.Follow the steps in the procedure below to configure merge replication and log shipping.

병합 복제 및 로그 전달을 구성하려면To configure merge replication and log shipping

  1. 게시 데이터베이스에 대한 로그 전달을 구성합니다.Configure log shipping for the publication database. 자세한 내용은 로그 전달 구성(SQL Server)을 참조하세요.For more information, see Configure Log Shipping (SQL Server).

  2. 게시자가 실패하면 보조 서버에서 컴퓨터의 이름을 바꾼 후 주 서버 이름과 일치하도록 SQL ServerSQL Server 인스턴스의 이름을 바꿉니다.If the Publisher fails, at the secondary server, rename the computer and then rename the SQL ServerSQL Server instance to match the primary server name. 컴퓨터의 이름을 바꾸는 방법은 Windows 설명서를 참조하십시오.For information about renaming the computer, see the Windows documentation. 서버 이름을 바꾸는 방법은 SQL Server의 독립 실행형 인스턴스를 호스팅하는 컴퓨터 이름 바꾸기SQL Server 장애 조치(Failover) 클러스터 인스턴스 이름 변경을 참조하세요.For information about renaming the server, see Rename a Computer that Hosts a Stand-Alone Instance of SQL Server and Rename a SQL Server Failover Cluster Instance.

  3. RESTORE LOG의 KEEP_REPLICATION 옵션을 사용하여 데이터베이스의 마지막 로그를 보조 서버로 복원합니다.Restore the last log of the database to the secondary server, using the KEEP_REPLICATION option of RESTORE LOG. 이렇게 하면 데이터베이스에 대한 모든 복제 설정이 유지됩니다.This retains all replication settings for the database. 자세한 내용은 로그 전달 보조 데이터베이스로 장애 조치(Failover)(SQL Server)RESTORE(Transact-SQL)를 참조하세요.For more information, see Fail Over to a Log Shipping Secondary (SQL Server) and RESTORE (Transact-SQL).

  4. 주 서버에서 보조 서버로 msdb 데이터베이스와 master 데이터베이스를 복원합니다.Restore the msdb database and master databases from the primary to the secondary. 자세한 내용은 시스템 데이터베이스 백업 및 복원(SQL Server&#41를 참조하세요.For more information, see Back Up and Restore of System Databases (SQL Server). 주 서버가 배포자이기도 한 경우 배포 데이터베이스를 주 서버에서 보조 서버로 복원합니다.If the primary was also a Distributor, restore the distribution database from the primary to the secondary.

    이러한 데이터베이스의 복제 구성 및 설정은 주 서버의 게시 데이터베이스와 일치해야 합니다.These databases must be consistent with the publication database at the primary in terms of replication configuration and settings.

  5. 보조 서버에서 주 서버로부터 백업한 서비스 마스터 키를 복원합니다.At the secondary server, restore the service master key that was backed up from the primary. 자세한 내용은 RESTORE SERVICE MASTER KEY(Transact-SQL)를 참조하세요.For more information, see RESTORE SERVICE MASTER KEY (Transact-SQL).

  6. 하나 이상의 구독 데이터베이스와 게시 데이터베이스를 동기화합니다.Synchronize the publication database with one or more subscription databases. 이렇게 하면 이전 게시 데이터베이스에서 변경되었지만 복원된 백업에 표시되지 않은 변경 내용을 업로드할 수 있습니다.This allows you to upload those changes made previously in the publication database, but not represented in the restored backup. 업로드할 수 있는 데이터는 게시가 필터링되는 방식에 따라 달라집니다.The data that can be uploaded depends on the way in which a publication is filtered:

    • 게시가 필터링되지 않은 경우 최신 구독자와 동기화하여 게시 데이터베이스를 최신 상태로 만들 수 있습니다.If the publication is not filtered, you should be able to bring the publication database up-to-date by synchronizing with the most up-to-date Subscriber.

    • 게시가 필터링된 경우 게시 데이터베이스를 최신 상태로 만들 수 없을 수도 있습니다.If the publication is filtered, you might not be able to bring the publication database up-to-date. 각 구독이 동부, 서부, 남부 및 북부 중 한 지역에 대한 고객 데이터만 수신하도록 분할된 테이블을 고려해 봅시다.Consider a table that is partitioned such that each subscription receives customer data only for a single region: North, East, South, and West. 각 데이터 파티션에 대해 최소 하나의 구독자가 있는 경우 각 파티션에 대해 구독자와 동기화하면 게시 데이터베이스가 최신 상태가 됩니다.If there is at least one Subscriber for each partition of data, synchronizing with a Subscriber for each partition should bring the publication database up-to-date. 그러나 예를 들어 서부 파티션의 데이터가 구독자에 복제되지 않은 경우에는 게시자에서 이 데이터를 최신 상태로 만들 수 없습니다.However, if data in the West partition, for example, was not replicated to any Subscribers, this data at the Publisher cannot be brought up-to-date. 이 경우에는 게시자 및 구독자의 데이터가 일치하도록 모든 구독을 다시 초기화하는 것이 좋습니다.In this case, we recommend reinitializing all subscriptions so that the data at the Publisher and Subscribers converges. 자세한 내용은 구독 다시 초기화를 참조하세요.For more information, see Reinitialize Subscriptions.

      SQL ServerSQL Server 이전 버전의 SQL Server 2005SQL Server 2005를 실행하는 구독자와 동기화할 경우에 해당 구독은 익명일 수 없습니다. 구독은 클라이언트 구독 또는 서버 구독(이전 버전에서는 로컬 구독 및 전역 구독)이어야 합니다.If you synchronize with a Subscriber that is running a version of SQL ServerSQL Server prior to SQL Server 2005SQL Server 2005, the subscription cannot be anonymous; it must be a client subscription or server subscription (referred to as local subscriptions and global subscriptions in previous releases). 자세한 내용은 데이터 동기화를 참조하세요.For more information, see Synchronize Data.

참고 항목See Also

복제 기능 및 태스크 Replication Features and Tasks
로그 전달 정보(SQL Server) About Log Shipping (SQL Server)
데이터베이스 미러링 및 복제(SQL Server)Database Mirroring and Replication (SQL Server)