데이터베이스 미러링 가용성 시나리오

이 절에서는 다음 두 가지 유형의 이벤트를 기반으로 데이터베이스 미러링 시나리오의 예상되는 가용성 결과를 알아 보겠습니다.

• 하나 이상의 서버 또는 데이터베이스가 다운된 경우
• 서버 사이에 하나 이상의 통신 회선이 끊어진 경우

파트너 데이터베이스 중 하나 또는 SQL Server 인스턴스 중 하나를 사용할 수 없게 될 때 서버 손실이 발생할 수 있습니다.
또는 서버 자체는 계속 작동하지만 데이터베이스 미러링 파트너 서버 사이의 통신 회선이 중단될 수 있습니다.

다음 시나리오는 한 구성 요소가 실패하고 이어서 다른 구성 요소가 실패하여 두 구성 요소가 동시에 실패한 것으로 간주됩니다.
예를 들어, 서버 A와 B가 동시에 실패한 것으로 나타나는 경우 미러링 시스템은 이 이벤트를 순서대로 처리합니다. 서버 A에 이어 서버 B 또는 이와 반대로 처리합니다.

다음 규칙을 사용하여 사용 불능 이벤트의 예상 결과를 확인할 수 있습니다.

1. 안전성이 FULL이면 주 서버는 데이터베이스 서비스를 유지하기 위해 최소 하나의 다른 서버에 쿼럼이 필요합니다.

주 서버가 쿼럼을 구성할 수 없는 경우 더 이상 데이터베이스를 서비스할 수 없습니다.

2. 안전성이 FULL일 때 미러나 감시 서버가 주 서버를 볼 수 없는 경우 미러 서버는 감시 서버와 쿼럼을 구성할 수 있고 새로운 주 서버가 되도록 감시 서버와 쿼럼을 구성할 수 있습니다.

이는 자동 장애 조치입니다.

3. 안전성이 FULL이고 감시 서버와 쿼럼을 구성한 상태에서 주 서버가 수행되지만 미러에서는 연결이 끊긴 경우 주 서버 실패는 미러가 감시 서버와 쿼럼을 구성하고 새로운 주 서버의 역할을 맡는 것이 허용되지 않습니다.

이렇게 하면 세션에 의해 작업이 손실되는 것이 방지됩니다.

4. 안전성이 FULL일 때 실패한 주 서버가 다운 또는 격리된 후에 세션에 다시 참가하고 기존의 미러 서버가 감시 서버가 있는 쿼럼에서 이전에 새로운 주 서버의 역할을 맡은 경우 기존의 주 서버는 세션에서 새로운 미러의 역할을 맡게 됩니다.

장애 조치 이벤트 동안 미러와 감시 서버는 미러링 역할 시퀀스 카운터를 증가시켰습니다. 기존의 주 서버 미러링 역할 시퀀스 카운터가 다른 파트너 서버 및 감시 서버의 시퀀스 카운터보다 작기 때문에 이러한 두 서버는 기존의 주 서버가 세션에 다시 참가하기 전에 쿼럼을 구성했고 새로운 주 서버에서 작업이 발생했을 수 있습니다. 기존의 주 서버는 세션에서 미러 역할을 맡습니다.

5. 안정성이 FULL이고 세션에 감시 서버가 없거나, 감시 서버가 세션에서 제거된 경우 쿼럼이 없으면 파트너 서버 실패가 발생 하므로 주 서버는 더 이상 주 데이터베이스 서비스를 유지할 수 없습니다.

쿼럼이 가능하지 않으므로 감시 서버가 안전성 FULL 세션의 일부가 아닐 경우 자동 장애 조치가 발생할 수 없습니다.

서버 손실 시의 고가용성 시나리오

고가용성 작동 모드에서 데이터베이스 미러링의 목적은 가능한 데이터베이스를 사용할 수 있도록 유지하는 것입니다. 이 모드 에서 데이터베이스 미러링은 주 데이터베이스를 사용할 수 없게 될 경우 미러 데이터베이스를 신속하게 서비스하게 됩니다. 다음 시나리오에서는 세 개의 독립 서버가 있는 고가용성 구성으로 시작합니다.

다음 고가용성 시나리오에서 그림 1에서 볼 수 있듯이 서버 A는 주 서버, 서버 B는 미러 서버, 서버 W는 감시 서버로 시작합니다. 실제로 세 개의 모든 서버는 같은 사이트에 있고 로컬 네트워크를 통해 연결되거나 WAN을 통해 연결된 독립 사이트에 있을 수 있습니다. 서버 A와 서버 B는 역할을 변경할 수 있지만 서버 W는 항상 감시 서버를 유지합니다.

이제 서버 중 하나가 다운되는 경우 어떤 일이 발생하는지 생각해 봅시다.

시나리오 HASL1.1: 주 서버 손실

