다음을 통해 공유

스냅숏 및 트랜잭션 복제의 백업 및 복원을 위한 전략

  • 아티클

다음은 스냅숏 및 트랜잭션 복제에 대한 백업 및 복원 전략을 설계할 때 고려할 3가지 영역입니다.

  • 백업할 데이터베이스
  • 트랜잭션 복제에 대한 백업 설정
  • 데이터베이스를 복원하는 데 필요한 단계 - 이 단계는 선택한 복제 유형 및 옵션에 따라 달라집니다.

이 항목에서는 다음 3개의 섹션에서 각 영역을 설명합니다. Oracle 게시에 대한 백업 및 복원 방법은 Oracle 게시자 백업 및 복원을 참조하십시오.

데이터베이스 백업

스냅숏 및 트랜잭션 복제의 경우 다음 데이터베이스를 정기적으로 백업해야 합니다.

  • 게시자의 게시 데이터베이스
  • 배포자의 배포 데이터베이스
  • 각 구독자의 구독 데이터베이스
  • 게시자, 배포자 및 모든 구독자의 master 및 msdb 시스템 데이터베이스. 이러한 데이터베이스는 각각 그리고 관련 복제 데이터베이스와 동시에 백업되어야 합니다. 예를 들어 게시 데이터베이스를 백업할 때 게시자의 master 및 msdb 데이터베이스를 동시에 백업합니다. 게시 데이터베이스를 복원한 경우 master 및 msdb 데이터베이스의 복제 구성 및 설정이 게시 데이터베이스의 복제 구성 및 설정과 일치하는지 확인하십시오.

정기적인 로그 백업을 수행할 경우 모든 복제 관련 변경 내용은 로그 백업에 캡처됩니다. 로그 백업을 수행하지 않는 경우 복제와 관련된 설정이 변경될 때마다 백업을 수행해야 합니다. 자세한 내용은 업데이트된 백업이 필요한 일반 작업을 참조하십시오.

트랜잭션 복제에 대한 백업 설정

트랜잭션 복제에는 다음과 같이 배포 데이터베이스 및 게시 데이터베이스에 설정할 수 있는 sync with backup 옵션이 있습니다.

  • 모든 경우에 이 옵션을 배포 데이터베이스에 설정하는 것이 좋습니다.
    배포 데이터베이스에 이 옵션을 설정하면 게시 데이터베이스 로그의 트랜잭션은 배포 데이터베이스에서 백업될 때까지 잘리지 않습니다. 배포 데이터베이스는 마지막 백업으로 복원할 수 있으며 손실된 트랜잭션은 게시 데이터베이스에서 배포 데이터베이스로 배달됩니다. 이때 복제에는 영향을 주지 않습니다.
    배포 데이터베이스에 이 옵션을 설정해도 복제 대기 시간에는 영향을 주지 않습니다. 그러나 배포 데이터베이스의 해당 트랜잭션이 백업될 때까지 게시 데이터베이스의 로그 잘라내기가 지연되므로 게시 데이터베이스의 트랜잭션 로그가 커질 수 있습니다.

  • 응용 프로그램에서 추가 대기 시간을 허용할 수 있는 경우 게시 데이터베이스에 이 옵션을 설정하는 것이 좋습니다.
    게시 데이터베이스에 이 옵션을 설정하면 트랜잭션은 게시 데이터베이스에서 백업될 때까지 배포 데이터베이스로 배달되지 않습니다. 그러면 복원된 게시 데이터베이스에 없는 트랜잭션이 배포 데이터베이스에 있을 수 없으므로 게시자에서 마지막 게시 데이터베이스 백업을 복원할 수 있습니다.
    트랜잭션이 게시자에서 백업될 때까지 배포 데이터베이스로 배달될 수 없으므로 지연 시간 및 처리량에 영향을 받습니다. 예를 들어 트랜잭션 로그가 5분마다 백업되는 경우 트랜잭션이 게시자에서 커밋된 후 배포 데이터베이스와 구독자로 차례로 배달되기까지 5분의 추가 대기 시간이 발생합니다.

    [!참고] sync with backup 옵션을 사용하면 게시 데이터베이스 및 배포 데이터베이스 간의 일관성을 유지할 수 있지만 데이터 손실이 있을 수 있습니다. 예를 들어 트랜잭션 로그가 손실되는 경우 마지막 트랜잭션 로그 백업 이후에 커밋된 트랜잭션은 게시 데이터베이스 또는 배포 데이터베이스에서 사용할 수 없습니다. 이 동작은 복제되지 않는 데이터베이스에서도 같습니다.

