데이터베이스 미러링 세션 중 역할 전환(SQL Server)

아티클
09/10/2013

데이터베이스 미러링 세션에서는 역할 전환 프로세스를 통해 주 역할과 미러 역할을 서로 바꿀 수 있습니다. 역할 전환 시 미러 서버는 주 서버에 대한 장애 조치(Failover) 파트너 역할을 하며 주 역할을 넘겨 받아 해당 데이터베이스 복사본을 복원하고 새로운 주 데이터베이스로 사용할 수 있도록 온라인 상태로 만듭니다. 이전 주 서버는 가능할 경우 미러 서버 역할을 맡으며 이 서버의 데이터베이스는 새 미러 데이터베이스가 됩니다. 여러 오류에 대한 응답이나 관리 용도로 역할이 전환될 수 있습니다.

[!참고]

이 항목에서는 사용자가 데이터베이스 미러링 운영 모드에 대해 잘 알고 있다고 가정합니다. 자세한 내용은 데이터베이스 미러링 운영 모드를 참조하십시오.

다음 그림에서는 일련의 자동 또는 수동 장애 조치를 수행하는 동안 주 역할과 미러 역할을 전환하는 미러링 파트너 Partner_A와 Partner_B를 보여 줍니다.

역할을 두 번 전환하는 파트너

중요
역할 전환 후 이전 주 데이터베이스에서 실행하던 작업을 새로운 주 데이터베이스에서 다시 만들어 실행해야 합니다. 자세한 내용은 역할 전환 후 로그인 및 작업 관리(SQL Server)를 참조하십시오.

역할 전환에는 자동 장애 조치(failover), 수동 장애 조치(failover) 및 강제 서비스(데이터 손실 가능)의 3가지 유형이 있습니다. 각 유형에 대한 지원은 세션의 운영 모드에 따라 달라집니다.

[!참고]

이러한 운영 모드에 대한 자세한 내용은 데이터베이스 미러링 운영 모드을 참조하십시오.

수동 장애 조치

보안 우선 모드는 수동 장애 조치를 지원합니다. 데이터베이스 소유자는 데이터베이스가 동기화될 때마다 수동 장애 조치를 시작할 수 있습니다.

수동 장애 조치는 관리 목적으로 제공됩니다. 자세한 내용은 이 항목의 뒷부분에 나오는 수동 장애 조치(failover)를 참조하십시오.
자동 장애 조치(failover)

미러링 모니터 서버가 있는 경우 보안 우선 모드에서 자동 장애 조치가 지원됩니다. 자동 장애 조치는 미러링 모니터 서버와 미러 서버가 서로 연결되어 있고 데이터베이스가 이미 동기화된 경우 주 서버가 손실될 때에만 수행됩니다. 자세한 내용은 이 항목의 뒷부분에 나오는 자동 장애 조치(failover)를 참조하십시오.
강제 서비스(데이터 손실 가능)

강제 서비스는 미러링 모니터 서버가 설정되어 있지 않은 보안 우선 모드와 성능 우선 모드에서 지원됩니다. 주 서버를 손실한 경우 데이터베이스 소유자는 데이터베이스를 사용할 수 있도록 미러 서버에 서비스를 강제 적용할 수 있으며 이 경우 데이터가 손실될 수 있습니다.

[!참고]

성능 우선 모드에서는 WITNESS 속성을 OFF로 설정하는 것이 좋습니다. 그렇지 않으면 데이터베이스를 온라인 상태로 만들려는 경우 미러 서버가 미러링 모니터에 연결해야 합니다.

자세한 내용은 이 항목의 뒷부분에 나오는 강제 서비스(데이터 손실 가능)를 참조하십시오.

다음 표에서는 각 운영 모드에서 지원되는 장애 조치 유형을 요약합니다.

	성능 우선	미러링 모니터 서버가 없는 보안 우선 모드	미러링 모니터 서버가 있는 보안 우선 모드
자동 장애 조치(failover)	아니요	아니요	예
수동 장애 조치(failover)	아니요	예	예
강제 서비스	예	예	아니요