다음 시나리오는 주 서버가 고가용성 시나리오에서 손실될 때 어떤 일이 발생하는지 고려합니다. 그림 2는 다양한 역할 및 파트너 사이에서 어떻게 변하는지 보여줍니다.

주 서버 A가 손실된 후에 미러 서버와 감시 서버가 쿼럼을 구성하고 자동 장애 조치가 발생합니다. 원본 주 서버를 다시 불러 올 수 있는 경우 미러 역할을 맡게 됩니다.

주: 고가용성 모드에서 장애 조치가 발생하도록 하려면 많은 수준에서 실패가 발생할 수 있습니다. 실제 서버가 다운되거나, 주 서버의 SQL Server 인스턴스가 중지 또는 실패하거나, 서버의 주 데이터베이스를 사용하지 못할 수 있습니다. 다음 시나리오에서 주 서버가 손실되면 이러한 이벤트에 의해 발생할 수 있습니다.

서버 B와 W가 쿼럼을 구성할 수 있고 어느 서버도 서버 A를 볼 수 없기 때문에 서버 B가 새로운 주 서버로 자신의 수준을 올릴 수 있습니다. 그러나 미러 서버가 없으면 미러링 세션이 표시된 것으로 간주됩니다.

서버 A가 복원되면 새로운 주 서버가 되고 미러링 세션은 더 이상 표시되지 않습니다.exposed

단일 서버 실패는 거의 발생하지 않는 이벤트일 수 있습니다. 드물게 발생하는 이벤트라도 두 서버가 실패할 수 있습니다. 드문 경우라도 결과를 검사하는 것이 유용합니다.

두 서버가 동시에 또는 거의 동시에 실패할 수 있지만 데이터베이스 미러링 관점에서 결과는 마치 한 서버가 실패하고 이어서 다른 서버가 실패하는 것이 됩니다. 따라서 이러한 시나리오는 서버가 순차적으로 실패할 때만 발생하는 것으로 간주됩니다. 다음 두 시나리오는 주 서버 A 실패가 두 개의 대체 서버 실패에 이어 발생하는 것으로 간주합니다.

• 새로운 주 서버 B의 실패
• 감시 서버 W의 실패

시나리오 HASL1.2: 주 서버 손실에 이어 새로운 주 서버 손실

앞의 시나리오에서 본 것처럼 고가용성 모드에서는 주 서버가 먼저 손실되는 경우 장애 조치가 발생합니다. 그림 3은 새로운 주 서버가 다음에 실패하는 경우 서버 복원에 관계 없이 새로운 주 서버(서버 B)가 주 서버 역할을 유지합니다.

서버 A가 실패한 후에 서버 B가 새로운 주 서버가 되지만 데이??스는 여전히 서비스할 수 있어도 주 서버는 표 서버 B는 다운되기 때문에 미러링이 없습니다.

먼저 서버 A를 복구하는 경우 감시 서버가 새로운 쿼럼을 구성했기 때문에 감시 서버 W에서 mirroring_role_sequence 번호를 감지합니다. 서버 A는 미러의 역할을 맡고 서버 B가 복구되기를 기다립니다. 서버 B가 복구되자 마자 서버 A로 미러링 프로세스를 시작합니다. 먼저 서버 B를 복구하는 경우에는 HASL1.1에 표시된 원래 시나리오로 돌아갑니다.

주: 서버 A가 손실된 다음 서버 B가 손실된 후에 서버 W가 손실된 경우 이러한 서버는 모두 다운되고 서버 A와 서버 B의 전환된 역할은 서버 복원 순서에 관계 없이 유지됩니다.

시나리오 HASL1.3. 주 서버 손실에 이어 감시 서버 손실

주 서버가 손실되면 장애 조치가 발생합니다. 그림 4에서와 같이 감시 서버가 다음에 실패할 수 있습니다.

주 서버 A가 손실된 후에 감시 서버 W가 손실되면 새로운 주 서버 B는 여전히 주 서버이지만 격리되어 있어 쿼럼을 구성할 수 없고 데이터베이스를 서비스랄 수 없습니다.

먼저 서버 A를 복구하는 경우 서버 B의 mirroring_role_sequence 번호는 장애 조치가 발생했기 때문에 서버 A의 번호보다 1이 커집니다. 이는 서버 A가 수행한 후에 서버 B가 이제 주 서버 역할을 가지는 것을 서버 A에 알립니다. 서버 A는 서버 B와 쿼럼 을 구성하고 미러 서버가 되며 두 서버 모두 동기화됩니다. 서버 W가 복구될 때까지 자동 장애 조치는 발생할 수 없습니다.

주: 서버 A가 손실된 다음 서버 W가 손실된 후에 서버 B가 손실된 경우 서버 A와 서버 B의 새로운 역할은 서버 복원 순서에 관계 없이 유지됩니다.