sync with backup 옵션을 설정하려면

복제와 관련된 데이터베이스 복원

최근 백업을 사용할 수 있는 상태에서 적절한 단계를 수행하면 복제 토폴로지의 모든 데이터베이스를 복원할 수 있습니다. 게시 데이터베이스의 복원 단계는 사용된 복제 유형 및 옵션에 따라 다르지만 다른 모든 데이터베이스의 복원 단계는 유형 및 옵션에 독립적입니다.

복제에서는 복제된 데이터베이스를 백업이 생성된 서버 및 데이터베이스로 복원할 수 있습니다. 복제된 데이터베이스의 백업을 다른 서버 또는 데이터베이스로 복원할 경우 복제 설정은 유지되지 않습니다. 이 경우 백업 복원 후 모든 게시 및 구독을 다시 만들어야 합니다.

게시자

다음과 같은 복제 유형에 대한 복원 단계가 제공됩니다.

  • 스냅숏 복제
  • 읽기 전용 트랜잭션 복제
  • 구독 업데이트가 있는 트랜잭션 복제
  • 피어 투 피어 트랜잭션 복제

이 4가지 복제에 대한 msdb 데이터베이스 및 master 데이터베이스(이 섹션에서 함께 설명됨)의 복원은 모두 동일합니다.

게시 데이터베이스: 스냅숏 복제

  1. 게시 데이터베이스의 최신 백업을 복원합니다. 2단계로 이동합니다.
  2. 게시 데이터베이스 백업이 모든 게시 및 구독에 대한 최신 구성을 포함하고 있는지 확인합니다. 그렇다면 복원이 완료된 것이며 그렇지 않으면 3단계로 이동합니다.
  3. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 후 구성을 다시 만듭니다. 복원이 완료되었습니다.
    복제 제거 방법은 복제 제거 및 sp_removedbreplication(Transact-SQL)을 참조하십시오.

