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