스냅샷 및 트랜잭션 복제의 백업 및 복원을 위한 전략
적용 대상: 
SQL Server Azure SQL Database
스냅샷 및 트랜잭션 복제에 대한 백업 및 복원 전략을 설계할 때 다음 세 가지 영역을 고려해야 합니다.
- 백업할 데이터베이스.
- 트랜잭션 복제에 대한 백업 설정.
- 데이터베이스를 복원하는 데 필요한 단계입니다. 이 단계는 선택한 복제 유형 및 옵션에 따라 달라집니다.
이 항목에서는 다음 세 섹션의 각 영역에 대해 설명합니다. Oracle 게시에 대한 백업 및 복원에 대한 자세한 내용은 Oracle 게시자 백업 및 복원을 참조하세요.
참고 항목
Azure SQL Managed Instance는 스냅샷 및 트랜잭션 복제를 위한 게시자, 배포자 및 구독자일 수 있습니다. Azure SQL Database의 데이터베이스는 스냅샷과 트랜잭션 복제를 위한 밀어넣기 구독자만 될 수 있습니다. 자세한 내용은 Azure SQL 데이터베이스 및 Azure SQL Managed Instance를 사용하는 트랜잭션 복제를 참조하세요.
데이터베이스 백업하기
스냅샷 및 트랜잭션 복제의 경우 다음 데이터베이스를 정기적으로 백업해야 합니다.
게시자의 게시 데이터베이스.
배포자에서 배포 데이터베이스 만들기
각 구독자의 구독 데이터베이스.
게시자, 배포자 및 모든 구독자의 master 및 msdb 시스템 데이터베이스. 이러한 데이터베이스는 서로 그리고 관련 복제 데이터베이스와 함께 동시에 백업되어야 합니다. 예를 들어 게시 데이터베이스를 백업하는 동시에 게시자에서 마스터 및 msdb 데이터베이스를 백업합니다. 게시 데이터베이스를 복원한 경우에는 master 및 msdb 데이터베이스의 복제 구성 및 설정이 게시 데이터베이스와 일치하는지 확인해야 합니다.
정기적인 로그 백업을 수행할 경우 모든 복제 관련 변경 내용은 로그 백업에 캡처됩니다. 로그 백업을 수행하지 않는 경우 복제와 관련된 설정이 변경될 때마다 백업을 수행해야 합니다. 자세한 내용은 업데이트된 백업이 필요한 일반적인 작업을 참조하세요.
트랜잭션 복제에 대한 백업 설정
트랜잭션 복제 과정에는 배포 데이터베이스 및 게시 데이터베이스에 설정할 수 있는 sync with backup 옵션이 사용됩니다.
항상 배포 데이터베이스에서 이 옵션을 설정하는 것이 좋습니다.
배포 데이터베이스에 이 옵션을 설정하면 게시 데이터베이스 로그의 트랜잭션은 배포 데이터베이스에서 백업될 때까지 잘리지 않습니다. 배포 데이터베이스를 마지막 백업으로 복원할 수 있으며 누락된 트랜잭션은 게시 데이터베이스에서 배포 데이터베이스로 전달됩니다. 복제는 아무런 영향 없이 계속됩니다.
배포 데이터베이스에서 이 옵션을 설정해도 복제 대기 시간에는 영향을 주지 않습니다. 그러나 이 옵션은 배포 데이터베이스의 해당 트랜잭션이 백업될 때까지 게시 데이터베이스의 로그 잘림을 지연할 것입니다. 이로 인해 게시 데이터베이스에 더 큰 트랜잭션 로그가 만들어질 수 있습니다.
애플리케이션에서 추가 대기 시간을 허용할 수 있는 경우 게시 데이터베이스에서 이 옵션을 설정하는 것이 좋습니다.
배포 데이터베이스에 이 옵션을 설정하면 트랜잭션은 게시 데이터베이스에서 백업될 때까지 배포 데이터베이스로 전달되지 않습니다. 그러면 복원된 게시 데이터베이스에 없는 트랜잭션이 배포 데이터베이스에 있을 기회가 없이 마지막 게시 데이터베이스 백업을 게시자에서 복원할 수 있습니다.
트랜잭션이 게시자에서 백업될 때까지 배포 데이터베이스로 전달될 수 없으므로 대기 시간 및 처리량이 영향을 받습니다. 예를 들어 트랜잭션 로그가 5분마다 백업되는 경우 게시자에서 트랜잭션이 커밋된 시간과 트랜잭션이 배포 데이터베이스와 그 이후에 구독자에 전달된 시점 사이에 5분의 대기 시간이 추가로 발생합니다.
참고 항목
백업과 동기화 옵션을 사용하면 게시 데이터베이스와 배포 데이터베이스 간의 일관성이 보장되지만 이 옵션은 데이터 손실을 보장하지 않습니다. 예를 들어 트랜잭션 로그가 손실된 경우 마지막 트랜잭션 로그 백업 이후 커밋된 트랜잭션은 게시 데이터베이스 또는 배포 데이터베이스에서 사용할 수 없습니다. 이는 복제되지 않은 데이터베이스와 동일한 동작입니다.
게시자 데이터베이스가 가용성 그룹의 일부이며 다음 오류가 발생할 수 있는 경우 배포 데이터베이스에서 백업과 동기화 옵션을 사용하는 것은 호환되지 않습니다. 이로 인해 장애 조치(failover) 후 로그 판독기 에이전트가 실행되면 다음 오류가 발생할 수 있습니다.
프로세스에서 'machinename\instance'의 'sp_repldone/sp_replcounters'을 실행할 수 없습니다. (원본: MSSQL_REPL, 오류 번호: MSSQL_REPL20011) 도움말 보기: http://help/MSSQL_REPL20011 배포 데이터베이스에서 가능한 일관성이 없는 상태: dist_backup_lsn {nnn:nnnnn:nnnnn}, dist_last_lsn {nnnnnnnn:nn:nnnnn}. "sp_repldone NULL, NULL, 0, 0, 1"을 실행한 다음 sp_replflush를 실행하십시오. 게시에 대한 모든 구독을 다시 초기화하십시오. (원본: MSSQLServer, 오류 번호: 18846)
백업과 동기화 옵션을 설정하려면
- 복제 Transact-SQL 프로그래밍: 트랜잭션 복제에 대한 조정된 백업 사용(복제 Transact-SQL 프로그래밍)
복제와 관련된 데이터베이스 복원
최근 백업을 사용할 수 있고 적절한 단계를 따르는 경우 복제 토폴로지의 모든 데이터베이스를 복원할 수 있습니다. 게시 데이터베이스의 복원 단계는 복제 유형 및 사용되는 옵션에 따라 달라집니다. 그러나 다른 모든 데이터베이스에 대한 복원 단계는 형식 및 옵션과 독립적입니다.
복제에서는 복제된 데이터베이스를 백업이 생성된 서버 및 데이터베이스로 복원할 수 있습니다. 복제된 데이터베이스의 백업을 다른 서버 또는 데이터베이스로 복원할 경우 복제 설정은 유지되지 않습니다. 이 경우 백업이 복원된 후 모든 게시 및 구독을 다시 만들어야 합니다.
게시자
다음 유형의 복제에 대해 제공되는 복원 단계가 있습니다.
스냅샷 복제
읽기 전용 트랜잭션 복제
구독 업데이트가 있는 트랜잭션 복제
피어 투 피어 트랜잭션 복제
이 4가지 복제에 대한 msdb 데이터베이스 및 master 데이터베이스(이 섹션에서 함께 설명됨)의 복원은 모두 동일합니다.
게시 데이터베이스: 스냅샷 복제
게시 데이터베이스의 최신 백업을 복원합니다. 2단계로 이동합니다.
게시 데이터베이스 백업이 모든 게시 및 구독에 대한 최신 구성을 포함하고 있는지 확인합니다. 그렇다면 복원이 완료됩니다. 그렇지 않으면 3단계로 이동합니다.
게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 이 단계로 복원이 완료됩니다.
복제를 제거하는 방법은 sp_removedbreplication(Transact-SQL)을 참조하세요.
게시 데이터베이스: 읽기 전용 트랜잭션 복제
게시 데이터베이스의 최신 백업을 복원합니다. 2단계로 이동합니다.
실패하기 전에 게시 데이터베이스에서 백업과 동기화 설정을 사용하도록 설정되었나요? 그렇다면 3단계로 이동하고, 그렇지 않으면 5단계로 이동합니다.
설정을 사용하도록 설정하면 쿼리
SELECT DATABASEPROPERTYEX('<PublicationDatabaseName>', 'IsSyncWithBackup')는 '1'을 반환합니다.복원된 백업이 완료되었으며 최신 상태인지 확인합니다. 모든 게시물 및 구독에 대한 최신 구성을 포함하고 있습니까? 그렇다면 복원이 완료됩니다. 그렇지 않으면 4단계로 이동합니다.
복원된 게시 데이터베이스의 구성 정보가 최신 상태가 아닙니다. 따라서 배포 데이터베이스의 처리 중인 모든 명령이 구독자에 배포되었는지 확인한 다음 복제 구성을 삭제하고 다시 만들어야 합니다.
모든 구독자가 배포 데이터베이스의 처리 중인 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터의 배포되지 않은 명령을 사용하거나 배포 데이터베이스에서 MSdistribution_status 뷰를 쿼리하여 모든 명령이 구독자에 제공되었는지 확인합니다. b 단계로 이동합니다.
배포 에이전트를 실행하는 방법은 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 복제 에이전트 실행 파일 개념을 참조하세요.
명령을 확인하는 방법에 대한 자세한 내용은 배포 데이터베이스의 복제된 명령 및 기타 정보 보기(복제 Transact-SQL 프로그래밍) 및 복제 모니터를 사용하여 정보 보기 및 태스크 수행을 참조하세요.
게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. 복원이 완료됩니다.
복제를 제거하는 방법은 sp_removedbreplication(Transact-SQL)을 참조하세요.
구독자에 이미 데이터가 있다고 지정하는 방법은 Initialize a Subscription Manually를 참조하십시오.
게시 데이터베이스에서 백업과 동기화 옵션이 설정되지 않았습니다. 복원된 백업에 포함되지 않은 트랜잭션이 배포자 및 구독자에 배달되었을 수 있습니다. 이제 구독자에게 배포 데이터베이스의 모든 미해결 명령이 있는지 확인한 다음 복원된 백업에 포함되지 않은 트랜잭션을 게시 데이터베이스에 수동으로 적용해야 합니다.
Important
이 프로세스를 수행하면 게시된 테이블이 백업에서 복원된 다른 게시되지 않은 테이블의 지정 시간보다 더 최근 시점으로 복원될 수 있습니다.
모든 구독자가 배포 데이터베이스의 처리 중인 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터의 배포되지 않은 명령을 사용하거나 배포 데이터베이스에서 MSdistribution_status 뷰를 쿼리하여 모든 명령이 구독자에 제공되었는지 확인합니다. b 단계로 이동합니다.
배포 에이전트를 실행하는 방법은 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 복제 에이전트 실행 파일 개념을 참조하세요.
명령을 확인하는 방법에 대한 자세한 내용은 배포 데이터베이스의 복제된 명령 및 기타 정보 보기(복제 Transact-SQL 프로그래밍) 및 복제 모니터를 사용하여 정보 보기 및 태스크 수행을 참조하세요.
tablediff 유틸리티 또는 다른 도구를 사용하여 게시자를 구독자와 수동으로 동기화합니다. 이렇게 하면 게시 데이터베이스 백업에 포함되지 않은 구독 데이터베이스에서 데이터를 복구할 수 있습니다. c 단계로 이동합니다.
tablediff 유틸리티에 대한 자세한 내용은 복제된 테이블의 차이점 비교(복제 프로그래밍)를 참조하세요.
복원된 백업이 완료되었으며 최신 상태인지 확인합니다. 모든 게시물 및 구독에 대한 최신 구성을 포함하고 있습니까? 그렇다면 저장 프로시저 sp_replrestart 를 실행하여 게시자 메타데이터를 배포자 메타데이터와 다시 동기화합니다. 복원이 완료됩니다. 그렇지 않으면 d 단계로 이동합니다.
게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. 복원이 완료됩니다.
복제를 제거하는 방법은 sp_removedbreplication(Transact-SQL)을 참조하세요.
구독자에 이미 데이터가 있다고 지정하는 방법은 Initialize a Subscription Manually를 참조하십시오.
게시 데이터베이스: 업데이트 구독을 사용한 트랜잭션 복제
게시 데이터베이스의 최신 백업을 복원합니다. 2단계로 이동합니다.
모든 구독자가 배포 데이터베이스의 처리 중인 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터에서 배포되지 않은 명령을 사용하거나 배포 데이터베이스에서 MSdistribution_status 뷰를 쿼리하여 모든 명령이 구독자에 제공되었는지 확인합니다. 3단계로 이동합니다.
배포 에이전트를 실행하는 방법은 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 복제 에이전트 실행 파일 개념을 참조하세요.
명령을 확인하는 방법에 대한 자세한 내용은 배포 데이터베이스의 복제된 명령 및 기타 정보 보기(복제 Transact-SQL 프로그래밍) 및 복제 모니터를 사용하여 정보 보기 및 태스크 수행을 참조하세요.
지연 업데이트 구독을 사용하는 경우 각 구독자에 연결하고 구독 데이터베이스의 MSreplication_queue(Transact-SQL) 테이블에서 모든 행을 삭제합니다. 4단계로 이동합니다.
참고 항목
대기 중인 업데이트 구독을 사용하고 테이블에 ID 열이 포함된 경우 복원 후에 올바른 ID 범위가 할당되었는지 확인해야 합니다. 자세한 내용은 ID 열 복제를 참조하세요.
이제 구독자에게 배포 데이터베이스의 모든 미해결 명령이 있는지 확인한 다음 복원된 백업에 포함되지 않은 트랜잭션을 게시 데이터베이스에 수동으로 적용해야 합니다.
Important
이 프로세스를 수행하면 게시된 테이블이 백업에서 복원된 다른 게시되지 않은 테이블의 지정 시간보다 더 최근 시점으로 복원될 수 있습니다.
모든 구독자가 배포 데이터베이스의 처리 중인 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터를 사용하거나 배포 데이터베이스에서 MSdistribution_status 뷰를 쿼리하여 모든 명령이 구독자에 배달되었는지 확인합니다. b 단계로 이동합니다.
tablediff 유틸리티 또는 다른 도구를 사용하여 게시자를 구독자와 수동으로 동기화합니다. 이렇게 하면 게시 데이터베이스 백업에 포함되지 않은 구독 데이터베이스에서 데이터를 복구할 수 있습니다. c 단계로 이동합니다.
tablediff 유틸리티에 대한 자세한 내용은 복제된 테이블의 차이점 비교(복제 프로그래밍)를 참조하세요.
복원된 백업이 완료되었으며 최신 상태인지 확인합니다. 모든 게시물 및 구독에 대한 최신 구성을 포함하고 있습니까? 그렇다면 저장 프로시저 sp_replrestart 를 실행하여 게시자 메타데이터를 배포자 메타데이터와 다시 동기화합니다. 복원이 완료됩니다. 그렇지 않으면 d 단계로 이동합니다.
게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. 복원이 완료됩니다.
복제를 제거하는 자세한 방법은 sp_removedbreplication(Transact-SQL)을 참조하세요.
구독자에 이미 데이터가 있다고 지정하는 방법은 Initialize a Subscription Manually를 참조하십시오.
게시 데이터베이스: 피어 투 피어 트랜잭션 복제
다음 단계에서 게시 데이터베이스 A, B 및 C 는 피어 투 피어 트랜잭션 복제 토폴로지입니다. 데이터베이스 A와 C는 온라인 상태가 되며 제대로 작동합니다. 데이터베이스 B는 복원할 데이터베이스입니다. 여기서 설명하는 프로세스, 특히 7단계, 10단계 및 11단계는 피어 투 피어 토폴로지에 노드를 추가하는 데 필요한 프로세스와 매우 유사합니다. 이러한 단계를 수행하는 가장 간단한 방법은 피어 투 피어 토폴로지 구성 마법사를 사용하는 것이지만 저장 프로시저를 사용할 수도 있습니다.
배포 에이전트를 실행하여 데이터베이스 A 및 C에서 구독을 동기화합니다. 2단계로 이동합니다.
배포 에이전트를 실행하는 방법은 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 복제 에이전트 실행 파일 개념을 참조하세요.
B에서 사용하는 배포 데이터베이스를 계속 사용할 수 있는 경우 배포 에이전트 실행하여 데이터베이스 B와 A, 데이터베이스와 B 및 C 간에 구독을 동기화합니다. 3단계로 이동합니다.
B에 대한 배포 데이터베이스에서 sp_removedistpublisherdbreplication을 실행하여 B가 사용하는 배포 데이터베이스에서 메타데이터를 제거합니다. 4단계로 이동합니다.
데이터베이스 A 및 C에서 데이터베이스 B의 게시물에 대한 구독을 삭제합니다. 5단계로 이동합니다.
구독 삭제에 대한 자세한 내용은 게시물 구독을 참조하세요.
데이터베이스 A의 로그 백업 또는 전체 백업을 수행합니다. 6단계로 이동합니다.
데이터베이스 B에서 데이터베이스 A의 백업을 복원합니다. 이제 데이터베이스 B에는 데이터베이스 A의 데이터가 있지만 복제 구성은 없습니다. 백업을 다른 서버로 복원하면 복제가 제거되므로 이 경우 B 데이터베이스에서 복제가 제거된 것입니다. 7단계로 이동합니다.
데이터베이스 B에서 게시물을 다시 만든 다음 데이터베이스 A와 B 간에 구독을 다시 만듭니다.(데이터베이스를 포함하는 구독 C는 이후 단계에서 처리됩니다.).
데이터베이스 B에서 게시물을 다시 만듭니다. b 단계로 이동합니다.
백업으로 구독이 초기화되도록 지정하여 데이터베이스 B의 구독을 데이터베이스 A의 게시물로 다시 만듭니다(sp_addsubscription의
@sync_type매개 변수에 대한 백업으로 초기화의 값). c 단계로 이동합니다.A 데이터베이스에서 B데이터베이스의 게시에 대한 구독을 다시 만들고 해당 구독자에 이미 데이터가 있다고 지정합니다. 즉, sp_addsubscription의
@sync_type매개 변수에 replication support only 값을 지정합니다. 8단계로 이동합니다.
배포 에이전트 실행하여 데이터베이스 A 및 B에서 구독을 동기화합니다. 게시된 테이블에 ID 열이 있는 경우 9단계로 이동합니다. 그렇지 않은 경우에는 10단계로 이동합니다.
복원 후에는 데이터베이스 A의 각 테이블에 할당한 ID 범위도 데이터베이스 B에서 사용됩니다. 복원된 데이터베이스 B가 실패한 데이터베이스 B에서 데이터베이스 A 및 데이터베이스 C로 전파된 모든 변경 내용을 받았는지 확인한 다음 각 테이블의 ID 범위를 다시 지정했는지 확인합니다.
데이터베이스 B에서 sp_requestpeerresponse를 실행하고 출력 매개 변수
@request_id를 검색합니다. b 단계로 이동합니다.기본적으로 배포 에이전트가 지속적으로 실행되도록 설정되므로 토큰은 모든 노드에 자동으로 전송되어야 합니다. 배포 에이전트가 연속 모드로 실행되지 않을 경우에는 에이전트를 실행합니다. 자세한 내용은 복제 에이전트 실행 파일 개념 또는 복제 에이전트 시작 및 중지(SQL Server Management Studio)를 참조하세요. c 단계로 이동합니다.
b 단계에서 검색한
@request_id값을 지정하고 sp_helppeerresponses를 실행합니다. 모든 노드가 피어 요청을 수신했음을 나타낼 때까지 기다립니다. d 단계로 이동합니다.DBCC CHECKIDENT를 사용하여 데이터베이스 B의 각 테이블을 다시 지정하고 적절한 범위가 사용되는지 확인합니다. 10단계로 이동합니다.
ID 범위를 관리하는 방법에 대한 자세한 내용은 ID 열 복제의 "수동 ID 범위 관리를 위한 범위 할당" 섹션을 참조하세요.
이 시점에서 데이터베이스 B 와 데이터베이스 C 는 직접 연결되지 않지만 데이터베이스 A를 통해 변경 내용을 받습니다. 토폴로지에서 SQL Server 2005(9.x)를 실행하는 노드가 포함된 경우 11단계로 이동합니다. 그렇지 않으면 12단계로 이동합니다.
시스템을 정지한 다음 데이터베이스 B와 C 간에 구독을 다시 만듭니다. 시스템 정지에는 모든 노드에서 게시된 테이블에 대한 작업을 중지하고 각 노드가 다른 모든 노드에서 모든 변경 내용을 수신했는지 확인하는 작업이 포함됩니다.
피어 투 피어 토폴로지의 게시된 테이블에 대한 모든 작업을 중지합니다. b 단계로 이동합니다.
데이터베이스 B에서 sp_requestpeerresponse를 실행하고 출력 매개 변수
@request_id를 검색합니다. c 단계로 이동합니다.기본적으로 배포 에이전트가 지속적으로 실행되도록 설정되므로 토큰은 모든 노드에 자동으로 전송되어야 합니다. 배포 에이전트가 연속 모드로 실행되지 않을 경우에는 에이전트를 실행합니다. d 단계로 이동합니다.
b 단계에서 검색한
@request_id값을 지정하고 sp_helppeerresponses를 실행합니다. 모든 노드가 피어 요청을 수신했음을 나타낼 때까지 기다립니다. e 단계로 이동합니다.구독자에 이미 데이터가 있음을 지정하여 B 데이터베이스에서 C데이터베이스의 게시에 대한 구독을 다시 만듭니다. b 단계로 이동합니다.
구독자에 이미 데이터가 있음을 지정하여 데이터베이스 B에서 데이터베이스 C의 게시물에 대한 구독을 다시 만듭니다. 13단계로 이동합니다.
데이터베이스 B와 C 간에 구독을 다시 만듭니다.
B데이터베이스에서 MSpeer_lsns 테이블을 쿼리하여 B 데이터베이스에서 C데이터베이스로부터 받은 최신 트랜잭션의 LSN(로그 시퀀스 번호)을 검색합니다.
구독자에 이미 데이터가 있음을 지정하여 B 데이터베이스에서 C데이터베이스의 게시에 대한 구독을 다시 만들고 LSN을 기반으로 구독이 초기화되도록 지정합니다. 즉, sp_addsubscription 의
@sync_type매개 변수에 initialize with backup값을 지정합니다. b 단계로 이동합니다.구독자에 이미 데이터가 있음을 지정하여 데이터베이스 B에서 데이터베이스 C의 게시물에 대한 구독을 다시 만듭니다. 13단계로 이동합니다.
배포 에이전트를 실행하여 데이터베이스 B 및 C에서 구독을 동기화합니다. 복원이 완료되었습니다.
msdb 데이터베이스(게시자)
msdb 데이터베이스의 최신 백업을 복원합니다.
복원된 백업이 완료되었으며 최신 상태인지 확인합니다. 모든 게시물 및 구독에 대한 최신 구성을 포함하고 있습니까? 그렇다면 복구가 완료됩니다. 그렇지 않으면 3단계로 이동합니다.
복제 스크립트에서 구독 정리 작업을 다시 만듭니다. 복구가 완료되었습니다.
master 데이터베이스(게시자)
master 데이터베이스의 최신 백업을 복원합니다.
데이터베이스의 복제 구성 및 설정이 게시 데이터베이스와 일치하는지 확인해야 합니다.
배포자의 데이터베이스
배포 데이터베이스
배포 데이터베이스의 최신 백업을 복원합니다.
오류가 발생하기 전에 배포 데이터베이스에서 백업과 동기화 설정을 사용하도록 설정했나요? 그렇다면 3단계로 이동하고, 그렇지 않으면 4단계로 이동합니다.
설정을 사용하도록 설정하면 쿼리
SELECT DATABASEPROPERTYEX('<DistributionDatabaseName>', 'IsSyncWithBackup')는 '1'을 반환합니다.복원된 백업이 완료되었으며 최신 상태인지 확인합니다. 모든 게시물 및 구독에 대한 최신 구성을 포함하고 있습니까? 그렇다면 복구가 완료됩니다. 그렇지 않으면 4단계로 이동합니다.
복원된 배포 데이터베이스의 구성 정보가 최신 상태가 아니거나 백업과 동기화 옵션이 배포 데이터베이스에 설정되지 않았습니다. (복원 후, 배포 데이터베이스에 게시자에서 커밋되었지만 아직 구독자에게 배달되지 않은 트랜잭션이 누락되었을 수 있습니다.) 복제를 삭제하고 다시 만든 다음 유효성 검사를 실행합니다.
게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. b 단계로 이동합니다.
복제를 제거하는 방법은 sp_removedbreplication(Transact-SQL)을 참조하세요.
구독자에 이미 데이터가 있다고 지정하는 방법은 Initialize a Subscription Manually를 참조하십시오.
유효성 검사를 위해 모든 게시물을 표시합니다. 유효성 검사에 실패한 구독 다시 초기화 복구가 완료되었습니다.
유효성 검사에 관한 자세한 내용은 복제된 데이터의 유효성 검사를 참조하세요. 다시 초기화에 대한 자세한 내용은 구독 다시 초기화를 참조하세요.
msdb 데이터베이스(배포자)
msdb 데이터베이스의 최신 백업을 복원합니다.
복원된 백업이 완료되었으며 최신 상태인지 확인합니다. 모든 게시물 및 구독에 대한 최신 구성을 포함하고 있습니까? 그렇다면 복구가 완료됩니다. 그렇지 않으면 3단계로 이동합니다.
게시자, 배포자 및 구독자에서 복제 구성을 제거한 다음 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. 4단계로 이동합니다.
복제를 제거하는 방법은 sp_removedbreplication(Transact-SQL)을 참조하세요.
구독자에 이미 데이터가 있다고 지정하는 방법은 Initialize a Subscription Manually를 참조하십시오.
유효성 검사를 위해 모든 게시물을 표시합니다. 유효성 검사에 실패한 구독 다시 초기화 복구가 완료되었습니다.
유효성 검사에 관한 자세한 내용은 복제된 데이터의 유효성 검사를 참조하세요. 다시 초기화에 대한 자세한 내용은 구독 다시 초기화를 참조하세요.
master 데이터베이스(배포자)
master 데이터베이스의 최신 백업을 복원합니다.
데이터베이스의 복제 구성 및 설정이 게시 데이터베이스와 일치하는지 확인해야 합니다.
구독자에 있는 데이터베이스
구독 데이터베이스
최신 구독 데이터베이스 백업이 배포 데이터베이스의 최소 배포 보존 기간 설정보다 최신인지 확인합니다. 이를 통해 배포자에 구독자를 최신 상태로 만들기 위해 필요한 명령이 모두 있는지 여부를 확인합니다. 그렇다면 2단계로 이동합니다. 그렇지 않은 경우 구독을 다시 초기화합니다. 복구가 완료되었습니다.
최대 배포 보존 설정을 확인하려면 sp_helpdistributiondb을 실행하고 max_distretention 열에서 값을 검색합니다(이 값은 시간 단위).
구독을 다시 초기화하는 방법은 Reinitialize a Subscription를 참조하십시오.
최신 구독 데이터베이스 백업을 복원합니다. 3단계로 이동합니다.
구독 데이터베이스에 밀어넣기 구독만 있는 경우 4단계로 이동합니다. 구독 데이터베이스에 끌어오기 구독이 포함된 경우 다음 질문을 합니다. 구독 정보가 최신인가요? 이 데이터베이스에 오류 발생 시 설정된 테이블과 옵션이 모두 포함되어 있는지 확인합니다. 그렇다면 4단계로 이동합니다. 그렇지 않은 경우 구독을 다시 초기화합니다. 복구가 완료되었습니다.
구독자를 동기화하려면 배포 에이전트를 실행합니다. 복구가 완료되었습니다.
배포 에이전트를 실행하는 방법은 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 복제 에이전트 실행 파일 개념을 참조하세요.
msdb 데이터베이스(구독자)
msdb 데이터베이스의 최신 백업을 복원합니다. 이 구독자에서 끌어오기 구독을 사용합니까? 그렇지 않으면 복원이 완료됩니다. 그렇다면 2단계로 이동합니다.
복원된 백업이 완료되었으며 최신 상태인지 확인합니다. 모든 끌어오기 구독에 대한 최신 구성을 포함하고 있습니까? 그렇다면 복구가 완료됩니다. 그렇지 않으면 3단계로 이동합니다.
끌어오기 구독을 삭제하고 다시 만드십시오. 구독을 다시 만들 때 구독자에 이미 데이터가 있는지 지정합니다. 복원이 완료됩니다.
구독 삭제에 대한 자세한 내용은 게시물 구독을 참조하세요.
구독자에 이미 데이터가 있다고 지정하는 방법은 Initialize a Subscription Manually를 참조하십시오.
master 데이터베이스(구독자)
master 데이터베이스의 최신 백업을 복원합니다.
데이터베이스의 복제 구성 및 설정이 게시 데이터베이스와 일치하는지 확인해야 합니다.