게시 데이터베이스: 읽기 전용 트랜잭션 복제

  1. 게시 데이터베이스의 최신 백업을 복원합니다. 2단계로 이동합니다.
  2. 실패하기 전에 게시 데이터베이스에 sync with backup 옵션이 설정되었는지 확인합니다. 그렇다면 3단계로 이동하고, 그렇지 않으면 5단계로 이동합니다.
    옵션이 설정되어 있으면 SELECT DATABASEPROPERTYEX('<PublicationDatabaseName>', 'IsSyncWithBackup'); 쿼리가 '1'을 반환합니다.
  3. 복원된 백업이 완료되었으며 최신 상태인지, 이 백업이 모든 구독 및 게시에 대한 최신 구성을 포함하고 있는지 확인합니다. 그렇다면 복원이 완료된 것이며 그렇지 않으면 4단계로 이동합니다.
  4. 복원된 게시 데이터베이스의 구성 정보가 최신 상태가 아니므로 배포 데이터베이스의 처리 중인 모든 명령이 구독자에 배달되었는지 확인한 다음 복제 구성을 삭제하고 다시 만들어야 합니다.
    1. 모든 구독자가 배포 데이터베이스의 처리 중인 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터의 배포되지 않은 명령 탭을 사용하거나 배포 데이터베이스에서 MSdistribution_status 뷰를 쿼리하여 모든 명령이 구독자로 배달되었는지 확인합니다. b 단계로 이동합니다.
      배포 에이전트 실행 방법은 방법: 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 Programming Replication Agent Executables을 참조하십시오.
      명령 확인 방법은 How to: View Replicated Commands and Other Information in the Distribution Database (Replication Transact-SQL Programming) 및 방법: 구독 관련 에이전트에 대한 정보 보기 및 작업 수행(복제 모니터)을 참조하십시오.
    2. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 후 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있다고 지정합니다. 복원이 완료되었습니다.
      복제 제거 방법은 복제 제거 및 sp_removedbreplication(Transact-SQL)을 참조하십시오.
      구독자에 이미 데이터가 있다고 지정하는 방법은 방법: 수동으로 구독 초기화(SQL Server Management Studio) 및 How to: Initialize a Subscription Manually (Replication Transact-SQL Programming)를 참조하십시오.
  5. 게시 데이터베이스에 sync with backup 옵션이 설정되지 않아서 복원된 백업에 포함되지 않은 트랜잭션이 배포자 및 구독자에 배달되었을 수 있습니다. 배포 데이터베이스의 처리 중인 모든 명령이 구독자에 배달되었는지 확인한 다음 복원된 백업에 포함되지 않은 모든 트랜잭션을 게시 데이터베이스에 수동으로 적용해야 합니다.
    ms152560.note(ko-kr,SQL.90).gif중요:
    이 프로세스를 수행하면 게시된 테이블이 백업에서 복원된 다른 비게시 테이블보다 더 최신 시점으로 복원될 수 있습니다.
    1. 모든 구독자가 배포 데이터베이스의 처리 중인 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터의 **배포되지 않은 명령** 탭을 사용하거나 배포 데이터베이스에서 **MSdistribution\_status** 뷰를 쿼리하여 모든 명령이 구독자로 배달되었는지 확인합니다. b 단계로 이동합니다. 배포 에이전트 실행 방법은 [방법: 복제 에이전트 시작 및 중지(SQL Server Management Studio)](ms151783\(v=sql.90\).md) 및 [Programming Replication Agent Executables](ms147886\(v=sql.90\).md)을 참조하십시오. 명령 확인 방법은 [How to: View Replicated Commands and Other Information in the Distribution Database (Replication Transact-SQL Programming)](ms147306\(v=sql.90\).md) 및 [방법: 구독 관련 에이전트에 대한 정보 보기 및 작업 수행(복제 모니터)](ms152749\(v=sql.90\).md)을 참조하십시오. 2. [tablediff 유틸리티](ms162843\(v=sql.90\).md) 또는 다른 도구를 사용하여 게시자를 구독자와 수동으로 동기화합니다. 이렇게 하면 게시 데이터베이스 백업에 포함되지 않은 구독 데이터베이스에서 데이터를 복구할 수 있습니다. c 단계로 이동합니다. **tablediff** 유틸리티에 대한 자세한 내용은 [How to: Compare Replicated Tables for Differences (Replication Programming)](ms147919\(v=sql.90\).md)를 참조하십시오. 3. 복원된 백업이 완료되었으며 최신 상태인지, 이 백업이 모든 구독 및 게시에 대한 최신 구성을 포함하고 있는지 확인합니다. 그렇다면 저장 프로시저 [sp\_replrestart(Transact-SQL)](ms174390\(v=sql.90\).md)를 실행하여 게시자 메타데이터를 배포자 메타데이터와 다시 동기화합니다. 복원이 완료되었습니다. 그렇지 않으면 d 단계로 이동합니다. 4. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 후 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있다고 지정합니다. 복원이 완료되었습니다. 복제 제거 방법은 [복제 제거](ms152757\(v=sql.90\).md) 및 [sp\_removedbreplication(Transact-SQL)](ms188734\(v=sql.90\).md)을 참조하십시오. 구독자에 이미 데이터가 있다고 지정하는 방법은 [방법: 수동으로 구독 초기화(SQL Server Management Studio)](ms151246\(v=sql.90\).md) 및 [How to: Initialize a Subscription Manually (Replication Transact-SQL Programming)](ms147897\(v=sql.90\).md)를 참조하십시오.

