장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹)

적용 대상:SQL Server

AG(가용성 그룹)의 컨텍스트 내에서는 일반적으로 가용성 복제본의 주 역할과 보조 역할을 장애 조치(failover)로 알려져 있는 프로세스에서 서로 교환할 수 있습니다. 자동 장애 조치(데이터가 손실되지 않음), 계획된 수동 장애 조치(데이터가 손실되지 않음)와 강제 장애 조치(failover)라고 불리는 강제 수동 장애 조치(데이터가 손실될 수 있음)의 세 가지 형태가 있습니다. 자동 및 계획된 수동 장애 조치(failover)는 모든 데이터를 보존합니다. 가용성 그룹은 가용성 복제본 수준에서 장애 조치(Failover)를 합니다. 즉, 가용성 그룹은 해당 보조 복제본(replica)(현재 장애 조치 대상)중 하나에 장애 조치(failover)를 합니다.

장애 조치(failover)를 하는 동안에는 대상이 주 역할을 맡아서 각 데이터베이스의 복사본을 복구하고 이를 새로운 주 데이터베이스로 하여 온라인 상태로 만듭니다. 이전의 주 복제본을 사용 가능성이 있을 때 보조 역할로 전환되며 해당 데이터베이스는 보조 데이터베이스가 됩니다. 잠재적으로 이러한 역할은 다중성 장애에 대응하거나 관리 목적으로 전환 (다른 장애 조치를 대상으로) 될 수 있습니다.

지정된 가용성 복제본(replica)이 지원하는 장애 조치(failover)의 형식은 장애 조치(failover) 모드 속성에 의해 지정됩니다. 지정된 가용성 복제본(replica) 경우 가능한 장애 조치 모드는 복제본(replica) 가용성 모드에 따라 달라집니다:

• 동기-커밋 복제본은 두 개의 설정 (자동 또는 수동)을 지원합니다. "자동" 설정은 자동 장애 조치(failover) 및 수동 장애 조치(failover)를 모두 지원합니다. 데이터 손실을 방지하기 위해서 자동 장애 조치(failover) 및 계획된 장애 조치를 실행하려면 장애 조치(failover) 대상이 정상 동기화 상태의 동기-커밋 보조 복제본(replica)이어야 합니다(장애 조치 대상의 모든 보조 데이터베이스가 해당 주 데이터베이스와 동기화된 상태). 보조 복제본이 이러한 조건을 모두 충족하지 않을 때는 항상 강제 장애 조치(Failover)만 지원됩니다. 강제 장애 조치(Failover)는 또한 역할이 RESOLVING 상태인 복제본을 지원합니다.

• 비동기-커밋 복제본(replica)은 수동 장애 조치(failover) 모드만 지원합니다. 또한, 동기화가 절대로 되지 않기 때문에 강제 장애 조치(failover)만 지원합니다.

이 항목의 섹션:

• 용어 및 정의

• 장애 조치(Failover) 개요

• 자동 장애 조치(Failover)

• 계획된 수동 장애 조치(Failover)(데이터가 손실되지 않음)

• 강제 장애 조치(failover)(데이터가 손실될 수 있음)

• 관련 작업

• 관련 내용

용어 및 정의

자동 장애 조치(Failover)
주 복제본이 손실되는 경우 자동으로 발생하는 장애애 조치(failover)입니다. 자동 장애 조치(Failover)는 현재 주 복제본과 하나의 보조 복제본이 모두 AUTOMATIC으로 설정된 장애 조치(Failover) 모드로 구성되고 보조 복제본이 현재 동기화된 경우에만 지원됩니다. 주 또는 보조 복제본(replica)의 장애 조치(failover)모드가 수동이면 자동 장애 조치(failover)는 실행될 수 없습니다.

계획된 수동 장애 조치(Failover)(데이터가 손실되지 않음)
계획된 수동 장애 조치(failover) 또는 수동 장애 조치(failover)는 일반적으로 데이터베이스 관리자가 관리를 목적으로 초기화를 하는 장애 조치(failover)입니다. 계획된 수동 장애 조치(Failover)는 주 복제본과 보조 복제본이 동기-커밋 모드에 대해 구성되고 주 복제본과 보조 복제본이 현재 동기화된(SYNCHRONIZED 상태) 경우에만 지원됩니다. 대상 보조 복제본(replica)이 동기화가 되었을 때 보조 데이터베이스가 장애 조치(failover)를 취할 준비가 되었기 때문에 주 복제본(replica) 이 중단된 경우 데이터 손실 없이도 수동 장애 조치(failover)가 가능합니다. 데이터베이스 관리자는 수동 장애 조치(failover)를 수동으로 초기화를 합니다.