역할 전환 후 모든 데이터베이스 사용자가 새로운 주 데이터베이스에 액세스할 수 있게 하려면 특정 메타데이터가 두 파트너에 모두 있어야 합니다. 또한 데이터베이스가 정기적인 일정에 따라 계속 백업되게 하려면 새로운 주 서버에서 백업 작업을 만들어야 합니다. 자세한 내용은 역할 전환 후 로그인 및 작업 관리(SQL Server)를 참조하십시오.

역할 전환 중에 데이터베이스 미러링의 서비스가 중단되는 시간은 역할 전환의 유형 및 원인에 따라 달라집니다. 자세한 내용은 역할 전환 중 서비스 중단 예측(데이터베이스 미러링)을 참조하십시오.

수동 장애 조치(Failover)

수동 장애 조치(Failover)는 데이터베이스에서 클라이언트의 연결을 끊고 파트너의 역할을 반대로 바꿉니다. 이러한 수동 장애 조치는 보호 우선 모드에서만 지원됩니다.

섹션 내용

업그레이드 중에 가용성 유지
수동 장애 조치(Failover)에 필요한 상태
수동 장애 조치(Failover) 작동 방법

업그레이드 중에 가용성 유지

데이터베이스 관리자는 수동 장애 조치를 사용하여 가용성에 영향을 주지 않고 하드웨어 또는 소프트웨어를 업그레이드할 수 있습니다. 소프트웨어 업그레이드 시 데이터베이스 미러링을 사용하려면 미러 서버 및/또는 시스템에 이미 해당 업그레이드가 있어야 합니다.

[!참고]

데이터베이스 미러링에서 롤링 업그레이드를 수행할 수도 있지만 이 기능은 이후 변경 내용을 알 수 없으므로 보장되지 않습니다. 자세한 내용은 서버 인스턴스 업그레이드 시 미러된 데이터베이스의 작동 중단 최소화를 참조하십시오.

다음 그림에서는 데이터베이스 서버 인스턴스를 업그레이드하는 동안 데이터베이스 가용성을 유지하기 위해 수동 장애 조치를 사용하는 예를 설명합니다. 업그레이드가 완료되면 관리자는 필요에 따라 원래 서버 인스턴스로 장애 조치를 수행할 수 있습니다. 이는 관리자가 미러링 세션을 중지하고 미러 서버를 다른 곳에서 사용하려는 경우에 유용합니다. 이러한 방법으로 일련의 데이터베이스 서버 인스턴스를 업데이트할 때 단일 서버 인스턴스를 반복적으로 사용할 수 있습니다.

계획된 수동 장애 조치(Failover)

수동 장애 조치에 필요한 조건

수동 장애 조치를 수행하려면 트랜잭션 보안이 FULL(보호 우선 모드)로 설정되어야 합니다. 파트너가 연결되어 있으며 데이터베이스가 이미 동기화된 경우 수동 장애 조치가 지원됩니다.

수동 장애 조치 작동 방법

수동 장애 조치의 동작 순서는 다음과 같습니다.

주 서버는 주 데이터베이스에서 클라이언트의 연결을 끊고 비상 로그를 미러 서버로 보낸 다음 미러 역할로 전환하기 위해 미러링 상태를 SYNCHRONIZING으로 설정합니다.
미러 서버는 주 서버에서 받은 마지막 로그 레코드의 LSN(로그 시퀀스 번호)을 장애 조치 LSN으로 기록합니다.

[!참고]

이 LSN을 보려면 sys.database_mirroring(Transact-SQL)에서 mirroring_failover_lsn 열을 선택하십시오.
Redo Queue에서 대기 중인 로그가 있으면 미러 서버가 미러 데이터베이스의 롤포워드를 마칩니다. 소요 시간은 시스템 속도, 최근 작업 및 Redo Queue에 있는 로그 양에 따라 달라집니다. 동기 운영 모드의 경우 Redo Queue의 크기를 제한하여 장애 조치 시간을 조정할 수 있습니다. 그러나 이 경우 미러 서버에서 동기화 상태를 계속 유지해야 하므로 주 서버의 속도가 느려질 수 있습니다.

[!참고]