게시 데이터베이스: 구독 업데이트가 있는 트랜잭션 복제

  1. 게시 데이터베이스의 최신 백업을 복원합니다. 2단계로 이동합니다.

  2. 모든 구독자가 배포 데이터베이스의 처리 중인 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터의 배포되지 않은 명령 탭을 사용하거나 배포 데이터베이스에서 MSdistribution_status 뷰를 쿼리하여 모든 명령이 구독자로 배달되었는지 확인합니다. 3단계로 이동합니다.
    배포 에이전트 실행 방법은 방법: 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 Programming Replication Agent Executables을 참조하십시오.
    명령 확인 방법은 How to: View Replicated Commands and Other Information in the Distribution Database (Replication Transact-SQL Programming) 및 방법: 구독 관련 에이전트에 대한 정보 보기 및 작업 수행(복제 모니터)을 참조하십시오.

  3. 지연 구독 업데이트를 사용하는 경우 각 구독자에 연결하고 구독 데이터베이스에 있는 MSreplication_queue 테이블의 모든 행을 삭제합니다. 4단계로 이동합니다.

    [!참고] 지연 구독 업데이트를 사용하고 테이블에 ID 열이 있는 경우 복원 후에 올바른 ID 범위가 지정되었는지 확인해야 합니다. 자세한 내용은 ID 열 복제를 참조하십시오.

  4. 배포 데이터베이스의 처리 중인 모든 명령이 구독자에 배달되었는지 확인한 다음 복원된 백업에 포함되지 않은 모든 트랜잭션을 게시 데이터베이스에 수동으로 적용해야 합니다.

    ms152560.note(ko-kr,SQL.90).gif중요:
    이 프로세스를 수행하면 게시된 테이블이 백업에서 복원된 다른 비게시 테이블보다 더 최신 시점으로 복원될 수 있습니다.
    1. 모든 구독자가 배포 데이터베이스의 처리 중인 명령과 동기화될 때까지 배포 에이전트를 실행합니다. 복제 모니터를 사용하거나 배포 데이터베이스에서 **MSdistribution\_status** 뷰를 쿼리하여 모든 명령이 구독자로 배달되었는지 확인합니다. b 단계로 이동합니다. 2. [tablediff 유틸리티](ms162843\(v=sql.90\).md) 또는 다른 도구를 사용하여 게시자를 구독자와 수동으로 동기화합니다. 이렇게 하면 게시 데이터베이스 백업에 포함되지 않은 구독 데이터베이스에서 데이터를 복구할 수 있습니다. c 단계로 이동합니다. **tablediff** 유틸리티에 대한 자세한 내용은 [How to: Compare Replicated Tables for Differences (Replication Programming)](ms147919\(v=sql.90\).md)를 참조하십시오. 3. 복원된 백업이 완료되었으며 최신 상태인지, 이 백업이 모든 구독 및 게시에 대한 최신 구성을 포함하고 있는지 확인합니다. 그렇다면 저장 프로시저 [sp\_replrestart(Transact-SQL)](ms174390\(v=sql.90\).md)를 실행하여 게시자 메타데이터를 배포자 메타데이터와 다시 동기화합니다. 복원이 완료되었습니다. 그렇지 않으면 d 단계로 이동합니다. 4. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 후 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있다고 지정합니다. 복원이 완료되었습니다. 복제 제거 방법은 [복제 제거](ms152757\(v=sql.90\).md) 및 [sp\_removedbreplication(Transact-SQL)](ms188734\(v=sql.90\).md)을 참조하십시오. 구독자에 이미 데이터가 있다고 지정하는 방법은 [방법: 수동으로 구독 초기화(SQL Server Management Studio)](ms151246\(v=sql.90\).md) 및 [How to: Initialize a Subscription Manually (Replication Transact-SQL Programming)](ms147897\(v=sql.90\).md)를 참조하십시오.