시나리오 HASL2.1 미러 서버 손실

미러 서버가 먼저 손실된 경우 미러 서버로 데이터를 전송할 수 없기 때문에 주 서버가 노출된 것으로 간주됩니다. 그림 5는 미러 서버인 서버 B가 손실될 때의 역할을 보여줍니다.

자동 장애 조치는 발생하지 않으며 파트너는 역할을 교환하지 않습니다. 서버 B가 복원되면 세 서버 모두 원래 역할과 상태로 돌아갑니다.

다음 표는 미러 서버 B의 손실과 복원 동안 데이터베이스 상태와 쿼럼을 보여줍니다.

데이터는 중복 데이터베이스에 저장되지 않기 때문에 미러 서버 없이 세션이 노출됩니다.

서버 B를 복원할 수 있게 되면 미러 역할이 재개되며 두 파트너가 동기화되면 미러링 세션은 더 이상 노출된 것으로 간주되지 않습니다.

다음 두 시나리오는 미러 서버 B 실패에 이어 주 서버 A 또는 감시 서버 W가 실패할 때 발생하는 것으로 간주됩니다.

시나리오 HASL2.2: 미러 서버 손실에 이어 주 서버 손실

미러 서버에 이어 주 서버가 손실되면 파트너 서버의 역할은 변경되지 않습니다. 그림 6은 서버를 복구하는 다양한 경로를 취 할 때 역할이 어떻게 변경되는지를 보여줍니다.

서버 B에 이어 서버 A가 손실되면 상태는 다이어그램 오른쪽 위 모서리에 표시된 상태가 됩니다.

먼저 서버 B를 복구하는 경우 서버 A는 계속 주 서버이고 장애 조치가 발생하지 않는 감시 서버 W에서 발견됩니다 . mirroring_failover_lsn은 증가하지 않습니다. 결과적으로 서버 B는 미러 서버를 유지합니다. 그런 다음 서버 W를 복구하면 세션이 원래 상태로 복원됩니다.

주: 서버 B에 이어 서버 A가 손실된 후에 서버 W가 손실되는 경우 어떤 순서로 서버를 복구하든 결과는 같습니다.

시나리오 HASL2.3: 미러 서버에 이어 감시 서버 손실

미러 서버 손실에 이어 감시 서버가 손실되면 주 서버는 격리되고 다른 서버와 쿼럼을 구성할 수 없습니다. 따라서 그림 7의 오른쪽 위 모서리에서 볼 수 있듯이 데이터베이스를 서비스하지 못하게 됩니다.

미러 서버에 이어 감시 서버가 중단되면 주 서버 A는 주 서버 역할을 유지하지만 다른 서버와 쿼럼을 구성할 수 없고 안전성이 FULL이기 때문에 데이터베이스를 서비스할 수 없고 모든 사용자의 연결이 끊어집니다.

먼저 서버 B가 복원되면 감시 서버 없이는 자동 장애 조치가 가능하지 않지만 미러링은 계속됩니다.
먼저 서버 W가 복원되는 경우 시나리오는 그림 5와 같습니다.

주: 서버 B에 이어 서버 W가 손실된 후에 서버 A가 손실되는 경우 어떤 순서로 서버를 복구하든 최종 결과는 같습니다.

시나리오 HASL3.1: 감시 서버 손실

감시 서버가 실패하면 미러링은 계속되지만 자동 장애 조치는 가능하지 않습니다. 하나 이상의 서버 손실은 쿼럼이 없고 주 데이터베이스가 더 이상 데이터베이스를 서비스할 수 없음을 의미합니다.

서버 W를 복원하면 파트너 서버 A와 서버 B는 원래 역할을 유지합니다.
다음 표는 감시 서버의 실패와 복원 동안 데이터베이스 상태와 쿼럼의 변경을 보여줍니다.
다음 두 시나리오는 감시 서버 W 실패에 이어 주 서버 A 또는 미러 서버 B가 실패할 때 발생하는 것으로 간주됩니다.

시나리오 HASL3.2: 감시 서버 손실에 이어 주 서버 손실

먼저 감시 서버가 실패하면 미러링은 계속되지만 자동 장애 조치는 가능하지 않습니다. 나머지 두 서버 중 하나가 실패하면 쿼럼은 가능하지 않고 나머지 서버는 격리됩니다.

먼저 서버 W를 복구하는 경우 서버 B는 마지막 양호한 주 서버가 서버 A인 감시 서버에서 감지하므로 서버 B는 미러 서버를 유지합니다. 마지막으로 서버 A를 복구하면 주 서버 역할을 유지합니다.

주: 서버 W에 이어 서버 A가 손실된 후에 서버 B가 손실과에3: 감시 서버 손실에 이어 미러 서버 손실