강제 장애 조치(failover)(데이터가 손실될 수 있음)
보조 복제본(replica)이 주 복제본(replica) 동기화가 안 되었거나 주 복제본(replica) 실행되지 않아서 보조 복제본(replica) 장애 조치(failover)가 준비가 안 되었을 때 데이터베이스 관리자가 초기화할 수 있는 장애 조치(failover)입니다. 강제 장애 조치(Failover)는 데이터가 손실될 수 있는 위험이 있으며 재해 복구용으로만 사용하는 것이 좋습니다. 강제 장애 조치(failover)는 수동으로만 시작될 수 있기 때문에 강제 수동 장애 조치(failover)라고도 합니다. 이 장애 조치(failoveR)는 비동기 커밋 가용성 모드에서 지원되는 유일한 장애 조치(failover)의 형태입니다.

자동 장애 조치(Failover) 설정

지정된 가용성 그룹 내에서 자동 장애 조치(Failover)를 사용하는동기-커밋 모드(있는 경우)에 관해 구성된 가용성 복제본의 쌍(현재 주 복제본 포함)입니다. 자동 장애 조치(Failover) 설정은 보조 복제본이 주 복제본과 현재 동기화된 경우에만 효과적인 것 입니다.

동기 커밋 장애 조치(Failover) 설정

지정된 가용성 그룹 내에서 동기-커밋 모드(있는 경우)로 구성된 2~3개의 가용성 복제본(현재 주 복제본 포함)의 집합입니다. 보조 복제본이 수동 장애 조치(Failover) 모드로 구성되고 하나 이상의 보조 복제본이 주 복제본과 현재 동기화된 경우에만 효과적인 것입니다.

전체 장애 조치(Failover) 설정

지정된 가용성 그룹 내에서 가용성 모드 및 장애 조치(failover) 모드와는 관계없이 작동 상태가 현재 온라인인 모든 가용성 복제본 집합입니다. 전체 장애 조치(Failover) 설정은 주 복제본과 SYNCHRONIZED된 보조 복제본이 없을 때 관련이 있습니다.

장애 조치(Failover) 개요

다음 표에는 여러 가지 가용성 및 장애 조치(failover) 모드에서 지원되는 장애 조치(failover)의 형태가 요약되어 있습니다. 각 쌍에 대해 유효한 가용성 모드 및 장애 조치(Failover) 모드는 주 복제본 모드와 하나 이상의 보조 복제본 모드의교차로 결정됩니다.

*****동기화된 보조 복제본에 강제 장애 조치(Failover) 명령을 실행하면 보조 복제본은 수동 장애 조치(Failover)의 경우와 동일하게 작동합니다.

장애 조치(failover)를 하는 동안 데이터베이스를 사용할 수 없는 시간의 양은 장애 조치(failover) 유형과 그 원인에 따라 달라집니다.

장애 조치(Failover) 집합

지정된 가용성 그룹에 대해 가능한 장애 조치(Failover)의 형태는 장애 조치(Failover) 설정의 관점에서 이해할 수 있습니다. 장애 조치(failover) 설정은 다음과 같이 지정된 형태의 장애 조치(failover)를 지원하는 기본 복제본(replica) 및 보조 복제본(replica)으로 구성됩니다:

• 자동 장애 조치(failover) 집합(선택 사항): 지정된 가용성 그룹 내에서 자동 장애 조치(failover)를 사용하는 동기-커밋 모드(있는 경우)에 대해 구성된 가용성 복제본의 쌍(현재 주 복제본 포함)입니다. 자동 장애 조치(failover)는 보조 복제본이 주 복제본과 현재 동기화된 경우에만 작동됩니다.

• 동기 커밋 장애 조치(failover) 집합(선택 사항): 지정된 가용성 그룹 내에서 동기-커밋 모드(있는 경우)로 구성된 2개 또는 3개의 가용성 복제본(현재 주 복제본 포함) 세트입니다. 동기-커밋 장애 모드 설정은 보조 복제본이 수동 장애 조치(Failover) 모드로 구성되고 하나 이상의 보조 복제본이 주 복제본과 현재 동기화된 경우에만 작동합니다.

• 전체 장애 조치(failover) 집합: 지정된 가용성 그룹 내에서 가용성 모드 및 장애 조치(failover) 모드와 상관없이 작업 상태가 현재 ONLINE인 모든 가용성 복제본 집합입니다. 현재 주 복제본(replica)과 동기화된 보조 복제본(replica)이 없는 경우 전체 장애 조치(failover) 설정이 관련이 있습니다.

자동 장애 조치(Failover)를 사용하는 동기 커밋으로 가용성 복제본을 구성할 때 가용성 복제본은 자동 장애 조치(Failover) 설정의 일부가 됩니다. 하지만 이 설정이 적용되는지의 여부는 현재 주 복제본에 따라 달라집니다. 지정된 시간에 실제로 가능한 장애 조치(Failover) 형태는 현재 적용되는 장애 조치(Failover) 집합에 따라 다릅니다.

예를 들어, 다음과 같은 네 개의 가용성 복제본이 있는 가용성 그룹을 고려합니다:

각 보조 복제본(replica) 대한 장애 조치(failover) 동작은 어떤 가용성 복제본이 현재 주 복제본(replica)인지 가용성 복제본(replica)인지에 따라 달라집니다. 근본적으로 지정된 보조 복제본(replica) 대한 장애 조치(failover) 동작은 현재 주 복제본(replica)에게 주어진 최악의 경우입니다. 다음 그림에서는 현재 주 복제본에 따라 보조 복제본의 장애 조치(Failover) 동작이 어떻게 달라지는지와 보조 복제본의 장애 조치(Failover) 동작이 강제 장애 조치(Failover)만 사용하는 비동기-커밋 모드용으로 구성되었는지 자동 장애 조치(Failover)를 사용하거나 사용하지 않는 동기-커밋 모드용으로 구성되었는지를 보여주고 있습니다.

자동 장애 조치(Failover)

자동 장애 조치(failover)를 실행하면 주 복제본(replica) 사용할 수 없게 된 후에 지정된 보조 복제본(replica)이 기본 역할로 자동으로 전환됩니다. 자동 장애 조치(failover)는 주 복제본(replica)을 호스팅하는 WSFC 노드가 보조 복제본(replica을) 호스팅하는 노드에 관해 로컬인 경우에 가장 적합합니다. 이는 데이터 동기화가 컴퓨터 사이에서의 메시지 대기 시간이 짧은 경우 데이터 동기기화가 가장 잘 작동하며 클라이언트 연결이 로컬로 다시 유지될 수 있기 때문입니다.

섹션 내용:

• 자동 장애 조치(Failover)에 필요한 조건

• 자동 장애 조치(Failover) 작동 방법

• 자동 장애 조치(Failover)를 사용를 사용하려면

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

자동 장애 조치(Failover)에는 다음의 상태에서만 실행이 됩니다:

• 자동 장애 조치(failover) 설정이 있습니다. 이 설정은 동기 커밋 모드로 구성되고 자동 장애 조치(failover)로 설정된 주 복제본(replica) 과 보조 복제본(replica)(자동 장애 조치(Failover)대상)으로 구성됩니다. 주 복제본(replica)이 수동 장애 조치(failover)로 설정된 경우 보조 복제본(replica) 자동 장애 조치(failover)로 설정된 경우라도 자동 장애 조치(failover)는 실행될 수 없습니다.

  자세한 내용은 가용성 모드(Always On 가용성 그룹)를 참조하세요.

• 자동 장애 조치(Failover) 대상의 동기화 상태는 정상 상태, 즉 장애 조치(Failover) 대상의 모든 보조 데이터베이스가 해당 주 데이터베이스와 동기화되는 상태입니다.

  팁

  Always On 가용성 그룹은 자동 장애 조치(Failover) 설정에서 두 복제본의 상태를 모니터링합니다. 복제본 중 하나가 실패하면 가용성 그룹의 상태는 CRITICAL로 설정됩니다. 보조 복제본(replica) 실패하는 경우 자동 장애 조치(failover) 대상을 사용할 수 없기 때문에 자동 장애 조치(failover)를 실행할 수 없습니다. 주 복제본(replica) 실패하는 경우 가용성 그룹은 보조 복제본(replica)으로 장애 조치(failover)가 됩니다. 이전의 주 복제본(replica)이 온라인 상태가 될 때까지 자동 장애 조치(failover)는 대상은 없습니다. 어떠한 경우에도 순차적인 오류가 발생할 가능성이 희박한 경우 사용 가능성을 보장하기 위해서는 다른 보조 복제본(replica)을 자동 장애 조치(failover) 대상으로 구성하는 것을 권장합니다.

  자세한 내용은 Always On 정책을 사용하여 가용성 그룹의 상태 보기(SQL Server) 및 가용성 복제본의 장애 조치(failover) 모드 변경(SQL Server)을 참조하세요.

• WSFC(Windows Server 장애 조치(Failover) 클러스터링) 클러스터에는 쿼럼이 있습니다. 자세한 내용은 WSFC 쿼럼 모드 및 응답 구성(SQL Server)을 참조하세요.

• 주 복제본(replica)을 사용할 수 없게 되었으며 유연성 있는 장애 조치(failover) 정책에 의해 정의된 장애 조치(failover) 조건 수준을 충족되었습니다. 장애 조치(failover) 상태 수준에 대한 자세한 내용은 가용성 그룹 자동 장애 조치에 대한 유연한 장애 조치(Failover) 정책(SQL Server)을 참조하세요.

자동 장애 조치 작동 방법

자동 장애 조치는 다음과 같은 일련의 동작을 시작합니다:

1. 현재 주 복제본(replica)을 호스팅하는 서버 인스턴스가 여전히 실행 중인 경우 주 데이터베이스의 상태를 DISCONNECTED로 변경하고 모든 클라이언트의 연결을 끊습니다.

2. 로그 레코드가 대상 보조 복제본의 Recovery Queue에서 대기 중인 경우 보조 복제본이 나머지 로그 레코드에 적용되어 보조 데이터베이스의 롤포워드를 마칩니다.

   참고 항목

   지정된 데이터베이스에 로그를 적용하는 데 필요한 시간은 시스템 속도, 최근 작업 로드 및 Recovery Queue에 있는 로그 양에 따라 달라집니다.