Redo Queue의 현재 크기를 확인하려면 데이터베이스 미러링 성능 개체의 Redo Queue 성능 카운터를 사용합니다. 자세한 내용은 데이터베이스 미러링 모니터링(SQL Server)을 참조하십시오.
미러 서버는 새 주 서버가 되고 이전 주 서버는 새 미러 서버가 됩니다.
새 주 서버는 커밋되지 않은 모든 트랜잭션을 롤백하고 해당 데이터베이스의 복사본을 주 데이터베이스로 사용할 수 있도록 온라인 상태로 만듭니다.
이전 주 서버가 미러 역할을 맡아 이전 주 데이터베이스가 미러 데이터베이스가 됩니다. 새 미러 서버는 신속하게 새 미러 데이터베이스를 새 주 데이터베이스와 다시 동기화합니다.

[!참고]

새 미러 서버에서 데이터베이스를 다시 동기화하면 장애 조치가 다시 가능해지지만 역방향으로 진행됩니다.

장애 조치 후 클라이언트는 현재의 주 데이터베이스에 다시 연결해야 합니다. 자세한 내용은 데이터베이스 미러링 세션에 클라이언트 연결(SQL Server)을 참조하십시오.

수동 장애 조치를 시작하려면

자동 장애 조치(Failover)

자동 장애 조치는 미러링 모니터 서버에서 보호 우선 모드(자동 장애 조치를 지원하는 보호 우선 모드)로 실행되는 데이터베이스 미러링 세션에서만 지원됩니다. 자동 장애 조치를 지원하는 보호 우선 모드에서 데이터베이스가 동기화된 후 주 데이터베이스를 사용할 수 없게 되면 자동 장애 조치가 수행됩니다. 자동 장애 조치가 수행되면 미러 서버가 주 서버의 역할을 맡고 해당 데이터베이스의 복사본이 주 데이터베이스로 온라인 상태가 됩니다. 데이터베이스가 동기화되어야 한다는 점에서 주 데이터베이스에서 커밋된 모든 트랜잭션이 미러 데이터베이스에서도 커밋되기 때문에 장애 조치 중에 데이터 손실이 방지됩니다.

중요
자동 장애 조치로 안정성을 개선하려면 미러 데이터베이스와 주 데이터베이스가 서로 다른 컴퓨터에 있어야 합니다.

섹션 내용

자동 장애 조치(Failover)에 필요한 상태
자동 장애 조치(Failover) 작동 방법
자동 장애 조치(failover)를 해제하려면(SQL Server Management Studio)
자동 장애 조치를 해제하려면(Transact-SQL 사용)

자동 장애 조치(Failover)에 필요한 상태

자동 장애 조치(failover)에는 다음 조건이 필요합니다.

데이터베이스 미러링 세션이 보호 우선 모드로 실행되고 있어야 하고 미러링 모니터 서버가 있어야 합니다. 자세한 내용은 데이터베이스 미러링 운영 모드를 참조하십시오.
미러 데이터베이스가 이미 동기화된 상태여야 합니다. 이는 미러 서버로 보낸 모든 로그가 디스크에 기록되었음을 나타냅니다.
데이터베이스 미러링 구성의 나머지 부분과 주 서버 간의 통신이 끊어졌지만 미러 서버와 미러링 모니터 서버는 쿼럼을 유지합니다. 그러나 모든 서버 인스턴스의 통신이 끊어지고 나중에 미러링 모니터 서버와 미러 서버에서 통신을 회복한 경우에는 자동 장애 조치가 수행되지 않습니다.

[!참고]

자세한 내용은 쿼럼: 미러링 모니터 서버가 데이터베이스 가용성에 미치는 영향(데이터베이스 미러링)을 참조하십시오.
미러 서버에서 주 서버가 손실된 것을 감지했습니다.

미러 서버에서 주 서버의 오류를 감지하는 방법은 하드 오류인지 또는 소프트 오류인지에 따라 달라집니다. 자세한 내용은 데이터베이스 미러링 중에 발생 가능한 오류를 참조하십시오.

자동 장애 조치 작동 방법

위의 조건 하에서 자동 장애 조치는 다음과 같은 일련의 동작을 시작합니다.

주 서버가 계속 실행되고 있으면 주 데이터베이스의 상태를 DISCONNECTED로 변경하고 주 데이터베이스로부터 모든 클라이언트의 연결을 끊습니다.
미러링 모니터 서버와 미러 서버가 주 서버를 사용할 수 없다고 등록합니다.
Redo Queue에서 대기 중인 로그가 있으면 미러 서버가 미러 데이터베이스의 롤포워드를 마칩니다.

[!참고]