감시 서버가 실패한 다음 미러 서버가 손실되는 경우 주 서버는 격리됩니다. 안전성이 FULL이고 주 서버가 쿼럼을 구성할 수 없는 경우 그림 10가 같이 더 이상 데이터베이스를 서비스할 수 없습니다.

주: 서버 W에 이어 서버 B가 손실된 후에 서버 A가 손실되는 경우 어떤 순서로 서버를 복구하든 최종 결과에는 영향을 주지 않습니다.

요약: 서버 손실 시의 고가용성 시나리오

이러한 시나리오에서 많은 결론을 이끌어낼 수 있습니다. 고가용성 모드에서는:
주 서버를 먼저 사용할 수 없게 되면 자동 장애 조치가 발생하고 이전 미러 서버가 주 서버 역할을 맡게 되고 사용자는 데이터베이스를 사용할 수 있습니다. 이후의 서버 실패와 복원은 새로운 주 서버의 전체 미러링 구성에 영향을 주지 않습니다.
미러링은 역방향으로 계속됩니다.

미러 서버를 먼저 사용할 수 없게 되면 자동 장애 조치는 발생하지 않습니다. 이후의 서버 비가용성과 복원 순서는 미러링 파트너 역할에 영향을 주지 않습니다.

감시 서버를 먼저 사용할 수 없게 되면 자동 장애 조치는 가능하지 않으며 파트너 서버는 원래 역할을 유지합니다. 이후의 서버 비가용성과 복원은 파트너 역할에 영향을 주지 않습니다.

다음 표는 하나 또는 두 서버가 손실되는 고가용성 시나리오에 대한 결과를 요약합니다. 표에서 가정하는 조건은 안전성이 FULL이고 미러링 세션 서버에 다음과 같은 조건이 있습니다.

• A: 주 서버, SYNCHRONIZED
• B: 미러 서버, SYNCHRONIZED
• W: Witness, CONNECTED

표는 장애 조치 시나리오를 회색으로 강조 표시하여 보여줍니다.

표 10. 파트너 서버 역할과 데이터베이스 상태를 보여주는 단일 및 이중 서버 실패 요약

최초 이벤트	쿼럼	결과	중간 상태	두번째 이벤트	쿼럼	결과	최종 상태	첫번째 서버로 돌아감	결과	두번째 서버로 돌아감	최종 상태
A가 손실 (HASL1.1)	B 및 W	장애 조치: B 서버의데이터베이스실행 중,세션이표시됨	A 서버 다운B: 주 서버,DISCONNECTED W: Witness, CONNECTED	B 서버다운(HASL1.2)	없음	실행되는 서버없음	A 서버 다운 B 서버 다운 W: Witness	A 서버로 돌아감	A: 미러 서버,DISCONNECTED B 서버 다운 W: Witness	B 서버로 돌아감	A: 미러 서버, SYNCHRONIZED B: 주 서버, SYNCHRONIZED W: Witness, CONNECTED
				W 서버다운(HASL1.3)	없음	실행되는 서버없음	A 서버 다운 B: 주 서버,DISCONNECTED,실행되지 않음 W 서버 다운	A 서버로 돌아감	A: 미러 서버 B: 주 서버 W 서버 다운	W 서버로 돌아감
B is lost HASL2.1	A 및 W	A 서버의 데이터베이스 실행 중, 세션이 표시됨	A: 주 서버, DISCONNECTED B 서버 다운 W: Witness, CONNECTED	A 서버다운(HASL2.2)	A 및 W	실행되는 서버없음	A 서버 다운 B 서버 다운 W: Witness	B 서버로돌아감	A 서버 다운 B: 미러 서버,DISCONNECTED W: Witness	A 서버로 돌아감	A 서버로 돌아감 A: 주 서버, SYNCHRONIZED B: 미러 서버, SYNCHRONIZED W: Witness, CONNECTED
				W 서버다운(HASL2.3)	없음	실행되는 서버없음	A: 주 서버,DISCONNECTED,실행되지 않음 B 서버 다운 W 서버 다운,DISCONNECTED	B 서버로 돌아감	A: 주 서버,SYNCHRONIZED B: 미러 서버,SYNCHRONIZED W 서버 다운	W 서버로돌아감
W is lost HASL3.1	A 및 B	A 서버의 데이터베이스실행 중, 세션이 표시됨	A: 주 서버,SYNCHRONIZED B: 미러 서버,SYNCHRONIZED W: 서버 다운	A 서버다운(HASL3.2)	없음	실행되는 서버없음	A 서버 다운 B: 미러 서버,DISCONNECTED W 서버 다운, DISCONNECTED	W 서버로 돌아감	A 서버 다운 B: 미러 서버,DISCONNECTED W: Witness	A 서버로 돌아감	A: 주 서버,SYNCHRONIZED B: 미러 서버,SYNCHRONIZED
				B 서버다운(HASL3.3)	없음	실행되는 서버없음	A: 주 서버,DISCONNECTED,실행되지 않음 B 서버 다운 W: 서버 다운,DISCONNECTED	W 서버로 돌아감	A: 주 서버,DISCONNECTED,실행되지 않음 B 서버 다운 W: Witness	B 서버로 돌아감