3. 이전 보조 복제본이 주 역할로 전환됩니다. 해당 데이터베이스는 주 데이터베이스가 됩니다. 새 주 복제본(replica)은 커밋되지 않은 트랜잭션(복구 실행 취소 단계)을 가능한 한 신속하게 롤백합니다. 잠금은 커밋되지 않은 트랜잭션을 격리하여 클라이언트가 데이터베이스를 사용하는 동안 백그라운드에서 롤백이 실행할 수 있게 합니다. 이 프로세스는 커밋된 트랜잭션이 롤백하지 않습니다.

   지정된 보조 데이터베이스가 연결될 때까지 잠시 NOT_SYNCHRONIZED가 표시됩니다. 롤백 복구가 시작되기 전에 보조 데이터베이스는 새로운 주 데이터베이스에 연결하여 SYNCHRONIZED 상태로 빨리 전환될 수 있습니다. 일반적으로 장애 조치(failover)를 한 이후에 보조 역할에 유지되는 세 번째 동기 커밋 복제본(replica)의 경우가 가장 좋습니다.

4. 나중에 이전의 주 복제본(replica) 호스팅하는 서버 인스턴스가 다시 시작될 때 다른 가용성 복제본(replica)이 이제 주 역할을 소유하고 있다는 것을 인식합니다. 이전 주 복제본은 보조 역할로 전환되고 해당 데이터베이스는 보조 데이터베이스가 됩니다. 새로운 보조 복제본은 현재 주 복제본에 연결하고 최대한 빠르게 해당 데이터베이스를 현재 주 데이터베이스와 동기화합니다. 새로운 보조 복제본은 해당 데이터베이스를 다시 동기화하면 바로 장애 조치(Failover)를 반대 방향으로 다시 실행할 수 있습니다.

자동 장애 조치(failover) 구성하려면

언제든지 가용성 복제본(replica)은 자동 장애 조치(failover)를 지원하도록 구성할 수 있습니다.

자동 장애 조치(failover)를 구성하려면

1. 보조 복제본(replica) 동기 커밋 가용성 모드를 사용하기 위해서 구성되어 있는지 확인합니다. 자세한 내용은 가용성 복제본의 가용성 모드 변경(SQL Server)을 참조하세요.

2. 장애 조치(failover) 모드를 자동으로 설정합니다. 자세한 내용은 가용성 복제본의 장애 조치(failover) 모드 변경(SQL Server)을 참조하세요.

3. 필요에 따라 가용성 그룹의 유연한 장애 조치(Failover) 정책을 변경하여 자동 장애 조치(Failover)를 발생시킬 수 있는 오류의 유형을 지정할 수 있습니다. 자세한 내용은 유연한 장애 조치(failover) 정책을 구성하여 자동 장애 조치(failover)의 상태 제어(Always On 가용성 그룹) 및 장애 조치(failover) 클러스터 인스턴스용 장애 조치(failover) 정책을 참조하세요.

계획된 수동 장애 조치(Failover)(데이터가 손실 없음)

수동 장애 조치(Failover)를 실행하면 대상 보조 복제본을 호스팅하는 서버 인스턴스에서 데이터베이스 관리자가 수동 장애 조치(Failover) 명령을 실행한 이후에 동기화된 보조 복제본이 주 역할로 전환됩니다. 수동 장애 조치(Failover)를 지원하려면 현재의 주 복제본을 동기-커밋 모드(있는 경우)로 구성되어야 합니다. 가용성 복제본(replica)은 모든 보조 데이터베이스를 가용성 그룹에 조인해야 하며 해당 주 데이터베이스(즉, 보조 복제본(replica)이 동기화해야 합니다)와 동기화를 해야 합니다. 이렇게 되면 이전의 주 데이터베이스에서 커밋된 모든 트랜잭션이 해당 보조 데이터베이스에서도 커밋이 되어있음을 보장합니다. 따라서 새로운 주 데이터베이스는 이전의 주 데이터베이스와 똑같습니다.

다음 그림에서는 계획된 장애조치(Failover)의 단계를 보여 줍니다:

1. 장애 조치(failover)를 하기 이전에 서버 인스턴스가 주 복제본을 호스팅합니다 Node01.

2. 데이터베이스 관리자가 계획된 장애조치(Failover)를 시작합니다. 장애 조치 대상은 서버 인스턴스에서 호스팅하는 가용성 복제본(replica)입니다Node02.

3. 장애 조치 대상(켜Node02짐)의 대상은 새로운 주 복제본(replica)이 됩니다. 계획된 장애 조치(Failover)이기 때문에 이전의 주 복제본은 장애 조치(Failover) 중에 보조 역할로 전환되고 해당 데이터베이스는 보조 데이터베이스로서 즉시 온라인 상태가 됩니다.

섹션 내용:

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

• 수동 장애 조치 작동 방법

• 업그레이드를 하는 동안 가용성 유지 관리

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