로그를 적용하는 데 필요한 시간은 시스템 속도, 최근 작업 및 Redo Queue에 있는 로그 양에 따라 달라집니다.
이전의 미러 데이터베이스는 새로운 주 데이터베이스로 사용할 수 있도록 온라인 상태로 변경되고 복구 작업은 가능한 빨리 커밋되지 않은 모든 트랜잭션을 롤백하여 정리합니다. 이러한 트랜잭션은 잠금에 의해 격리됩니다.
이전의 주 서버는 세션에 다시 참가할 때 해당 장애 조치 파트너가 이제 주 역할을 소유함을 인식합니다. 이전의 주 서버는 데이터베이스를 미러 데이터베이스로 만들어 미러 역할을 수행하게 됩니다. 새 미러 서버는 가능한 빨리 새 미러 데이터베이스를 주 데이터베이스와 동기화합니다. 새 미러 서버에서 데이터베이스를 다시 동기화하면 장애 조치가 다시 가능해지지만 역방향으로 진행됩니다.

다음 그림에서는 자동 장애 조치의 단일 인스턴스를 보여 줍니다.

자동 장애 조치(Failover)

처음에는 세션에 전체 쿼럼이 있으며 세 서버가 모두 연결되어 있습니다. Partner_A는 주 서버이고 Partner_B는 미러 서버입니다. 먼저 Partner_A(또는 Partner_A의 주 데이터베이스)를 사용할 수 없게 됩니다. 미러링 모니터 서버와 Partner_B에서 주 서버를 더 이상 사용할 수 없다는 것을 인식하고 세션이 쿼럼을 유지합니다. Partner_B가 주 서버가 되고 해당 데이터베이스 복사본을 새로운 주 데이터베이스로 사용할 수 있도록 만듭니다. 마지막으로 Partner_A가 세션에 다시 연결되고 Partner_B가 주 역할을 담당하고 있음을 확인합니다. 그런 다음 Partner_A는 미러 역할을 수행합니다.

[!참고]

Microsoft DTC(Distributed Transaction Coordinator)를 사용하여 트랜잭션을 준비했지만 장애 조치가 발생했을 때 커밋되지 않은 트랜잭션은 데이터베이스에 장애 조치를 취한 다음 중단된 것으로 간주됩니다.

자동 장애 조치(failover)를 해제하려면(SQL Server Management Studio)

데이터베이스 속성 미러링 페이지를 열고 다음 옵션 중 하나를 선택하여 운영 모드를 변경합니다.

자동 장애 조치를 지원하지 않는 보호 우선 모드(동기)

이 모드에서 데이터베이스는 계속 동기화되지만 수동으로 장애 조치를 수행할 수 있습니다.
성능 우선(비동기)

이 모드에서는 미러 데이터베이스가 주 데이터베이스보다 지연될 수 있으며 수동 장애 조치를 수행할 수 없습니다.

자동 장애 조치를 해제하려면(Transact-SQL 사용)

데이터베이스 미러링 세션의 특정 시점에서 데이터베이스 소유자는 미러링 모니터를 해제하여 자동 장애 조치를 해제할 수 있습니다.

미러링 모니터 해제

데이터베이스 미러링 세션에서 미러링 모니터 서버 제거(SQL Server)

[!참고]

전체 트랜잭션 보안은 유지하고 미러링 모니터를 해제하면 세션이 자동 장애 조치를 지원하지 않는 보호 우선 모드가 됩니다.

강제 서비스(데이터 손실 가능)

데이터베이스 미러링은 미러 서버를 웜 대기 서버로 사용할 수 있는 강제 서비스(데이터 손실 가능)를 재해 복구 방법으로 제공합니다. 미러링 세션에서 주 서버가 미러 서버와 연결이 끊긴 경우에만 서비스를 강제 적용할 수 있습니다. 서비스를 강제 적용하면 데이터가 손실될 수 있으므로 반드시 필요한 경우에만 주의해서 사용해야 합니다.

강제 서비스 지원은 세션의 운영 모드와 상태에 따라 다음과 같이 달라집니다.