게시 데이터베이스: 피어 투 피어 트랜잭션 복제

다음 단계에서 A, B 및 C 게시 데이터베이스는 피어 투 피어 트랜잭션 복제 토폴로지에 있습니다. A 및 C 데이터베이스는 온라인 상태이며 제대로 작동하고 있습니다. B 데이터베이스는 복원될 데이터베이스입니다.

  1. 배포 에이전트를 실행하여 A 및 C 데이터베이스의 구독을 동기화합니다. 2단계로 이동합니다.
    배포 에이전트 실행 방법은 방법: 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 Programming Replication Agent Executables을 참조하십시오.
  2. B에 대한 배포 데이터베이스를 사용할 수 있는 경우 배포 에이전트를 실행하여 B 데이터베이스와 A 데이터베이스 간의 구독과 B 데이터베이스와 C 데이터베이스 간의 구독을 동기화합니다. 3단계로 이동합니다.
  3. B에 대한 배포 데이터베이스에서 sp_Removedistpublisherdbreplication(Transact-SQL)을 실행하여 B가 사용하는 배포 데이터베이스의 메타데이터를 제거합니다. 4단계로 이동합니다.
  4. A 및 C 데이터베이스에서 B 데이터베이스의 구독에 대한 게시를 삭제합니다. 5단계로 이동합니다.
    구독 삭제 방법은 게시 구독을 참조하십시오.
  5. A 데이터베이스의 로그 백업 또는 전체 백업을 수행합니다. 6단계로 이동합니다.
  6. A 데이터베이스의 백업을 B 데이터베이스로 복원합니다. 이제 B 데이터베이스에는 A 데이터베이스의 데이터는 있지만 복제 구성은 없습니다. 백업을 다른 서버로 복원하면 복제가 제거되므로 이 경우 B 데이터베이스에서 복제가 제거됩니다. 7단계로 이동합니다.
  7. B 데이터베이스의 게시를 다시 만든 후 A 데이터베이스와 B 데이터베이스 간에 구독을 다시 만듭니다. C 데이터베이스와 관련된 구독은 이후의 단계에서 처리됩니다.
    1. B 데이터베이스에 게시를 다시 만듭니다. b 단계로 이동합니다.
    2. B 데이터베이스에서 A 데이터베이스의 게시에 대한 구독을 다시 만들고 백업으로 구독이 초기화되도록 지정합니다. 즉, sp_addsubscription(Transact-SQL)의 @sync_type 매개 변수에 initialize with backup 값을 지정합니다. c 단계로 이동합니다.
    3. B 데이터베이스의 게시에 대한 구독을 A 데이터베이스에서 다시 만들고 구독자에 이미 데이터가 있다고 지정합니다. 즉, sp_addsubscription(Transact-SQL)의 @sync_type 매개 변수에 replication support only 값을 지정합니다. 8단계로 이동합니다.
      a 단계에서 c 단계까지를 가장 간단하게 수행하려면 피어 투 피어 토폴로지 구성 마법사를 사용합니다. 자세한 내용은 방법: 피어 투 피어 트랜잭션 복제 구성(SQL Server Management Studio)을 참조하십시오. 저장 프로시저를 사용할 수도 있습니다. 자세한 내용은 How to: Configure Peer-to-Peer Transactional Replication (Replication Transact-SQL Programming)을 참조하십시오.
  8. 배포 에이전트를 실행하여 A 및 B 데이터베이스의 구독을 동기화합니다. 게시된 테이블에 ID 열이 있는 경우 9단계로 이동하고 그렇지 않으면 10단계로 이동합니다.
  9. 복원 후에 A 데이터베이스의 각 테이블에 할당한 ID 범위는 B 데이터베이스에서도 사용됩니다. 복원된 B 데이터베이스가 실패한 B 데이터베이스의 모든 변경 내용(A 데이터베이스와 C 데이터베이스로 전파됨)을 받았는지 확인한 다음 각 테이블의 ID 범위에 대한 초기값을 다시 설정합니다.
    1. B 데이터베이스에서 sp_requestpeerresponse(Transact-SQL)를 실행하고 출력 매개 변수 @request_id를 검색합니다. b 단계로 이동합니다.
    2. 기본적으로 배포 에이전트는 연속적으로 실행되도록 설정되므로 토큰이 모든 노드로 자동 전송됩니다. 배포 에이전트가 연속 모드로 실행되지 않을 경우에는 에이전트를 실행합니다. 자세한 내용은 Programming Replication Agent Executables 또는 방법: 복제 에이전트 시작 및 중지(SQL Server Management Studio)를 참조하십시오. c 단계로 이동합니다.
    3. sp_helppeerresponses(Transact-SQL)를 실행한 다음 b 단계에서 검색된 @request_id 값을 제공하여 모든 노드가 피어 요청을 받았음을 나타낼 때까지 기다립니다. d 단계로 이동합니다.
    4. DBCC CHECKIDENT를 통해 B 데이터베이스에 있는 각 테이블의 ID 범위에 대한 초기값을 다시 설정하여 적절한 범위가 사용되도록 합니다. 10단계로 이동합니다.
      ID 범위 관리 방법은 ID 열 복제의 "ID 범위 수동 관리를 위한 범위 할당" 섹션을 참조하십시오.
  10. 이 시점에서 B 데이터베이스와 C 데이터베이스는 직접 연결되어 있지 않지만 A 데이터베이스를 통해 변경 내용을 받습니다. B 데이터베이스와 C 데이터베이스를 연결하려면 11단계에서 13단계까지를 완료합니다.
  11. 시스템을 정지합니다. 시스템 정지 과정에서는 모든 노드에서 게시된 테이블에 대한 작업을 중지하고 각 노드가 다른 모든 노드의 변경 내용을 받았는지 확인합니다.
    1. 피어 투 피어 토폴로지의 게시된 테이블에 대한 모든 작업을 중지합니다. b 단계로 이동합니다.
    2. B 데이터베이스에서 sp_requestpeerresponse(Transact-SQL)를 실행하고 출력 매개 변수 @request_id를 검색합니다. c 단계로 이동합니다.
    3. 기본적으로 배포 에이전트는 연속적으로 실행되도록 설정되므로 토큰이 모든 노드로 자동 전송됩니다. 배포 에이전트가 연속 모드로 실행되지 않을 경우에는 에이전트를 실행합니다. d 단계로 이동합니다.
    4. sp_helppeerresponses(Transact-SQL)를 실행한 다음 b 단계에서 @request_id 값을 제공하여 모든 노드가 피어 요청을 받았음을 나타낼 때까지 기다립니다. 12단계로 이동합니다.
  12. B 데이터베이스와 C 데이터베이스 간에 구독을 다시 만듭니다.
    1. B 데이터베이스에서 C 데이터베이스의 게시에 대한 구독을 다시 만들고 백업에서 구독이 초기화되도록 지정합니다. b 단계로 이동합니다.
    2. C 데이터베이스에서 B 데이터베이스의 게시에 대한 구독을 다시 만들고 구독자에 이미 데이터가 있다고 지정합니다. 13단계로 이동합니다.
  13. 배포 에이전트를 실행하여 B 및 C 데이터베이스의 구독을 동기화합니다. 복원이 완료되었습니다.