수동 장애 조치(Failover)를 지원하려면 현재 주 복제본을 동기-커밋 모드로 설정해야 하며 보조 복제본은 다음과 같아야 합니다:

• 동기-커밋 모드로 구성되었습니다.

• 주 복제본과 현재 동기화되어 있어야 합니다.

가용성 그룹을 수동으로 장애 조치(failover)하기위해 새로운 주 복제본(replica)이 될 보조 복제본(replica)에 연결해야 합니다.

계획된 수동 장애 조치(failover)의 작동 방법

대상 보조 복제본(replica)에서 시작되어야 하는 계획된 수동 장애 조치(failover)는 다음 일련의 동작을 시작합니다:

1. 원래 주 데이터베이스에서 새로운 사용자 트랜잭션이 실행되는 것을 확인하기 해서 WSFC 클러스터는 오프라인으로 전환하려는 요청을 복제본(replica)에 전송합니다.

2. 보조 데이터베이스의 복구 큐에서 로그가 대기 중인 경우 보조 복제본(replica)은 해당 보조 데이터베이스의 롤 포워드를 완료합니다. 소요 시간은 시스템 속도, 최근 작업 및 Recovery Queue에 있는 로그 양에 따라 달라집니다. 복구 큐의 현재 크기를 알아보려면 복구 큐 성능 카운터를 사용합니다. 자세한 정보는 SQL Server, 데이터베이스 복제본을 참조해 주세요.

   참고 항목

   장애 조치(failover) 시간은 복구 큐의 크기를 제한함으로써 장애 조치(failover) 시간을 조정할 수 있습니다. 그러나 이 경우 동기화 상태를 보조 복제본에서 계속 유지해야 하므로 주 복제본의 속도가 느려질 수 있습니다.

3. 보조 복제본(replica)은 새로운 주 복제본(replica) 되고 이전의 주 복제본(replica)은 새로운 보조 복제본(replica이) 됩니다.

4. 새로운 주 복제본은 커밋되지 않은 모든 트랜잭션을 롤백하고 해당 데이터베이스를 주 데이터베이스로 사용할 수 있도록 온라인 상태로 만듭니다. 모든 보조 데이터베이스는 새로운 주 데이터베이스에 연결하여 다시 동기화할 때까지 잠시 동안 NOT SYNCHRONIZED로 표시됩니다. 이 프로세스에서는 커밋된 트랜잭션을 롤백되지 않습니다.

5. 이전 주 복제본이 다시 온라인 상태가 되면 이 데이터베이스가 보조 역할을 맡고 이전 주 데이터베이스는 보조 데이터베이스가 됩니다. 새로운 보조 복제본은 새로운 보조 데이터베이스를 해당 주 데이터베이스와 빠르게 다시 동기화합니다.

   참고 항목

   새로운 보조 복제본이 해당 데이터베이스를 다시 동기화되면 바로 장애 조치(Failover)를 반대 방향으로 다시 실행할 수 있습니다.

장애 조치(failover)를 한 후에 클라이언트는 현재 주 데이터베이스에 다시 연결해야 합니다. 자세한 내용은 가용성 그룹 수신기, 클라이언트 연결 및 애플리케이션 장애 조치(failover)(SQL Server)를 참조하세요.

업그레이드를 하는 동안에 가용성 유지

하드웨어나 소프트웨어를 업그레이드할 때 가용성 그룹의 데이터베이스 관리자는 수동 장애 조치(Failover)를 사용해서 데이터베이스 가용성을 유지 관리할 수 있습니다. 소프트웨어 업그레이드에 가용성 그룹을 사용하기 위해서 대상 보조 복제본을 호스팅하는 서버 인스턴스 및/또는 컴퓨터 노드는 업그레이드를 이미 수신한 상태여야 합니다. 자세한 정보는 Always On 가용성 그룹 복제본 인스턴스 업그레이드를 참조해 주세요.

강제 장애 조치(failover)(데이터가 손실될 수 있음)

가용성 그룹의 강제 장애 조치(Failover)(데이터가 손실될 수 있음)는 보조 복제본을 웜 대기 서버로 사용할 수 있는 재해 복구 방법입니다. 강제 장애 조치(Failover)를 실행하면 데이터가 손실될 위험이 있으므로 반드시 필요한 경우에만 주의해서 사용해야 합니다. 데이터 손실을 감수하더라도 즉시 가용성 데이터베이스 서비스를 복원해야 하는 경우에만 강제 장애 조치(Failover)를 실행하는 것을 권장합니다. 강제 장애 조치(failover)를 위한 사전 요구 사항 및 권장 사항에 대한 자세한 내용과 강제 장애 조치(failover)를 사용하여 치명적인 오류에서 복구하는 예제 시나리오는 가용성 그룹의 강제 수동 장애 조치(Failover) 수행(SQL Server)을 참조하세요.

섹션 내용:

• 강제 장애 조치(failover)의 작동 방법

• 강제 장애 조치(Failover)의 위험

• 강제 쿼럼 이후에 강제 장애 조치(failover)가 필요한 이유