통신 손실 시의 고가용성 시나리오

고가용성 작동 모드는 세 개의 SQL Sever 인스턴스를 필요로 합니다. 서버가 상당한 거리가 있는 둘 또는 세 개의 독립된 사이트에 있을 경우 사이트 간에 통신 문제가 발생할 가능성이 많습니다. 즉, 서버는 사용 가능하지만 통신 회선이 중단될 수 있습니다. 이러한 시나리오는 이전 설정보다 약간 더 복잡하지만 적용되는 원칙은 동일합니다.

통신이 손실된 다음 고가용성 작동 모드 시나리오는 두 집합으로 설명합니다. 첫 번째 세트는 독립된 사이트에 세 개의 SQL Server 인스턴스가 있으므로 세 개의 독립된 통신 회선을 기준으로 합니다. 두 번째 세트는 두 개의 독립된 사이트에 서버가 있고 서버 쌍과 세 번째 서버 사이에 있는 하나의 통신 회선을 기준으로 합니다.

첫 번째 세? 모든 서버 사이에 세 개의 독립된 통신 회선이 있다고 가정합시다. 예를 들어, 주 서버, 미러 서버 및 감시 서버가 세 개의 독립된 사이트에 있을 수 있습니다. 또한 세 개의 서버가 한 사이트에 있지만 개인 네트워크로 연결되어 있을 수도 있습니다.

초기 조건은 서버 A에 주 데이터베이스가 있고 미러링된 데이터베이스가 있는 파트너로 서버 B와 동기화되었다고 가정합니다. 안전성은 FULL로 설정되고 감시 서버(서버 W)는 데이터베이스 미러링 세션의 일부입니다. 그림 11은 초기 구성을 보여줍니다.

주: 다음 페이지에 있는 다이어그램에 대한 설명은 위의“서버 손실 시 고가용성 모드”를 참조하십시오.

그림 11을 기준으로 보면 A/B, A/W 및 B/W 등 먼저 연결이 끊어질 수 있는 세 개의 다른 회선이 있습니다. 단일 통신 회선이 다운되면 세 개의 서버 모두 계속 작동합니다. 그림 11에서 볼 수 있듯이 주 서버와 미러 서버 사이의 회선만 영향을 받습니다.

표 11. 단일 통신 회선 연결 끊김의 요약

초기 조건	이벤트	쿼럼	결과	조건
주 서버, Synchronizing B: 미러 서버, SYNCHRONIZED W: Witness, CONNECTED	A/B 링크 깨짐	A 및 W	A 서버의 데이터베이스 실행 중, 표시됨	A: 주 서버, DISCONNECTED B: 미러 서버, DISCONNECTED W: Witness, CONNECTED
	A/W	A 및 B	A 서버의 데이터베이스 실행 중	A: 주 서버, SYNCHRONIZED B: 미러 서버, SYNCHRONIZED W: Witness, CONNECTED
	B/W	A 및 B	A 서버의 데이터베이스 실행 중	A: 주 서버, SYNCHRONIZED B: 미러 서버, SYNCHRONIZED W: Witness, CONNECTED

주 서버/미러 서버 연결의 끊김만 영향을 받습니다. 주/감시 서버 또는 미러/감시 서버의 다른 끊김은 데이터베이스 미러링 세션의 동작을 변경시키지 않습니다.

요약하면 표 HACL1의 내용은 다음과 같습니다.

단일 통신 회선의 끊김 중에서도 주/미러 서버 끊김만 데이터베이스 미러링에 영향을 줍니다. 로그 레코드가 미러 서버로 전송되지 않기 때문에 주 서버는 표시된 상태로 실행됩니다.

이제 두 번째 회선이 끊기는 경우 어떤 일이 발생하는지 생각해 봅시다. 두 회선이 동시에 또는 순서대로 끊길 수 있습니다.
두 회선이 동시에 끊기는 경우 한 회선이 끊긴 다음 다른 회선이 끊기므로 최종 결과는 동일합니다. 그러나 정확한 순서는 사전 에 예측할 수 없습니다. 이후의 동작은 동시 끊김이 동일한 순서를 나타냅니다.

따라서 여기서의 목적을 위해 순차적인 회선 끊김만 고려할 것입니다. 표 12는 고가용성 모드에서 통신 회선 끊김의 경우 이 절에서 이름처럼 기본 시나리오를 보여줍니다.

표 12. 두 회선에서 대부분의 통신 회선 끊김은 한 서버가 다운되는 서버 다운 시나리오와 동일해 집니다.