msdb 데이터베이스(게시자)

  1. msdb 데이터베이스의 최신 백업을 복원합니다.
  2. 복원된 백업이 완료되었으며 최신 상태인지, 이 백업이 모든 구독 및 게시에 대한 최신 구성을 포함하고 있는지 확인합니다. 그렇다면 복구가 완료된 것이며 그렇지 않으면 3단계로 이동합니다.
  3. 복제 스크립트에서 구독 정리 작업을 다시 만듭니다. 복구가 완료되었습니다.

master 데이터베이스(게시자)

  1. master 데이터베이스의 최신 백업을 복원합니다.
  2. 해당 데이터베이스의 복제 구성 및 설정이 게시 데이터베이스의 복제 구성 및 설정과 일치하는지 확인합니다.

배포자의 데이터베이스

배포 데이터베이스

  1. 배포 데이터베이스의 최신 백업을 복원합니다.
  2. 실패하기 전에 배포 데이터베이스에 sync with backup 옵션이 설정되었는지 확인합니다. 그렇다면 3단계로 이동하고, 그렇지 않으면 4단계로 이동합니다.
    옵션이 설정되어 있으면 SELECT DATABASEPROPERTYEX('<DistributionDatabaseName>', 'IsSyncWithBackup'); 쿼리가 '1'을 반환합니다.
  3. 복원된 백업이 완료되었으며 최신 상태인지, 이 백업이 모든 구독 및 게시에 대한 최신 구성을 포함하고 있는지 확인합니다. 그렇다면 복구가 완료된 것이며 그렇지 않으면 4단계로 이동합니다.
  4. 복원된 배포 데이터베이스의 구성 정보가 최신 상태가 아니거나 배포 데이터베이스에 sync with backup 옵션이 설정되지 않았습니다. 복원 후에 게시자에서 커밋되었지만 구독자로 배달되지 않은 트랜잭션이 배포 데이터베이스에는 없을 수도 있습니다. 복제를 삭제하고 다시 만든 다음 유효성 검사를 실행합니다.
    1. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 후 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있다고 지정합니다. b 단계로 이동합니다.
      복제 제거 방법은 복제 제거 및 sp_removedbreplication(Transact-SQL)을 참조하십시오.
      구독자에 이미 데이터가 있다고 지정하는 방법은 방법: 수동으로 구독 초기화(SQL Server Management Studio) 및 How to: Initialize a Subscription Manually (Replication Transact-SQL Programming)를 참조하십시오.
    2. 모든 게시의 유효성을 검사하도록 표시합니다. 유효성 검사에 실패한 모든 구독을 다시 초기화합니다. 복구가 완료되었습니다.
      유효성 검사에 대한 자세한 내용은 복제된 데이터의 유효성 검사를 참조하십시오.
      재초기화에 대한 자세한 내용은 구독 다시 초기화를 참조하십시오.