• 잠재적인 데이터 손실 추적

• 잠재적 데이터 손실 관리

강제 장애 조치(failover)의 작동 방법

강제 장애 조치를 시작하면 역할이 SECONDARY 또는 RESOLVING 상태인 대상 복제본으로 기본 역할이 전환되게 됩니다. 장애 조치(failover) 대상은 새로운 주 복제본(replica) 되고 데이터베이스 복사본을 클라이언트에 즉시 제공합니다. 이전의 주 복제본을 사용할 수 있을 때 보조 역할로 전환되고 해당 데이터베이스는 일시 중지된 보조 데이터베이스가 됩니다.

모든 보조 데이터베이스(사용을 할 수 있는 경우 이전 주 데이터베이스 포함)는 일시 중지됩니다. 일시 중단된 보조 데이터베이스의 이전의 데이터 동기화 상태에 따라 해당 주 데이터베이스에 대해 누락된 커밋된 데이터를 복원하는 데 적합할 수 있습니다. 읽기 전용 액세스용으로 구성된 보조 복제본(replica)에 보조 데이터베이스를 쿼리하여 누락된 데이터를 수동으로 검색할 수 있습니다. 그런 다음, 새로운 주 데이터베이스에 대해 Transact-SQL 문을 실행하여 필요에 따라 변경할 수 있습니다.

강제 장애 조치(Failover)의 위험

강제 장애 조치(failover)로 인해 데이터가 손실될 수 있다는 점을 이해하는 것은 중요합니다. 대상 복제본(replica)이 기본 복제본(replica)과 통신할 수 없으므로 데이터베이스가 동기화되도록 보장할 수 없기 때문에 데이터 손실이 발생할 수 있습니다. 강제 장애 조치(failover)를 실행하면 새로운 복구 포크가 시작됩니다. 원래 주 데이터베이스와 보조 데이터베이스는 서로 다른 복구 분기에 있기 때문에 각 데이터베이스에는 다른 데이터베이스에 없는 데이터가 포함됩니다. 원래 각 주 데이터베이스에는 Send Queue에서 이전 보조 데이터베이스로 아직 전송되지 않은 모든 변경 사항(보내지 않은 로그)이 포함되며, 이전 보조 데이터베이스에는 강제 장애 조치(Failover)를 수행한 후 발생한 모든 변경 사항이 포함됩니다.

주 복제본이 실패하여 강제 장애 조치(Failover)가 실행된 경우 발생할 수 있는 데이터 손실은 실패 전에 트랜잭션 로그를 보조 복제본으로 전송했는지 여부에 따라 달라집니다. 비동기-커밋 모드에서는 전송하지 않은 누적 로그가 항상 있을 수 있습니다. 동기-커밋 모드에서는 보조 데이터베이스가 동기화될 때까지만 전송하지 않은 누적 로그가 있을 수 있습니다.

다음 표에서는 강제 장애 조치(Failover)할 복제본의 특정 데이터베이스에 관한 데이터 손실 가능성을 요약하여 보여주고 있습니다.

보조 데이터베이스는 두 개의 복구 포크만 추적하기 때문에 여러 가지 강제 장애 조치(failover)를 실행하는 경우 이전의 강제 장애 조치(failover)와 데이터 동기화를 시작한 보조 데이터베이스가 다시 시작되지 않을 수도 있습니다. 이럴 때는 다시 시작될 수 없는 보조 데이터베이스는 올바른 시점으로부터 복원된 가용성 그룹에서 제거한 이후에 가용성 그룹에 다시 조인되어야 합니다. 이 시나리오에서는 상태가 103인 오류 1408이 관찰될 수 있습니다(오류: 1408, 심각도: 16, 상태: 103). 여러 복구 분기 지점에 대해 복원을 수행할 수 없으므로 둘 이상의 강제 장애 조치(Failover) 수행한 후 로그 백업을 수행해야 합니다.

강제 쿼럼 후에 강제 장애 조치(failover)가 필요한 이유

WSFC 클러스터에서 쿼럼을 수행한 후에는(강제 쿼럼) 각 가용성 그룹에 대해 강제 장애 조치(failover)(데이터 손실 가능)를 수행해야 합니다. 강제 장애 조치(failover)가 필요한 이유는 WSFC 클러스터 값의 실제 상태가 손실되었을 수 있기 때문입니다. 동기화되지 않은 보조 복제본(replica) 다시 구성된 WSFC 클러스터에서 동기화되는 것처럼 보일 수 있기 때문에 강제 쿼럼 후 정상적인 장애 조치(failover)를 방지해야 합니다.