시나리오	첫 번째 회선 끊김	시나리오	두 번째 회선 끊김	결과	나머지 서버에 대해 동일한 시나리오	시나리오 참조
HACL1.1	A/B	HACL1.2	A/W	A 서버 분리됨	A 서버 다운	(없음)
		HACL1.3	B/W	B 서버 분리됨	B 서버 다운	HASL2.1
HACL2.1	A/W	HACL2.1	A/B	A 서버 분리됨	A 서버 다운	HASL1.1
		HACL2.2	B/W	W 서버 분리됨	W 서버 다운	HASL3.1
HACL3.1	B/W	HACL3.1	A/W	W 서버
		HACL3.2	A/B	B 서버 분리됨	B 서버 다운	HASL2.1

중요한 사항은 다음과 같습니다.

두 통신이 끊기는 한 시나리오에서만 장애 조치가 발생합니다. 주/감시 서버 회선 끊김에 이어 주/미러 서버 회선이 끊깁니다.

주/미러 서버 회선이 끊기고 이어서 주/감시 서버 회선이 끊기면 주 서버가 격리되었어도 장애 조치는 발생하지 않고 감시 서버가 이를 볼 수 없습니다.
시나리오 HACL1.2를 보다 신중하게 검토해 보겠습니다.

시나리오 HACL1.2: 주/미러 서버 회선이 끊기고 이어서 주/감시 서버 회선이 끊김

주/미러 서버 링크가 끊어지고 이어서 주 서버와 감시 서버 사이의 링크가 끊어지면 주 서버가 격리됩니다. 다른 서버를 볼 수 없으며 쿼럼이 손실됩니다. 한편 미러 서버와 감시 서버는 주 서버가 여전히 가동되는지 여부를 알지 못하므로 서버 B는 주 서버의 역할을 맡고 자동 장애 조치가 발생합니다. 그림 12는 이러한 이벤트를 보여줍니다.

주/미러 서버 링크가 끊어지고 이어서 주/감시 서버가 끊어지면 서버 A는 격리되고 데이터베이스를 서비스할 수 없습니다.
서버 A가 서버 B에 없는 작업을 수행할 수 있기 때문에 서버 B와 W는 쿼럼을 구성하지 못합니다.

주/감시(A/W) 서버 회선 끊김이 먼저 복구되면 서버 A는 DISCONNECTED 상태에서 주 서버 역할을 계속합니다. 그러나 주 서버와 미러 서버 사이의 회선은 아직 복구되지 않았기 때문에 미러링은 발생하지 않습니다.

주/미러(A/B) 서버 회선 끊김이 먼저 복구되면 감시 서버가 없어도 서버 A는 서버 B에 대한 미러링을 계속하므로 세션이 표시 됩니다. 그러나 주/감시 서버 회선이 마지막으로 복구될 때까지 자동 장애 조치는 가능하지 않습니다.

요약: 서버 손실 시의 고가용성 시나리오: 세 개의 사이트

다음 표는 세 개의 독립된 서버가 있는 하나 및 두 회선 끊김의 동작을 요약합니다. 표의 초기 조건은 안전성 수준이 FULL이고 서버는 다음과 같은 상태에 있습니다.

A: 주 서버, SYNCHRONIZED
B: 미러 서버, SYNCHRONIZED
W: Witness, CONNECTED

장애 조치 시나리오 경로는 회색으로 강조 표시됩니다.

표 13. 고가용성 모드에서 안전성이 FULL이고 세 개의 독립된 서버의 경우 한 회선 및 두 회선 끊김의 요약

최초 이벤트	쿼럼	결과	중간 상태	두번째 이벤트	쿼럼	결과	최종 상태	복구된 회선	첫 번째 복구 상태
A/B 링크깨짐(HACL1.1)	A 및 W	A 서버의 데이터베이스실행 중, 표시됨	A: 주 서버, DISCONNECTED B: 미러 서버, DISCONNECTED W: Witness	A/W 링크끊김(HACL1.2)	B 및 W	실행되는 서버 없음 A 분리됨	A: 주 서버, DISCONNECTED, db를서비스할 수 없음 B: 미러 서버, DISCONNECTED W: Witness	A/B	A: 주 서버, SYNCHRONIZED B: 미러 서버, SYNCHRONIZED W: Witness
				B/W 링크끊김(HACL1.3)	A 및 W	A 서버의 데이터베이스실행 중, 표시됨 B 격리됨	A: 주 서버, DISCONNECTED B: 미러 서버, DISCONNECTED W: Witness	A/B