msdb 데이터베이스(배포자)

  1. msdb 데이터베이스의 최신 백업을 복원합니다.
  2. 복원된 백업이 완료되었으며 최신 상태인지, 이 백업이 모든 구독 및 게시에 대한 최신 구성을 포함하고 있는지 확인합니다. 그렇다면 복구가 완료된 것이며 그렇지 않으면 3단계로 이동합니다.
  3. 게시자, 배포자 및 구독자에서 복제 구성을 제거한 후 구성을 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있다고 지정합니다. 4단계로 이동합니다.
    복제 제거 방법은 복제 제거 및 sp_removedbreplication(Transact-SQL)을 참조하십시오.
    구독자에 이미 데이터가 있다고 지정하는 방법은 방법: 수동으로 구독 초기화(SQL Server Management Studio) 및 How to: Initialize a Subscription Manually (Replication Transact-SQL Programming)를 참조하십시오.
  4. 모든 게시의 유효성을 검사하도록 표시합니다. 유효성 검사에 실패한 모든 구독을 다시 초기화합니다. 복구가 완료되었습니다.
    유효성 검사에 대한 자세한 내용은 복제된 데이터의 유효성 검사를 참조하십시오.
    재초기화에 대한 자세한 내용은 구독 다시 초기화를 참조하십시오.