일반적으로 성능 우선 모드에서는 주 서버의 연결이 끊어질 때마다 강제 서비스 적용을 지원합니다. 그러나 필요한 것은 아니지만 성능 우선 모드 세션에 미러링 모니터 서버가 있을 수 있습니다. 이 경우 서비스를 강제 적용하려면 미리 서버와 미러링 모니터 서버가 서로 연결되어 있어야 합니다.
자동 장애 조치(Failover) 없는 보호 우선 모드에서는 주 서버의 연결이 끊어질 때마다 강제 서비스 적용을 지원합니다.
자동 장애 조치 있는 보호 우선 모드에서는 미러 서버가 마지막으로 주 서버에 연결되었을 때 미러 데이터베이스를 롤백하지 않은 경우 미러 서버와 미러링 모니터 서버가 서로 연결되어 있고 모두 주 서버에 연결되어 있지 않을 때마다 강제 서비스 적용을 지원합니다.

데이터 손실을 감수하더라도 즉시 데이터베이스 서비스를 복원해야 하는 경우에만 서비스를 강제 적용하는 것이 좋습니다. 서비스를 강제 적용할 경우 미러링이 재개될 때 데이터베이스를 다시 동기화하기가 쉽다는 점을 제외하고 미러링을 제거하는 것과 같은 효과가 있으며 데이터가 손실될 수 있습니다. 서비스를 강제 적용하면 주 역할을 미러 데이터베이스로 원활하게 전환하는 작업이 시작됩니다. 미러 서버는 주 서버의 역할을 맡으며 클라이언트에 즉시 데이터베이스 복사본을 제공합니다. 새로운 주 데이터베이스는 미러 없이 노출된 상태로 실행됩니다.

중요
주 서버가 단순히 데이터베이스 미러링 세션과 연결이 끊어졌지만 여전히 실행되고 있으면 일부 클라이언트가 계속해서 원래 주 데이터베이스에 액세스할 수 있습니다. 서비스를 강제 적용하기 전에 클라이언트가 원래 주 서버에 액세스하지 않도록 하는 것이 중요합니다. 그렇지 않으면 서비스가 강제 적용된 후 원래 주 데이터베이스와 현재 주 데이터베이스가 서로 독립적으로 업데이트될 수 있습니다.

주 서버가 단순히 데이터베이스 미러링 세션과 연결이 끊어졌지만 여전히 실행되고 있으면 일부 클라이언트가 계속해서 원래 주 데이터베이스에 액세스할 수 있습니다. 서비스를 강제 적용하기 전에 클라이언트가 원래 주 서버에 액세스하지 않도록 하는 것이 중요합니다. 그렇지 않으면 서비스가 강제 적용된 후 원래 주 데이터베이스와 현재 주 데이터베이스가 서로 독립적으로 업데이트될 수 있습니다.

섹션 내용

강제 서비스의 일반적인 사례
서비스 강제 적용 시의 위험
잠재적 데이터 손실 관리
강제 장애 조치(Failover) 관리를 위한 관련 태스크

강제 서비스의 일반적인 사례

다음 그림에서는 강제 서비스(데이터 손실 가능)의 일반적인 사례를 보여 줍니다.

데이터가 손실될 수 있는 강제 서비스

그림에서 원래 주 서버 Partner_A가 미러 서버 Partner_B에서 사용할 수 없게 되어 미러 데이터베이스의 연결이 끊깁니다. 클라이언트에서 Partner_A를 사용할 수 없는지 확인한 후 데이터베이스 관리자가 Partner_B에 서비스를 강제로 적용하며, 이 경우 데이터가 손실될 수 있습니다. Partner_B가 주 서버가 되고 데이터베이스가 노출된 상태(즉, 미러되지 않은 상태)로 실행됩니다. 이때 클라이언트는 Partner_B에 다시 연결할 수 있습니다.

Partner_A를 사용할 수 있게 되면 새로운 주 서버에 다시 연결하여 세션에 다시 참여하고 미러 역할을 담당합니다. 미러링 세션이 새 미러 데이터베이스를 동기화하지 않고 즉시 일시 중단됩니다. 세션이 일시 중단되면 데이터베이스 관리자가 세션을 재개할지 또는 극단적인 경우 미러링을 제거하고 이전 주 데이터베이스에서 데이터를 복원할지 결정할 수 있습니다. 여기서는 데이터베이스 관리자가 미러링을 재개하도록 선택합니다. 이때 Partner_A는 미러 서버의 역할을 맡고 이전 주 데이터베이스를 성공적으로 동기화된 마지막 트랜잭션 시점까지 롤백합니다. 서비스가 강제 적용되기 전에 미러 서버의 디스크에 기록되지 않은 커밋된 트랜잭션은 손실됩니다. 그런 다음 Partner_A는 이전 미러 서버가 새로운 주 서버가 된 이후의 변경 내용을 새로운 주 데이터베이스에 적용하여 새 미러 데이터베이스를 롤포워드합니다.