세 개의 노드에서 가용성 그룹을 호스트하는 WSFC 클러스터를 예로 들어 보겠습니다. 노드 A는 주 복제본을 호스트하고 노드 B와 노드 C는 보조 복제본을 호스트합니다. 로컬 보조 복제본이 동기화하가 이뤄지는 동안 노드 C는 WSFC 클러스터에서 연결이 끊어집니다. 그러나 노드 A와 노드 B는 정상 상태의 쿼럼을 유지하고 가용성 그룹을 온라인 상태로 유지합니다. 노드 A에서 주 복제본은 계속해서 업데이트를 허용하고 노드B에서 보조 복제본은 계속해서 주 복제본과 동기화합니다. 노드 C에서 보조 복제본은 비동기화되고 주 복제본 뒤에서 점점 뒤쳐집니다. 그러나, 노드 C는 연결이 끊어졌기 때문에 복제본의 동기화 상태가 잘못 유지됩니다.

쿼럼이 손실된 이후에 노드 A에서 강제 적용되는 경우 WSFC 클러스터에서 가용성 그룹의 동기화 상태는 UNSYNCHRONIZED로 표시되는 노드 C의 보조 복제본에서 올바른 상태여야 합니다. 그러나 노드 C에서 쿼럼이 강제로 적용되면 가용성 그룹의 동기화는 올바르지 않습니다. 클러스터의 동기화 상태는 SYNCHRONIZED로 잘못 표시된 노드 C의 보조 복제본과 노드 C 연결이 끊어진 상태로 되돌아가야 합니다. 계획된 수동 장애 조치(failover)는 데이터의 안전성을 보장하므로 쿼럼이 강제로 적용된 후 가용성 그룹을 다시 온라인 상태가 되도록 허용하지 않습니다.

잠재적인 데이터 손실 추적

WSFC 클러스터의 쿼럼이 정상 상태이면 데이터베이스에 대한 현재의 잠재적 데이터 손실을 예측할 수 있습니다. 지정된 보조 복제본(replica)의 경우 현재 데이터의 손실 가능성은 로컬 보조 데이터베이스가 해당 주 데이터베이스보다 오래되었는지에 따라 달라집니다. 지연 양은 시간에 따라 다르기 때문에 동기화되지 않은 보조 데이터베이스에 대한 잠재적인 데이터 손실을 주기적으로 추적하는 것이 좋습니다. 지연 간격 추적은 각각의 주 데이터베이스 및 보조 데이터베이스에 관한 마지막 커밋 LSN 및 마지막 커밋 시간을 다음과 같이 비교합니다:

1. 주 복제본에 연결합니다.

2. sys.dm_hadr_database_복제본(replica)_states 동적 관리 뷰의 last_commit_lsn(마지막으로 커밋된 트랜잭션의 LSN) 및 last_commit_time(마지막 커밋 시간) 열을 쿼리합니다.

3. 각각의 주 데이터베이스와 보조 데이터베이스에 대해 반환되는 값을 비교합니다. 마지막 커밋 LSN 간의 차이는 지연의 양을 나타냅니다.

4. 데이터베이스 또는 데이터베이스 집합의 지연 양이 지정된 기간 동안 원하는 최대 지연을 초과할 때 알림을 트리거할 수 있습니다. 예를 들어 각 주 데이터베이스에서 매 분마다 실행되는 작업을 통해서 쿼리를 실행할 수 있습니다. 작업이 실행된 마지막 시간 이후 주 데이터베이스와 보조 데이터베이스의 last_commit_time 간 차이가 RPO(복구 지점 목표)(예: 5분)를 초과하는 경우 작업에서 알림이 발생할 수 있습니다.

잠재적 데이터 손실 관리

장애 조치(failover)를 한 후에 모든 보조 데이터베이스는 일시 중단됩니다. 여기에는 이전의 주 복제본이 다시 온라인 상태가 되서 현재의 보조 복제본임을 확인한 후에 이전의 주 데이터베이스를 포함하는 것입니다. 각 보조 복제본에서 일시 중지된 각 데이터베이스를 개별적으로 수동 재개해야 합니다.

이전의 주 복제본(replica)을 사용할 수 있게 되면 데이터베이스가 손상되지 않은 것으로 가정하여 잠재적인 데이터 손실을 관리할 수 있습니다. 잠재적인 데이터 손실을 관리하는 데 사용할 수 있는 방법은 원래 주 복제본(replica)이 새 주 복제본(replica)에 연결되었는지 여부에 따라 달라집니다. 원래 주 복제본이 새로운 주 인스턴스에 액세스할 수 있다고 가정하면 자동으로 명확하게 다시 연결할 수 있습니다.

원래 주 복제본이 다시 연결된 경우

일반적으로 실패 후에 원래 주 서버가 다시 시작될 때 신속하게 해당 파트너에 다시 연결합니다. 다시 연결할 때 원래 기본 복제본(replica)은 보조 복제본(replica)이 됩니다. 해당 데이터베이스는 보조 데이터베이스가 되고 일시 중단 상태가 됩니다. 새로운 보조 데이터베이스는 다시 시작하지 않는 한 롤백되지 않습니다.

그러나 일시 중단된 데이터베이스에 액세스할 수 없기 때문에 지정된 데이터베이스를 다시 시작하면 손실될 데이터를 평가하기 위해 검사할 수 없게 됩니다. 따라서 다음과 같이 데이터 손실을 감수할지 여부에 따라 보조 데이터베이스를 재개할지 또는 제거할지를 결정합니다:

• 데이터 손실이 허용되지 않는 경우 가용성 그룹에서 데이터베이스를 제거해서 복구해야 합니다.

  이제 데이터베이스 관리자는 이전의 주 데이터베이스를 복구하고 손실된 데이터를 복구하기 위한 시도를 할 수 있습니다. 하지만 이전의 주 데이터베이스가 온라인 상태가 되면 현재 주 데이터베이스에서 분기되므로, 데이터베이스 관리자는 제거된 데이터베이스 또는 현재 주 데이터베이스에 클라이언트가 액세스할 수 없도록 하여 데이터베이스의 추가 분기를 방지하고 클라이언트 장애 조치(Failover) 문제를 예방해야 합니다.

• 비즈니스 목표에 따라 데이터 손실이 허용되는 경우 보조 데이터베이스를 재개할 수 있습니다.

  새로운 보조 데이터베이스를 재개하면 데이터베이스 동기화의 첫 번째 단계로 해당 데이터베이스가 롤백됩니다. 로그 레코드에서 장애가 발생 시 전송 큐에서 대기 중인 경우 해당 트랜잭션은 커밋되더라도 손실됩니다.

원래의 주 복제본이 다시 연결되지 않는 경우

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

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

  원래의 주 복제본(replica)을 새 주 복제본(replica)에 다시 연결하도록 허용합니다. 다시 연결하면 새 보조 데이터베이스는 일시 중단되게 됩니다. 데이터베이스에서 데이터 동기화를 시작하려면 데이터베이스를 다시 시작하면 됩니다. 새로운 보조 복제본은 해당 데이터베이스에 대한 원래 복구 분기를 삭제하기 때문에 이전의 보조 복제본으로 보내거나 받지 않은 모든 트랜잭션은 손실되게 됩니다.

• 데이터 손실이 허용되지 않는 경우

  일시 중지된 데이터베이스를 다시 재개할 경우 손실될 중요한 데이터가 원래 주 데이터베이스에 들어 있을 경우 가용성 그룹에서 원래 주 데이터베이스를 제거하여 해당 데이터를 보존할 수 있습니다. 이렇게 함으로써 데이터베이스가 RESTORING 상태가 됩니다. 이 시점에서는 제거된 데이터베이스 비상 로그를 백업하는 것이 좋습니다. 그런 다음 원래 주 데이터베이스에서 복구할 데이터를 내보냄으로써 현재 주 데이터베이스로 가져와서 현재 주 데이터베이스(이전 보조 데이터베이스)를 업데이트할 수 있습니다. 업데이트된 주 데이터베이스의 전체 데이터베이스 백업을 최대한 빨리 수행하는 것이 좋습니다.

  그런 다음 새로운 보조 복제본(replica)을 호스팅하는 서버 인스턴스에서 RESTORE WITH NORECOVERY를 사용해서 이 백업(및 하나 이상의 후속 로그 백업)을 복원하여 일시 중단된 보조 데이터베이스를 삭제하고 새 보조 데이터베이스를 만들 수 있습니다. 해당 보조 데이터베이스가 다시 시작될 때까지 현재의 주 데이터베이스의 추가 로그 백업을 지연하는 것을 권장드립니다.

관련 작업

장애 조치(failover) 동작을 구성하려면

• 가용성 복제본의 가용성 모드 변경(SQL Server)

• 가용성 복제본의 장애 조치(failover) 모드 변경(SQL Server)

• 유연성 있는 장애 조치(failover) 정책을 구성하여 자동 장애 조치의 상태 제어(AlwaysOn 가용성 그룹)

수동 장애 조치(failover)를 실행하려면

• 가용성 그룹의 계획된 수동 장애 조치(Failover) 실행(SQL Server)

• 가용성 그룹의 강제 수동 장애 조치 실행(SQL Server)

• 가용성 그룹 마법사 사용(SQL Server Management Studio)

• 가용성 그룹의 데이터베이스에 대한 로그인 및 작업 관리(SQL Server)

WSFC 쿼럼 구성을 구성하려면

• 클러스터 쿼럼 NodeWeight 설정 구성

• 클러스터 쿼럼 NodeWeight 설정 보기

• 쿼럼 없이 WSFC 클러스터 강제 시작

관련 내용

• 고가용성 및 재해 복구를 위한 Microsoft SQL Server Always On 솔루션 가이드

• SQL Server Always On 팀 블로그: 공식 SQL Server Always On 팀 블로그

참고 항목

Always On 가용성 그룹 개요(SQL Server)
가용성 모드(Always On 가용성 그룹)
SQL Server의 WSFC(Windows Server 장애 조치(Failover) 클러스터링)
Always On 가용성 그룹 및 데이터베이스 미러링을 위한 데이터베이스 간의 트랜잭션 및 분산 트랜잭션(SQL Server)
Failover Policy for Failover Cluster Instances
가용성 그룹 자동 장애 조치(Failover)에 대한 유연성 있는 장애 조치 정책(SQL Server)