데이터베이스 미러링 세션 중 역할 전환(SQL Server)
적용 대상: 
SQL Server
데이터베이스 미러링 세션에서는 역할 전환프로세스를 통해 주 역할과 미러 역할을 서로 바꿀 수 있습니다. 역할 전환에서 미러 서버는 주 서버의 장애 조치(failover) 파트너 역할을 수행하여, 보안 주체 역할을 인수하고 데이터베이스의 복사본을 복구하고 새 주 데이터베이스로서 온라인 상태로 전환합니다. 이전 주 서버(사용 가능한 경우)는 미러 역할을 맡고 해당 데이터베이스는 새로운 미러 데이터베이스가 됩니다. 여러 오류에 대한 응답이나 관리 용도로 역할이 전환될 수 있습니다.
참고 항목
이 항목에서는 데이터베이스 미러링 운영 모드에 익숙하다고 가정합니다. 자세한 내용은 Database Mirroring Operating Modes을 참조하세요.
다음 그림에서는 미러링 파트너, Partner_A 및 Partner_B가 일련의 자동 또는 수동 장애 조치(failover)를 통해 보안 주체 및 미러 역할을 전환하는 방법을 보여 줍니다.
Important
역할 전환 후 이전 주 데이터베이스에서 실행된 작업을 새 주 서버에서 다시 만들어 실행해야 합니다. 자세한 내용은 역할 전환 후 로그인 및 작업 관리(SQL Server)를 참조하세요.
자동 장애 조치( failover), 수동 장애 조치(failover) 및 강제 서비스(데이터 손실 가능)의 세 가지 역할 전환 유형이 있습니다. 각 형태에 대한 지원은 세션의 작동 모드에 따라 달라집니다.
참고 항목
이러한 작동 모드에 익숙하지 않은 경우 데이터베이스 미러링 작동 모드를 참조하세요.
수동 장애 조치
보안 우선 모드는 수동 장애 조치를 지원합니다. 데이터베이스 소유자는 데이터베이스가 동기화될 때마다 수동 장애 조치를 시작할 수 있습니다.
수동 장애 조치는 관리 목적으로 제공됩니다. 자세한 내용은 이 항목의 뒷부분에 나오는 수동 장애 조치(failover)를 참조하십시오.
자동 장애 조치(Failover)
미러링 모니터를 설정하면 보호 우선 모드에서 자동 장애 조치(Failover)를 지원합니다. 미러링 모니터 서버와 미러 서버가 서로 연결되어 있고 데이터베이스가 이미 동기화된 경우에 주 서버가 손실될 때만 자동 장애 조치(failover)가 발생합니다. 자세한 내용은 이 항목의 뒷부분에 나오는 자동 장애 조치(failover)를 참조하십시오.
강제 서비스 (데이터 손실 가능)
미러링 모니터가 설정되지 않은 경우 고성능 모드에서 보호 우선 모드의 강제 서비스가 지원됩니다. 주 서버가 손실되면 데이터베이스 소유자는 데이터 손실 가능성이 있는 미러 서버에 서비스를 강제 적용하여 데이터베이스를 사용할 수 있도록 할 수 있습니다.
참고 항목
성능 우선 모드에서는 WITNESS 속성을 OFF로 설정된 상태로 유지하는 것이 좋습니다. 그렇지 않고 데이터베이스를 온라인 상태로 설정하려면 미러 서버가 미러링 모니터에 연결되어야 합니다.
자세한 내용은 이 항목의 뒷부분에 나오는 강제 서비스(데이터 손실 가능)를 참조하세요.
다음 표에는 각 작동 모드에서 지원되는 장애 조치(failover) 형태가 요약되어 있습니다.
| 장애 조치(failover) 형식 | 고성능 | 미러링 모니터 서버가 없는 보안 우선 모드 | 미러링 모니터 서버가 있는 보안 우선 모드 |
|---|---|---|---|
| 자동 장애 조치(Failover) | 아니요 | 아니요 | 예 |
| 수동 장애 조치 | 아니요 | 예 | 예 |
| 강제 서비스(Forced service) | 예 | 예 | 아니요 |
역할 전환 후에는 모든 데이터베이스 사용자가 새 주 데이터베이스에 액세스할 수 있도록 두 파트너에 특정 메타데이터가 있어야 합니다. 또한 데이터베이스가 정기적인 일정에 따라 계속 백업되도록 하려면 새 주 서버에서 백업 작업을 만들어져야 합니다. 자세한 내용은 역할 전환 후 로그인 및 작업 관리(SQL Server)를 참조하세요.
역할 전환 중에 데이터베이스 미러링 서비스가 중단되는 시간은 역할 전환 유형 및 원인에 따라 달라집니다. 자세한 내용은 역할 전환 중 서비스 중단 예측(데이터베이스 미러링)을 참조하세요.
수동 장애 조치
수동 장애 조치(Failover)는 데이터베이스에서 클라이언트의 연결을 끊고 파트너의 역할을 반대로 바꿉니다. 이러한 수동 장애 조치는 보호 우선 모드에서만 지원됩니다.
섹션 내용:
업그레이드 중 가용성 유지 관리
데이터베이스 관리자는 가용성을 저하시키지 않고 하드웨어 또는 소프트웨어를 업그레이드하는 데 수동 장애 조치(failover)를 사용할 수 있습니다. 소프트웨어 업그레이드에 데이터베이스 미러링을 사용하려면 미러 서버 및/또는 시스템에서 이미 업그레이드를 받았어야 합니다.
참고 항목
데이터베이스 미러링은 롤링 업그레이드를 수행할 수 있어야 하지만 향후 변경 내용을 알 수 없기 때문에 보장되지는 않습니다. 자세한 내용은 Upgrading Mirrored Instances을 참조하세요.
다음 그림에서는 데이터베이스 서버 인스턴스를 업그레이드하는 동안 수동 장애 조치(failover)를 사용하여 데이터베이스 가용성을 유지하는 경우를 보여줍니다. 업그레이드가 완료되면 관리자는 필요에 따라 원래 서버 인스턴스로 장애 조치를 수행할 수 있습니다. 이 기능은 관리자가 미러링 세션을 중단하고 다른 곳에서 미러 서버를 사용하려는 경우에 유용합니다. 이러한 방식으로 일련의 데이터베이스 서버 인스턴스를 업데이트할 때 단일 서버 인스턴스를 반복적으로 사용할 수 있습니다.
수동 장애 조치에 필요한 조건
수동 장애 조치(failover)를 사용하려면 트랜잭션 보안을 FULL(즉, 보안 우선 모드)로 설정해야 합니다. 파트너가 연결되어 있으며 데이터베이스가 이미 동기화된 경우 수동 장애 조치가 지원됩니다.
수동 장애 조치 작동 방법
수동 장애 조치(failover)는 다음 일련의 작업을 시작합니다.
주 서버는 주 데이터베이스에서 클라이언트의 연결을 끊고 비상 로그를 미러 서버로 보낸 다음 미러 역할로 전환하기 위해 미러링 상태를 SYNCHRONIZING으로 설정합니다.
미러 서버는 주 서버에서 받은 마지막 로그 레코드의 LSN(로그 시퀀스 번호)을 장애 조치 LSN으로 기록합니다.
참고 항목
이 LSN을 보려면 sys.database_mirroring(Transact-SQL)에서 mirroring_failover_lsn 열을 선택합니다.
다시 실행 큐에서 로그가 대기 중인 경우 미러 서버에서는 미러 데이터베이스 롤포워드를 완료합니다. 소요 시간은 시스템 속도, 최근 작업 및 복구 큐에 있는 로그 양에 따라 달라집니다. 동기 작동 모드의 경우 다시 실행 큐의 크기를 제한하여 장애 조치(failover) 시간을 조절할 수 있습니다. 그러나 이 경우 미러 서버에서 동기화 상태를 계속 유지해야 하므로 주 서버의 속도가 느려질 수 있습니다.
참고 항목
Redo Queue의 현재 크기를 확인하려면 데이터베이스 미러링 성능 개체의 Redo Queue 성능 카운터를 사용합니다. 자세한 내용은 데이터베이스 미러링 모니터링(SQL Server)을 참조하세요.
미러 서버는 새 주 서버가 되고 이전 주 서버는 새 미러 서버가 됩니다.
새 주 서버는 커밋되지 않은 트랜잭션을 롤백하고 데이터베이스의 복사본을 주 데이터베이스로 온라인 상태로 만듭니다.
이전 주 서버가 미러 역할을 맡아 이전 주 데이터베이스가 미러 데이터베이스가 됩니다. 새 미러 서버는 새 주 데이터베이스를 사용하여 새 미러 데이터베이스를 신속하게 다시 동기화합니다.
참고 항목
새로운 미러 서버가 해당 데이터베이스를 다시 동기화한 후 즉시 장애 조치(Failover)를 반대 방향으로 다시 수행할 수 있습니다.
장애 조치(failover) 후 클라이언트는 현재 주 데이터베이스에 다시 연결해야 합니다. 자세한 내용은 데이터베이스 미러링 세션에 클라이언트 연결(SQL Server)을 참조하세요.
수동 장애 조치(failover)를 시작하려면
자동 장애 조치(Failover)
자동 장애 조치(failover)는 보호 우선 모드(자동 장애 조치(failover)를 동반한 보호 우선 모드)에서 미러링 모니터 서버로 실행되는 데이터베이스 미러링 세션에서만 지원됩니다. 자동 장애 조치(failover)가 있는 보안 우선 모드에서 데이터베이스가 동기화된 상태에서 주 데이터베이스를 사용할 수 없게 되면 자동 장애 조치(failover)가 발생합니다. 자동 장애 조치가 수행되면 미러 서버가 주 서버의 역할을 맡고 해당 데이터베이스의 복사본이 주 데이터베이스로 온라인 상태가 됩니다. 데이터베이스가 동기화되어야 한다는 점에서 주 데이터베이스에서 커밋된 모든 트랜잭션이 미러 데이터베이스에서도 커밋되기 때문에 장애 조치 중에 데이터 손실이 방지됩니다.
Important
자동 장애 조치로 안정성을 개선하려면 미러 데이터베이스와 주 데이터베이스가 서로 다른 컴퓨터에 있어야 합니다.
섹션 내용:
자동 장애 조치(Failover)에 필요한 조건
자동 장애 조치(Failover)에는 다음 조건이 필요합니다.
데이터베이스 미러링 세션은 보안 우선 모드에서 실행되어야 하며 미러링 모니터를 소유해야 합니다. 자세한 내용은 Database Mirroring Operating Modes을 참조하세요.
미러 데이터베이스가 이미 동기화된 상태여야 합니다. 이렇게 하면 미러 서버로 전송된 모든 로그가 디스크에 기록됩니다.
주 서버는 나머지 데이터베이스 미러링 구성과의 통신이 끊어졌고 미러 및 미러링 모니터는 쿼럼을 유지합니다. 그러나 모든 서버 인스턴스에서 통신이 끊기고 미러링 모니터와 미러 서버가 나중에 통신을 다시 시작하면 자동 장애 조치(failover)가 발생하지 않습니다.
참고 항목
자세한 내용은 쿼럼: 미러링 모니터가 데이터베이스 가용성에 미치는 영향(데이터베이스 미러링)을 참조하세요.
미러 서버에서 주 서버의 손실을 감지했습니다.
미러 서버에서 주 서버의 오류를 감지하는 방식은 하드 또는 소프트 오류인지에 따라 달라집니다. 자세한 내용은 Possible Failures During Database Mirroring을 참조하세요.
자동 장애 조치(Failover) 작동 방법
위의 조건 하에서 자동 장애 조치는 다음과 같은 일련의 동작을 시작합니다.
주 서버가 계속 실행 중인 경우 주 데이터베이스의 상태를 DISCONNECTED로 변경하고 주 데이터베이스에서 모든 클라이언트의 연결을 끊습니다.
미러링 모니터와 미러 서버는 주 서버를 사용할 수 없음으로 등록합니다.
다시 실행 큐에서 로그가 대기 중인 경우 미러 서버에서는 미러 데이터베이스 롤포워드를 완료합니다.
참고 항목
로그를 적용하는 데 필요한 시간은 시스템 속도, 최근 작업 및 Redo Queue에 있는 로그 양에 따라 달라집니다.
이전 미러 데이터베이스는 새 주 데이터베이스로서 온라인 상태가 되고 복구를 통해 가능한 한 신속하게 롤백하여 커밋되지 않은 모든 트랜잭션을 정리합니다. 잠금은 이러한 트랜잭션을 격리합니다.
이전의 주 서버는 세션에 다시 참가할 때 해당 장애 조치 파트너가 이제 주 역할을 소유함을 인식합니다. 이전 주 서버는 미러 역할을 맡아 데이터베이스를 미러 데이터베이스로 만듭니다. 새 미러 서버는 최대한 신속하게 새 미러 데이터베이스를 주 데이터베이스와 동기화합니다. 새로운 미러 서버가 해당 데이터베이스를 다시 동기화한 후 즉시 장애 조치(Failover)를 반대 방향으로 다시 수행할 수 있습니다.
다음 그림에서는 자동 장애 조치(failover)의 단일 인스턴스를 보여 줍니다.
처음에는 세 서버가 모두 연결됩니다(세션에 전체 쿼럼이 있습니다). Partner_A가 주 서버이고 Partner_B는 미러 서버입니다. Partner_A(또는 Partner_A의 주 데이터베이스)를 사용할 수 없게 됩니다. 미러링 모니터와 Partner_B 모두 보안 주체를 더 이상 사용할 수 없다는 것을 인식하고 세션은 쿼럼을 유지합니다. Partner_B는 주 서버가 되고 데이터베이스의 복사본을 새 주 데이터베이스로 사용할 수 있게 합니다. 결국, Partner_A가 세션에 다시 연결하면 Partner_B가 주 역할을 보유하고 있음을 확인할 수 있습니다. 그런 다음 Partner_A는 미러 역할을 맡습니다.
장애 조치(failover) 후 클라이언트는 현재 주 데이터베이스에 다시 연결해야 합니다. 자세한 내용은 데이터베이스 미러링 세션에 클라이언트 연결(SQL Server)을 참조하세요.
참고 항목
Microsoft Distributed Transaction Coordinator를 사용하여 준비되었지만 장애 조치(failover)가 발생할 때까지도 커밋되지 않은 트랜잭션은 데이터베이스가 장애 조치(failover)된 후 중단된 것으로 간주됩니다.
자동 장애 조치(failover)를 해제하려면(SQL Server Management Studio)
데이터베이스 PropertiesMirroring 페이지를 열고 다음 옵션 중 하나를 선택하여 작동 모드를 변경합니다.
자동 장애 조치(Failover)가 없는 보호 우선(동기)
이 모드에서는 데이터베이스가 계속 동기화되고 수동 장애 조치(failover)가 계속 가능할 수 있습니다.
고성능(비동기)
이 모드에서는 미러 데이터베이스가 주 데이터베이스보다 지연될 수 있으며 수동 장애 조치를 수행할 수 없습니다.
자동 장애 조치를 해제하려면(Transact-SQL 사용)
데이터베이스 미러링 세션의 어느 지점에서든 데이터베이스 소유자는 미러링 모니터를 해제하여 자동 장애 조치(failover)를 사용하지 않도록 설정할 수 있습니다.
미러링 모니터를 비활성화하려면
데이터베이스 미러링 세션에서 미러링 모니터 서버 제거(SQL Server)
참고 항목
전체 트랜잭션 안전을 유지하면서 미러링 모니터를 비활성화하면 자동 장애 조치(failover) 없이 세션을 보안 우선 모드로 전환할 수 있습니다.
강제 서비스 (데이터 손실 가능)
데이터베이스 미러링이 재해 복구 방법으로 강제 서비스(데이터 손실 가능)를 제공하여 미러 서버를 웜 대기 서버로 사용할 수 있습니다. 미러링 세션에서 주 서버가 미러 서버와 연결이 끊긴 경우에만 서비스를 강제 적용할 수 있습니다. 강제 서비스로 인해 데이터 손실이 발생할 수 있으므로 신중하게 사용하며 무분별한 사용을 피해야 합니다.
강제 서비스 지원은 세션의 운영 모드와 상태에 따라 다음과 같이 달라집니다.
일반적으로 성능 우선 모드에서는 주 서버의 연결이 끊어질 때마다 강제 서비스 적용을 지원합니다. 그러나 필요하지는 않지만 고성능 모드 세션에 대한 미러링 모니터가 존재할 수 있습니다. 이 경우 강제 서비스를 사용하려면 미러링 모니터가 서로 연결되어야 합니다.
자동 장애 조치(failover)가 없는 보호 우선 모드는 주 서버의 연결이 끊어질 때마다 강제 서비스를 지원합니다.
자동 장애 조치(failover)가 있는 보호 우선 모드는 미러 서버와 미러링 모니터가 서로 연결되고 주 서버에 연결되지 않을 때마다 강제 서비스를 지원합니다(미러 서버가 보안 주 서버에 마지막으로 연결되었을 때 미러 데이터베이스를 롤백하는 과정에 있지 않은 경우).
데이터베이스로 서비스를 즉시 복구해야 하며 일부 데이터가 손실되는 위험을 감수하려는 경우에만 서비스를 강제 실행하는 것이 좋습니다. 강제 서비스의 효과는 미러링 제거와 유사합니다. 단, 강제 서비스를 사용하면 데이터 손실이 발생할 위험이 있는 상황에서 미러링이 다시 시작될 때 데이터베이스를 쉽게 다시 동기화할 수 있습니다. 강제 서비스는 주 역할이 미러 데이터베이스로 원활하게 전환되도록 합니다. 미러 서버는 주 서버 역할로 간주되며 즉시 주 서버의 데이터베이스 복사본을 클라이언트에게 제공합니다. 새 주 데이터베이스는 미러 없이 실행됩니다(즉, 노출됨).
Important
주 서버가 데이터베이스 미러링 세션과의 연결이 끊어졌으며 여전히 실행 중인 경우 일부 클라이언트는 원래 주 데이터베이스에 계속 액세스할 수 있습니다. 서비스를 강제 적용하기 전에 클라이언트가 원래 주 서버에 액세스하지 못하도록 하는 것이 중요합니다. 그렇지 않으면 서비스가 강제 적용된 후 원래 주 데이터베이스와 현재 주 데이터베이스를 다른 주 데이터베이스와 독립적으로 업데이트할 수 있습니다.
섹션 내용:
강제 서비스의 일반적인 사례
다음 그림에서는 (데이터 손실이 발생할 수 있는) 일반적인 강제 서비스 사례를 보여 줍니다.
그림에서 원래 주 서버인 Partner_A는 미러 서버인 Partner_B에서 사용할 수 없게 되어 미러 데이터베이스의 연결이 끊어집니다. 클라이언트에서 Partner_A를 사용할 수 없도록 한 후 데이터베이스 관리자는 Partner_B의 데이터 손실이 발생할 수 있는 서비스를 강제로 적용합니다. Partner_B 가 주 서버가 되고 데이터베이스가 노출된 상태 (즉, 미러되지 않은 상태)로 실행됩니다. 이 시점에서 클라이언트는 Partner_B에 다시 연결할 수 있습니다.
Partner_A가 사용할 수 있게 되면 새 주 서버에 다시 연결하여 세션에 다시 참가하고 미러 역할을 맡습니다. 미러링 세션이 새 미러 데이터베이스를 동기화하지 않고 즉시 일시 중단됩니다. 세션을 일시 중단하면 데이터베이스 관리자가 세션을 다시 시작할지 또는 극단적인 경우 미러링을 제거하고 이전 주 데이터베이스에서 데이터를 회수할 것인지 결정할 수 있습니다. 이 경우 데이터베이스 관리자는 미러링을 다시 시작하도록 선택합니다. 이 시점에서 Partner_A가 미러 서버의 역할을 맡아 마지막으로 성공적으로 동기화된 트랜잭션의 시점으로 이전 주 데이터베이스를 롤백합니다. 서비스가 강제 적용되기 전에 커밋된 트랜잭션이 미러 서버의 디스크에 기록되지 않은 경우 손실됩니다. 그런 다음 Partner_A는 이전 미러 서버가 새 주 서버가 된 이후 새 주 데이터베이스에 변경 내용을 적용하여 새 미러 데이터베이스를 롤 포워드합니다.
참고 항목
성능 우선 모드에서는 미러링 모니터 서버가 필요하지 않지만 미러링 모니터 서버가 구성된 경우 현재 미러 서버에 연결되어 있어야만 서비스를 강제 적용할 수 있습니다.
강제 서비스 위험
강제 서비스로 인해 데이터가 손실될 수 있음을 이해해야 합니다. 미러 서버가 주 서버와 통신이 불가능함에 따라 두 데이터베이스가 동기화되도록 보장할 수 없으므로 데이터 손실이 발생할 수 있습니다. 서비스를 강제 적용하면 새 복구 분기가 시작됩니다. 원래 주 데이터베이스와 미러 데이터베이스가 서로 다른 복구 분기에 있으므로 이제 각 데이터베이스에는 다른 데이터베이스에 없는 데이터가 포함됩니다. 원래 주 데이터베이스에는 Send Queue에서 이전의 미러 데이터베이스로 아직 전송되지 않은 변경 내용(보내지 않은 로그)이 포함되고 이전의 미러 데이터베이스에는 서비스가 강제 적용된 후 발생한 변경 내용이 포함됩니다.
주 서버가 실패하여 서비스가 강제 적용된 경우 발생 가능한 데이터 손실은 실패 전에 미러 서버로 보내지 않은 트랜잭션 로그가 있는지 여부에 따라 달라집니다. 보안 우선 모드에서는 미러 데이터베이스가 동기화될 때까지만 가능합니다. 고성능 모드에서는 누적된 미전송 로그가 항상 발생할 수 있습니다.
강제 서비스 적용의 의미는 부분적으로 세션에 미러링 모니터 서버가 있는지 여부에 따라 달라집니다.
미러링 모니터 서버가 없을 경우 네트워크 연결이 끊기는 등의 이유로 파트너의 연결이 끊어지면 서비스를 강제 적용할 수 있습니다. 원래 주 서버가 여전히 실행되고 있으면 두 파트너가 모두 주 역할을 소유합니다. 새로운 주 서버에 연결하는 클라이언트는 데이터베이스의 현재 버전에 액세스하고, 원래 주 서버에 연결하는 클라이언트는 원래 주 데이터베이스에 액세스합니다. 이 경우 데이터 손실 가능성이 높아집니다. 파트너가 다시 연결할 수 있는 경우 원래 주 서버는 미러 역할을 맡고 데이터베이스의 상태를 '복구 중'으로 변경한 후 미러링을 일시 중단됩니다. 세션이 재개되면 가장 최근에 연결이 끊어질 때 해당 로그가 Send Queue에 있었던 원래 주 데이터베이스의 트랜잭션이 손실됩니다. 또한 서비스가 강제 적용된 후에 발생한 모든 트랜잭션도 소실됩니다.
미러링 모니터가 존재하는 상태에서 미러 서버가 주 서버와 미러링 모니터 모두에서 연결이 끊어진 경우 후자의 두 서버가 서로 연결되어 있는 한, 기본 보안 주체가 노출됩니다. 주 서버가 미러링 모니터와 연결이 끊어지면 데이터베이스 제공이 중지됩니다. 이후에 미러 서버가 미러링 모니터 서버에 다시 연결하면 서비스를 강제 적용할 수 있습니다. 서비스가 강제로 적용되는 경우 원래 주 서버가 노출되는 동안 적용된 모든 변경 내용이 원래 주 서버가 다시 연결되면 소실됩니다.
자세한 내용은 이 항목의 뒷부분에 나오는 잠재적 데이터 손실 관리를 참조하십시오.
잠재적 데이터 손실 관리
서비스가 강제 적용된 후 이전 주 서버를 사용할 수 있게 되면 데이터베이스가 손상되지 않은 것으로 가정하여 잠재적인 데이터 손실을 관리할 수 있습니다. 잠재적인 데이터 손실을 관리하는 데 사용할 수 있는 방법은 원래 주 서버가 해당 파트너에 다시 연결하고 미러링 세션에 다시 참가했는지 여부에 따라 달라집니다. 원래 주 서버가 새로운 주 인스턴스에 액세스할 수 있다고 가정하면 자동으로 투명하게 다시 연결할 수 있습니다.
원래 주 서버가 다시 연결된 경우
일반적으로 실패 후에 원래 주 서버가 다시 시작되면 신속하게 해당 파트너에 다시 연결합니다. 다시 연결할 때 원래 주 서버는 미러 서버가 됩니다. 해당 데이터베이스는 미러 데이터베이스가 되고 세션이 일시 중단되기 전에 복구 상태로 진입합니다. 미러링을 다시 시작하지 않는 한 미러 데이터베이스는 롤백되지 않습니다.
그러나 복구 데이터베이스에 액세스할 수 없습니다. 따라서 미러링을 다시 시작하면 어떤 데이터가 손실될 것인지를 평가하기 위한 검사를 수행할 수 없습니다. 따라서 데이터 손실을 감수할지 여부에 따라 미러링을 재개할지 또는 제거할지 결정합니다.
데이터 손실이 허용되지 않는 경우 미러링을 제거하여 데이터를 복원해야 합니다.
미러링을 제거하면 데이터베이스 관리자가 원래 주 데이터베이스를 복구하고 손실된 데이터의 복구를 시도할 수 있습니다. 그러나 이전 미러 데이터베이스가 온라인 상태가 되면 이전 파트너는 동일한 이름으로 서로 다른 데이터베이스를 제공하게 됩니다. 데이터베이스 관리자는 데이터베이스 중 하나를 클라이언트에서 액세스할 수 없도록 만들어 데이터베이스가 더 이상 달라지지 않도록 하고 클라이언트 장애 조치 문제를 방지해야 합니다.
데이터 손실이 허용되는 경우 미러링을 재개할 수 있습니다.
미러 데이터베이스를 재개하면 데이터베이스 동기화의 첫 번째 단계로 신규 데이터베이스가 롤백됩니다. 실패 시 송신 큐에서 대기 중인 로그 레코드가 있으면 커밋된 경우에도 해당 트랜잭션이 손실됩니다.
원래 주 서버가 다시 연결되지 않은 경우
원래 주 서버에서 네트워크를 통해 새로운 주 서버에 다시 연결하지 않도록 일시적으로 차단할 수 있으면 원래 주 데이터베이스를 검사하여 미러링을 재개할 경우 손실될 데이터를 평가할 수 있습니다.
잠재적 데이터 손실이 허용되는 경우
원래 주 서버가 해당 파트너에 다시 연결할 수 있도록 합니다. 다시 연결하면 미러링이 일시 중단됩니다. 미러링을 진행하려면 세션을 다시 시작하면 됩니다. 이전 주 서버는 미러 역할을 맡습니다. 새 미러 서버는 원래 복구 포크를 삭제하여 이전 미러 서버에 전송되거나 수신되지 않은 트랜잭션이 소실됩니다.
데이터 손실이 허용되지 않는 경우
세션을 다시 시작하면 손실될 중요한 데이터가 원래 주 데이터베이스에 포함된 경우, 미러링을 제거하여 원래 주 서버의 데이터를 보존할 수 있습니다. 이 시점에서 보안 주체의 비상 로그를 백업하는 것이 좋습니다. 그런 다음 원래 주 데이터베이스에서 회수할 데이터를 내보내고 현재 주 데이터베이스로 가져와 현재 보안 주체(이전 미러 데이터베이스)를 업데이트할 수 있습니다. 업데이트된 데이터베이스의 전체 데이터베이스 백업을 최대한 빨리 수행하는 것이 좋습니다.
업데이트된 데이터베이스를 초기 주 데이터베이스로 사용하여 미러링을 다시 설정하려면 이 백업(및 하나 이상의 후속 로그 백업)을 사용하여 새 미러 데이터베이스를 만듭니다. 미러링이 제거된 후에 수행된 모든 로그 백업을 적용해야 합니다. 따라서 새 미러링 세션이 시작될 때까지 주 데이터베이스의 추가 로그 백업을 지연하는 것이 좋습니다.
강제 장애 조치(failover) 관리를 위한 관련 작업
서비스를 강제 적용하려면
데이터베이스 미러링을 재개하려면
새 데이터베이스를 만들려면
데이터베이스 미러링을 시작하려면
참고 항목
역할 전환 중 서비스 중단 예측(데이터베이스 미러링)
데이터베이스 미러링 중에 발생 가능한 오류
데이터베이스 미러링 세션(SQL Server)에 클라이언트 연결
데이터베이스 미러링 모니터 서버
전체 데이터베이스 복원(전체 복구 모델)
데이터베이스 미러링 운영 모드
미러링 상태(SQL Server)