[!참고]

성능 우선 모드에서는 미러링 모니터 서버가 필요하지 않지만 미러링 모니터 서버가 구성된 경우 현재 미러 서버에 연결되어 있어야만 서비스를 강제 적용할 수 있습니다.

서비스 강제 적용 시의 위험

서비스를 강제 적용하면 데이터가 손실될 수 있음을 이해하는 것이 중요합니다. 데이터 손실은 미러 서버가 주 서버와 통신할 수 없어 두 데이터베이스의 동기화를 보장할 수 없기 때문에 발생합니다. 서비스를 강제 적용하면 새 복구 분기가 시작됩니다. 원래 주 데이터베이스와 미러 데이터베이스는 서로 다른 복구 분기에 있기 때문에 현재 각 데이터베이스는 다른 데이터베이스에 없는 데이터를 포함합니다. 즉, 원래 주 데이터베이스는 Send Queue에서 이전 미러 데이터베이스로 전송되지 않은 변경 내용(보내지 않은 로그)을 포함하고 이전 미러 데이터베이스는 서비스가 강제 적용된 후 발생한 변경 내용을 포함합니다.

주 서버가 실패하여 서비스가 강제 적용된 경우 발생 가능한 데이터 손실은 실패 전에 미러 서버로 보내지 않은 트랜잭션 로그가 있는지 여부에 따라 달라집니다. 보호 우선 모드에서는 미러 데이터베이스가 동기화될 때까지만 보내지 않은 로그가 있을 수 있습니다. 성능 우선 모드에서는 보내지 않은 로그가 항상 누적되어 있을 수 있습니다.

강제 서비스 적용의 의미는 부분적으로 세션에 미러링 모니터 서버가 있는지 여부에 따라 달라집니다.

미러링 모니터 서버가 없을 경우 네트워크 연결이 끊기는 등의 이유로 파트너의 연결이 끊어지면 서비스를 강제 적용할 수 있습니다. 원래 주 서버가 여전히 실행되고 있으면 두 파트너가 모두 주 역할을 소유합니다. 새로운 주 서버에 연결하는 클라이언트는 현재 버전의 데이터베이스에 액세스하고 원래 주 서버에 연결하는 클라이언트는 원래 주 데이터베이스에 액세스합니다. 이 경우 데이터 손실 가능성이 커집니다. 파트너가 다시 연결할 수 있으면 원래 주 서버는 미러 역할을 맡고 미러링이 일시 중단되기 전에 데이터베이스 상태를 "복구 중"으로 변경합니다. 세션이 재개되면 가장 최근에 연결이 끊어질 때 해당 로그가 Send Queue에 있었던 원래 주 데이터베이스의 트랜잭션이 손실됩니다. 서비스가 강제 적용된 후에 발생한 모든 트랜잭션도 손실됩니다.
미러링 모니터 서버가 있을 경우 미러 서버가 주 서버 및 미러링 모니터 서버와 모두 연결이 끊어지면 주 서버가 노출된 상태로 실행됩니다. 단, 주 서버와 미러링 모니터 서버는 서로 연결되어 있어야 합니다. 그런 다음 주 서버가 미러링 모니터 서버와 연결이 끊어지면 데이터베이스 제공을 중지합니다. 이후에 미러 서버가 미러링 모니터 서버에 다시 연결하면 서비스를 강제 적용할 수 있습니다. 서비스가 강제 적용된 경우 원래 주 서버가 다시 연결하면 원래 주 서버가 노출된 상태로 실행되는 동안 수행된 모든 변경 내용이 손실됩니다.

자세한 내용은 이 항목의 뒷부분에 나오는 잠재적 데이터 손실 관리를 참조하십시오.

잠재적 데이터 손실 관리