A/W 링크끊김(HACL2.1)	A 및 B	A 서버의 데이터베이스실행 중	A: 주 서버, SYNCHRONIZED B: 미러 서버, SYNCHRONIZE W: Witness	A/B 링크깨짐(HACL2.2)	B 및 W	B 서버의 데이터베이스실행 중 표시됨	A 서버는 실행되지 않음 B: 주 서버,DISCONNECTED W: Witness	A/W	A: 미러 서버, DISCONNECTED B: 주 서버, DISCONNECTED W: Witness
				B/W 링크끊김(HACL2.3)	A 및 B	A 서버의 데이터베이스실행 중	A: 주 서버, SYNCHRONIZED B: 미러 서버, SYNCHRONIZED W: 감시 서버, 분리됨, DISCONNECTED	A/W
B/W 링크끊김(HACL3.1	A 및 B	A 서버의 데이터베이스실행 중, 표시됨	A: 주 서버,SYNCHRONIZED B: 미러 서버,SYNCHRONIZED W: Witness	A/W 링크깨짐	A 및 B	A 서버의 데이터베이스실행 중	A: 주 서버, SYNCHRONIZED B: 미러 서버, SYNCHRONIZED W: 감시 서버, 분리됨, DISCONNECTED	B/W	A: 주 서버, SYNCHRONIZED B: 미러 서버, SYNCHRONIZED W: Witness
				A/B 링크깨짐	A 및 W	A 서버의 데이터베이스실행 중, 표시됨	A: 주 서버, DISCONNECTED B: 미러 서버, DISCONNECTED, 분리됨 W: Witness	B/W

시나리오 HACL4: 미러 사이트에 감시 서버가 회선이 하나만 있으면 감시 서버를 배치할 곳을 선택해야 합니다. 먼저 미러 데이터베이스 서버에 감시 서버를 배치한다고 가정합??선이 하나만 있고 이 회선이 중단될 수 있습니다.

서버 A는 감시 서버 W 또는 미러 데이터베이스의 서버 B를 볼 수 없으므로 쿼럼을 구성할 수 없습니다. 서버 B와 서버 W는 쿼럼을 구성할 수 있지만 서버 A에서 주 서버를 볼 수 없습니다. 회선 끊김의 결과는 그림 14와 같습니다.

서버 A는 감시 서버 W 또는 이전 미러 파트너 서버 B를 볼 수 없기 때문에 연결이 끊긴 상태가 되어야 하며 데이터베이스를 사용할 수 없게 됩니다.

서버 B와 서버 W는 쿼럼을 구성할 수 있습니다. 서버 B가 서버 A를 볼 수 없고 서버 W와 서버 B가 주 서버가 되고 데이터베이 스가 온라인이 되려고 시도합니다. 서버 W는 서버 A를 볼 수 없기 때문에 서버 B와 동의합니다. 서버 B에는 이제 쿼럼이 있고 이 세션에서 주 서버 역할을 맡고 데이터베이스를 복구합니다.

통신 회선을 복원하는 경 감시 서버 W가 서버 B를 주 서버로 보는 것을 발견 합니다. 서버 A는 미러 서버의 역할로 역할을 변경하고 새로운 주 서버와 동기화를 시도합니다. 완료되면 결과의 구성은 그림 15와 같아집니다.

요약: 감시 서버가 미러 서버와 함께 원격 사이트에 존재하는 경우 사이트 간의 통신 회선이 중단되면 자동 페일오버가 발생합 니다.

시나리오 HACL5: 주 사이트에 감시 서버가 있는 두 사이트

이 고가용성 시나리오에서는 그림 16과 같이 감시 서버를 주 데이터베이스 서버와 같은 사이트에 배치하고 두 사이트 사이의 통신이 중단된다고 가정합니다.

이 경우 미러 데이터베이스가 있는 서버 B는 주 서버와 감시 서버로부터 분리됩니다. 서버 A와 서버 W는 쿼럼을 계속 구성하 므로 서버 A는 데이터베이스를 주 서버를 유지합니다. 그러나 서버 A는 서버 B를 볼 수 없고 데이터를 전송할 수 없기 때문에 데이터베이스는 연결이 끊긴 상태가 됩니다. 서버 B는 서버 A를 볼 수 없으므로 역시 연결이 끊어진 상태가 됩니다. 결과의 구성은 그림 17과 같습니다.

서버 A는 트랜잭션을 계속 받지만 트랜잭션 로그를 잘라낼 수는 없습니다. 회선을 신속하게 복원하는 경우 미러링 세션을 다시 동기화하고 원래 작동 상태로 돌아갈 수 있습니다.

요약: 주 서버와 같은 사이트에 감시 서버가 있고 원격 사이트에 미러 서버가 있으면 사이트 사이의 통신 중단은 자동 장애 조치를 일으키지 않습니다.

요약: 통신 링크가 끊긴 상태의 고가용성 시나리오

세 개의 독립된 서버가 있는 고가용성 구성에서 세 개의 독립 통신 회선이 있습니다.

• 주/미러 서버 통신 손실이 발생하면 자동 장애 조치가 발생하지 않습니다.
• 주/감시 서버 통신 손실이 먼저 발생하고 이어서 주/미러 서버 통신이 끊어지면 자동 장애 조치가 발생합니다. 회선을 복원하면 미러링의 역방향을 유지합니다.
• 미러/감시 서버 통신 손실이 발생하면 자동 장애 조치가 발생하지 않습니다.

한 통신 회선만 있는 고가용성 구성에서는 감시 서버는 주 서버 또는 미러 서버에 있습니다.

• 감시 서버가 미러 서버와 함께 원격 사이트에 존재하는 경우 사이트 간의 통신 회선이 중단되면 자동 페일오버가 발생합니다.
• 주 서버와 같은 사이트에 감시 서버가 있고 원격 사이트에 미러 서버가 있으면 사이트 사이의 통신 중단은 자동 장애 조치를 일으키지 않습니다.

높은 수준의 보호 시나리오

높은 수준의 보호 작동 모드는 안전성이 FULL에서 작동하지만 감시 서버는 없습니다. 주 데이터베이스가 있는 서버와 미러 데이터베이스가 있는 서버만 관련되기 때문에 통신 회선이 하나만 있습니다. 이는 시나리오 수를 획기적으로 줄입니다.

사례 1. 높은 수준의 작동 모드에서 주 서버와 미러 서버 등 두 SQL Server 인스턴스만 관련됩니다. 감시 서버는 없기 때문에 자동 장애 조치는 가능하지 않습니다. 서버 사이에 통신 회선이 하나만 있고 중단될 수 있어 그림 18과 같은 구성이 가능합니다.

안전성이 FULL이고 주 서버가 미러 서버와 더 이상 쿼럼을 구성할 수 없기 때문에 주 서버는 데이터베이스 연결을 끊어야 하며 사용자 작업에 사용할 수 없습니다.

사례 2. 높은 수준의 보호 시나리오에서 미러 데이터베이스를 사용할 수 없게 되면 주 서버는 그림 19에서 볼 수 있듯이 시나리오에서 동일합니다.

사례 3. 높은 수준의 보호 시나리오에서 주 데이터베이스를 사용할 수 없는 경우 미러 데이터베이스는 미러 서버에 유지되어야 하지만 그림 20에서 볼 수 있듯이 연결이 끊긴 상태에 있게 됩니다.

높은 수준의 보호 작동 모드는 안정성이 FULL이기 때문에 중단되면 주 데이터베이스를 사용할 수 없게 되고 미러 데이터베이스는 복구 중 상태에 유지됩니다. 데이터베이스는 온라사항에는 좋은 솔루션이 아닙니다. 짧은 기간 동안 감시 서버를 제거해야 할 때 같이 임시 상태로 훨씬 적합합니다.

고가용성 시나리오

고가??니다. 감시 서버에서는 역할이 재생되지 않습니다. 주 데이터베이스가 있는 서버와 미러 데이터베이스가 있는 서버만 관련되기 때문에 통신 회선이 하나만 있습니다. 높은 수준의 보호와 유사함에도 불구하고 고성능은 안전성이 OFF이기 때문에 동작이 다릅니다.

사례 1. 고성능 작동 모드에서 두 SQL Server 인스턴스가 관련이 됩니다. 하나에는 주 데이터베이스가 있고 다른 하나에는 미러 데이터베이스가 포함되어 있습니다. 따라서 서버 사이에 통신 회선이 하나만 있고 중단될 수 있어 그림 21과 같은 구성이 가능합니다.

트랜잭션 안전성이 OFF이기 때문에 서버 A에는 데이터베이스의 가용성을 유지하기 위해 쿼럼이 요구되지 않습니다. 따라서 연결은 끊어졌지만 주 서버는 사용자 작업을 계속 받아들입니다. 통신을 복원하면 미러 데이터베이스는 추적을 시도하지만 하지 못하거나, 누락된 모든 트랜잭션을 검색할 수 없는 경우 재실행 오류가 발생할 수도 있습니다.

사례 2. 고성능 시나리오에서 미러 데이는 그림 22와 같습니다.
안전성이 OFF이므로 주 데이터베이스는 계속 사용할 수 있습니다.

사례 3. 높은 수준의 보호 시나?? 미러 데이터베이스는 미러를 유지하지만 그림23에서 볼 수 있듯이 연결은 끊어집니다.

고성능 작동 모드에서는 높은 수준의 보호 모드에서처럼 자동 장애 조치가 가능하지 않습니다. 안전성이 OFF이기 때문에 미러를 사용할 수 없게 되면 주 서버는 데이터베이스를 사용할 수 있도록 유지합니다. 또한 안전성이 OFF이므로 트랜잭션이 미러에 도달하는 것이 보장되지 않습니다. 미러에 강제로 장애 조치하는 경우 일부 트랜잭션은 손실될 수 있습니다.