master 데이터베이스(배포자)

  1. master 데이터베이스의 최신 백업을 복원합니다.
  2. 해당 데이터베이스의 복제 구성 및 설정이 게시 데이터베이스의 복제 구성 및 설정과 일치하는지 확인합니다.

구독자의 데이터베이스

구독 데이터베이스

  1. 최신 구독 데이터베이스 백업이 배포 데이터베이스의 최대 배포 보존 기간 설정보다 최신인지 확인합니다. 이는 배포자에 구독자를 최신 상태로 만들기 위해 필요한 명령이 모두 있는지 여부를 확인합니다. 그렇다면 2단계로 이동하고, 그렇지 않으면 구독을 다시 초기화합니다. 복구가 완료되었습니다.
    최대 배포 보존 기간 설정을 결정하려면 sp_helpdistributiondb(Transact-SQL)를 실행하고 max_distretention 열의 값을 검색합니다. 이 값은 시간 단위로 표시됩니다.
    구독을 다시 초기화하는 방법은 방법: 구독 다시 초기화(SQL Server Management Studio) 및 How to: Reinitialize a Subscription (Replication Transact-SQL Programming)을 참조하십시오.
  2. 최신 구독 데이터베이스 백업을 복원합니다. 3단계로 이동합니다.
  3. 구독 데이터베이스에 밀어넣기 구독만 있는 경우 4단계로 이동합니다. 구독 데이터베이스에 끌어오기 구독이 있는 경우 구독 정보가 현재 정보인지, 이 구독 데이터베이스 백업이 오류 발생 시 설정된 테이블과 옵션을 모두 포함하고 있는지 확인합니다. 그렇다면 4단계로 이동하고, 그렇지 않으면 구독을 다시 초기화합니다. 복구가 완료되었습니다.
  4. 배포 에이전트를 실행하여 구독자를 동기화합니다. 복구가 완료되었습니다.
    배포 에이전트 실행 방법은 방법: 복제 에이전트 시작 및 중지(SQL Server Management Studio) 및 Programming Replication Agent Executables을 참조하십시오.

msdb 데이터베이스(구독자)

  1. msdb 데이터베이스의 최신 백업을 복원합니다. 이 구독자에서 끌어오기 구독이 사용되었는지 확인합니다. 그렇지 않으면 복원이 완료된 것입니다. 그렇다면 2단계로 이동합니다.
  2. 복원된 백업이 완료되었으며 최신 상태인지, 이 백업이 모든 끌어오기 구독에 대한 최신 구성을 포함하고 있는지 확인합니다. 그렇다면 복구가 완료된 것이며 그렇지 않으면 3단계로 이동합니다.
  3. 끌어오기 구독을 삭제하고 다시 만듭니다. 구독을 다시 만들 때 구독자에 이미 데이터가 있다고 지정합니다. 복원이 완료되었습니다.
    구독 삭제 방법은 게시 구독을 참조하십시오.
    구독자에 이미 데이터가 있다고 지정하는 방법은 방법: 수동으로 구독 초기화(SQL Server Management Studio) 및 How to: Initialize a Subscription Manually (Replication Transact-SQL Programming)를 참조하십시오.

master 데이터베이스(구독자)

  1. master 데이터베이스의 최신 백업을 복원합니다.
  2. 해당 데이터베이스의 복제 구성 및 설정이 게시 데이터베이스의 복제 구성 및 설정과 일치하는지 확인합니다.

참고 항목

개념

복제된 데이터베이스 백업 및 복원
배포 구성
데이터 및 데이터베이스 개체 게시
게시 구독
구독 초기화
데이터 동기화

관련 자료

SQL Server의 데이터베이스 백업 및 복원

도움말 및 정보

SQL Server 2005 지원 받기