서비스가 강제 적용된 후 이전 주 서버를 사용할 수 있게 되면 데이터베이스가 손상되지 않았다고 가정할 경우 잠재적 데이터 손실을 관리할 수 있습니다. 잠재적 데이터 손실을 관리하는 데 사용 가능한 방법은 원래 주 서버가 파트너에 다시 연결하여 미러링 세션에 다시 참여했는지 여부에 따라 달라집니다. 원래 주 서버가 새로운 주 인스턴스에 액세스할 수 있다고 가정하면 자동으로 투명하게 다시 연결할 수 있습니다.

원래 주 서버가 다시 연결된 경우

일반적으로 실패 후에 원래 주 서버가 다시 시작되면 신속하게 해당 파트너에 다시 연결합니다. 다시 연결할 때 원래 주 서버는 미러 서버가 됩니다. 해당 데이터베이스는 미러 데이터베이스가 되고 세션이 일시 중단되기 전에 복구 상태가 됩니다. 미러링을 재개하지 않으면 미러 데이터베이스는 롤백되지 않습니다.

그러나 복구 중인 데이터베이스에 액세스할 수 없으므로 데이터베이스를 검사하여 미러링을 재개할 때 손실될 데이터를 평가할 수 없습니다. 따라서 데이터 손실을 감수할지 여부에 따라 미러링을 재개할지 또는 제거할지 결정합니다.

데이터 손실이 허용되지 않는 경우 미러링을 제거하여 데이터를 복원해야 합니다.

미러링을 제거하면 데이터베이스 관리자가 원래 주 데이터베이스를 복구하여 손실되었을 데이터를 복구할 수 있습니다. 그러나 이전 미러 데이터베이스가 온라인 상태가 되면 이전 파트너가 동일한 이름으로 다른 데이터베이스를 제공합니다. 데이터베이스 관리자는 데이터베이스 중 하나를 클라이언트에서 액세스할 수 없도록 만들어 데이터베이스가 더 이상 달라지지 않도록 하고 클라이언트 장애 조치 문제를 방지해야 합니다.
데이터 손실이 허용되는 경우 미러링을 재개할 수 있습니다.

미러링을 재개하면 데이터베이스 동기화의 첫 번째 단계로 새 미러 데이터베이스가 롤백됩니다. 실패 시 Send Queue에서 대기 중인 로그 레코드가 있으면 커밋된 경우에도 해당 트랜잭션이 손실됩니다.

원래 주 서버가 다시 연결되지 않은 경우

원래 주 서버가 네트워크를 통해 새로운 주 서버에 다시 연결하지 않도록 일시적으로 차단할 수 있는 경우 원래 주 데이터베이스를 검사하여 미러링을 재개하면 손실될 데이터를 평가할 수 있습니다.

잠재적 데이터 손실이 허용되는 경우

원래 주 서버가 해당 파트너에 다시 연결할 수 있도록 합니다. 다시 연결하면 미러링이 일시 중단됩니다. 미러링을 계속하려면 세션을 재개하면 됩니다. 이전 주 서버가 미러 역할을 맡습니다. 새 미러 서버는 원래 복구 분기를 삭제하므로 이전 미러 서버로 보내거나 받지 않은 모든 트랜잭션이 손실됩니다.
데이터 손실이 허용되지 않는 경우

세션을 재개할 때 손실되는 중요한 데이터가 원래 주 데이터베이스에 포함되어 있으면 미러링을 제거하여 원래 주 서버의 데이터를 유지할 수 있습니다. 이때 주 서버의 비상 로그를 백업하는 것이 좋습니다. 그러면 원래 주 데이터베이스에서 유지하려는 데이터를 내보낸 후 현재 주 데이터베이스로 가져와서 현재 주 데이터베이스(이전 미러 데이터베이스)를 업데이트할 수 있습니다. 업데이트된 데이터베이스의 전체 데이터베이스 백업을 가능한 한 빨리 수행하는 것이 좋습니다.

업데이트된 데이터베이스를 초기 주 데이터베이스로 사용하여 미러링을 다시 설정하려면 이 백업과 하나 이상의 후속 로그 백업을 사용하여 새 미러 데이터베이스를 만듭니다. 미러링이 제거된 후에 수행된 모든 로그 백업을 적용해야 합니다. 따라서 새 미러링 세션이 시작될 때까지 주 데이터베이스의 추가 로그 백업을 지연하는 것이 좋습니다.