가용성 그룹의 컨텍스트 내에서 가용성 복제본의 주 역할 및 보조 역할은 일반적으로 장애 조치( failover)라고 하는 프로세스에서 서로 교환할 수 있습니다. 자동 장애 조치(데이터가 손실되지 않음), 계획된 수동 장애 조치(데이터가 손실되지 않음)와 강제 장애 조치(failover)라고 불리는 강제 수동 장애 조치(데이터가 손실될 수 있음)의 세 가지 형태가 있습니다. 자동 및 계획된 수동 장애 조치(failover)는 모든 데이터를 유지합니다. 가용성 그룹은 가용성 복제본 수준에서 장애 조치(fail over)합니다. 즉, 가용성 그룹은 현재 장애 조치 대상인 보조 복제본 중 하나로 장애 조치됩니다.
비고
데이터 파일 손실, 데이터베이스 삭제 또는 트랜잭션 로그 손상으로 인해 데이터베이스가 의심되는 것과 같은 데이터베이스 수준의 문제는 가용성 그룹이 장애 조치(failover)를 일으키지 않습니다.
장애 조치(failover) 중에 장애 조치 대상은 주 역할을 인수하고, 데이터베이스를 복구하고, 새 주 데이터베이스로 온라인 상태로 전환합니다. 사용 가능한 경우 이전 주 복제본은 보조 역할로 전환되고 해당 데이터베이스는 보조 데이터베이스가 됩니다. 잠재적으로 이러한 역할은 여러 오류에 대응하거나 관리 목적으로 앞뒤로(또는 다른 장애 조치 대상으로) 전환할 수 있습니다.
지정된 가용성 복제본이 지원하는 장애 조치(failover) 양식은 장애 조치(failover) 모드 속성에 의해 지정됩니다. 지정된 가용성 복제본의 경우 가능한 장애 조치 모드는 다음과 같이 복제본의 가용성 모드 에 따라 달라집니다.
동기 커밋 복제본은 두 가지 설정인 자동 혹은 수동을 지원합니다. "자동" 설정은 자동 장애 조치(failover) 및 수동 장애 조치(failover)를 모두 지원합니다. 데이터 손실을 방지하기 위해 자동 장애 조치(failover) 및 계획된 장애 조치(failover)를 수행하려면 장애 조치(failover) 대상이 정상 동기화 상태인 동기 커밋 보조 복제본이어야 합니다(장애 조치 대상의 모든 보조 데이터베이스가 해당 주 데이터베이스와 동기화됨을 나타냅니다). 보조 복제본이 이러한 두 조건을 모두 충족하지 않을 때마다 강제 장애 조치(failover)만 지원합니다. 역할이 RESOLVING 상태인 복제본에서도 강제 장애 조치(failover)가 지원됩니다.
비동기-커밋 복제본은 수동 장애 조치(failover) 모드만 지원합니다. 또한 동기화되지 않으므로 강제 장애 조치(failover)만 지원합니다.
비고
장애 조치(failover) 후 주 데이터베이스에 액세스해야 하는 클라이언트 애플리케이션은 새 주 복제본에 연결해야 합니다. 또한 새 보조 복제본이 읽기 전용 액세스를 허용하도록 구성된 경우 읽기 전용 클라이언트 애플리케이션이 해당 복제본에 연결할 수 있습니다. 클라이언트가 가용성 그룹에 연결하는 방법에 대한 자세한 내용은 가용성 그룹 수신기, 클라이언트 연결 및 애플리케이션 장애 조치(Failover)(SQL Server)를 참조하세요.
용어 및 정의
자동 장애 조치
주 복제본 상실 시 자동으로 발생하는 장애 조치입니다. 자동 장애 조치(failover)는 현재 주 복제본과 하나의 보조 복제본이 모두 자동으로 설정된 장애 조치(failover) 모드로 구성되고 보조 복제본이 현재 동기화된 경우에만 지원됩니다. 주 복제본 또는 보조 복제본의 장애 조치(failover) 모드가 MANUAL이면 자동 장애 조치(failover)가 발생할 수 없습니다.
데이터 손실 없는 계획된 수동 전환
계획된 수동 장애 조치( failover) 또는 수동 장애 조치(failover)는 일반적으로 관리 목적으로 데이터베이스 관리자가 시작하는 장애 조치(failover)입니다. 계획된 수동 장애 조치(failover)는 주 복제본과 보조 복제본이 동기-커밋 모드로 구성되고 보조 복제본이 현재 동기화된 경우에만 지원됩니다(SYNCHRONIZED 상태). 대상 보조 복제본이 동기화되면 보조 데이터베이스가 장애 조치(failover)할 준비가 되었기 때문에 주 복제본이 중단된 경우에도 수동 장애 조치(failover)(데이터 손실 제외)가 가능합니다. 데이터베이스 관리자는 수동 장애 조치(failover)를 수동으로 시작합니다.
강제 장애 조치 (데이터 손실 가능성)
주 복제본과 동기화된 보조 복제본이 없거나 주 복제본이 실행되고 있지 않고 보조 복제본이 준비되지 않은 경우 데이터베이스 관리자가 시작할 수 있는 장애 조치(failover)입니다. 강제 장애 조치(failover)는 데이터 손실을 초래할 수 있으며 재해 복구를 위해 엄격하게 권장됩니다. 강제 장애 조치는 수동으로만 초래되기 때문에 강제 수동 장애 조치라고도 불립니다. 비동기 커밋 가용성 모드에서 지원하는 유일한 장애 조치(failover) 형식입니다.
자동 장애 조치(failover) 집합
지정된 가용성 그룹 내에서 자동 장애 조치(failover)가 있는 동기-커밋 모드에 대해 구성된 가용성 복제본 쌍(현재 주 복제본 포함)입니다(있는 경우). 보조 복제본이 현재 주 복제본과 동기화된 경우에만 Anautomatic 장애 조치(failover)가 적용됩니다.
동기적 커밋 장애 조치 세트
지정된 가용성 그룹 내에서 동기-커밋 모드(있는 경우)에 대해 구성된 두 개 또는 세 개의 가용성 복제본(현재 주 복제본 포함)의 집합입니다. 보조 복제본이 수동 장애 조치(failover) 모드로 설정되어 있고, 최소한 하나의 보조 복제본이 현재 주 복제본과 동기화된 경우에만 동기-커밋 장애 조치가 적용됩니다.
전체 장애 조치 집합
지정된 가용성 그룹 내에서 가용성 모드 및 장애 조치(failover) 모드에 관계없이 작동 상태가 현재 ONLINE인 모든 가용성 복제본 집합입니다. 현재 주 복제본과 동기화된 보조 복제본이 없는 경우 전체 장애 조치 집합이 관련됩니다.
장애 조치 개요
다음 표는 다양한 가용성 모드와 장애 조치 모드에서 지원되는 장애 조치 형태를 요약한 것입니다. 각 페어링에 대해 유효 가용성 모드 및 장애 조치(failover) 모드는 주 복제본(replica) 모드와 하나 이상의 보조 복제본 모드의 교차점에 따라 결정됩니다.
| 비동기-커밋 모드 | 동기 커밋 모드와 수동 장애 조치 모드 | 자동 장애 조치 모드를 사용하는 동기 커밋 모드 | |
|---|---|---|---|
| 자동 장애 조치 | 아니오 | 아니오 | 예 |
| 계획된 수동 장애 전환 | 아니오 | 예 | 예 |
| 강제 장애 조치(failover) | 예 | 예 | 예***** |
* 동기화된 보조 복제본에서 강제 장애 조치(failover) 명령을 실행하면 보조 복제본은 수동 장애 조치(failover)와 동일하게 작동합니다.
장애 조치(Failover) 동안 데이터베이스를 사용할 수 없는 기간은 장애 조치(Failover)의 유형 및 해당 원인에 따라 다릅니다.
중요합니다
포함된 데이터베이스를 제외하고 장애 조치(failover) 후 클라이언트 연결을 지원하려면 이전 주 데이터베이스에 정의된 로그인 및 작업을 새 주 데이터베이스에서 수동으로 다시 만들어야 합니다. 자세한 내용은 가용성 그룹의 데이터베이스에 대한 로그인 및 작업 관리(SQL Server)라는 프로세스에서 서로 바꿀 수 있습니다.
장애 조치 집합 (Failover Sets)
지정된 가용성 그룹에 대해 가능한 장애 조치 형식은 장애 조치 집합의 관점에서 이해할 수 있습니다. 장애 조치 집합은 다음과 같이 지정된 형태의 장애 조치(failover)를 지원하는 주 복제본 및 보조 복제본으로 구성됩니다.
자동 장애 조치 집합(선택 사항): 특정 가용성 그룹 내에서 자동 장애 조치가 가능한 동기 커밋 모드로 설정된 복제본 쌍(현재 주 복제본 포함)입니다(있는 경우). 자동 장애 조치(failover) 집합은 보조 복제본이 현재 주 복제본과 동기화된 경우에만 적용됩니다.
동기-커밋 장애 조치 전환 집합(선택 사항): 지정된 가용성 그룹 내에서 두 개 또는 세 개의 가용성 복제본 (현재 주 복제본 포함)이 동기-커밋 모드로 구성된 경우의 집합입니다. 동기-커밋 장애 조치(failover) 집합은 보조 복제본이 수동 장애 조치(failover) 모드로 구성된 경우, 그리고 하나 이상의 보조 복제본이 현재 주 복제본과 동기화된 경우에만 적용됩니다.
전체 장애 조치(failover) 집합: 지정된 가용성 그룹 내에서 가용성 모드 및 장애 조치(failover) 모드에 관계없이 작동 상태가 현재 ONLINE인 모든 가용성 복제본 집합입니다. 현재 주 복제본과 동기화된 보조 복제본이 없는 경우 전체 장애 조치(failover) 집합이 관련됩니다.
가용성 복제본을 자동 장애 조치(failover)를 사용하여 동기 커밋으로 구성하면 가용성 복제본이 자동 장애 조치(failover) 집합의 일부가 됩니다. 그러나 설정의 효력이 발생하는지는 현재 조건에 따라 달라집니다. 지정된 시간에 실제로 가능한 장애 조치(failover) 형식은 현재 적용되는 장애 조치(failover) 집합에 따라 달라집니다.
예를 들어 다음과 같이 4개의 가용성 복제본이 있는 가용성 그룹을 고려합니다.
| 복제본 | 가용성 모드 및 장애 조치 모드 설정 |
|---|---|
| A | 동기 커밋 및 자동 장애 조치 |
| b | 자동 페일오버를 사용하는 동기적 커밋 |
| C | 계획된 수동 장애 조치(failover)을 위한 동기 커밋 |
| D | 비동기 커밋(강제 장애 조치만 포함) |
각 보조 복제본에 대한 장애 조치(failover) 동작은 현재 주 복제본인 가용성 복제본에 따라 달라집니다. 기본적으로 지정된 보조 복제본의 경우 현재 주 복제본을 고려할 때 장애 조치(failover) 동작이 최악의 경우입니다. 다음 그림에서는 현재 주 복제본에 따라 보조 복제본의 장애 조치 동작이 어떻게 달라지는지를 보여주며, 강제 장애 조치만 가능한 비동기 커밋 모드와 자동 장애 조치가 가능한지 여부와 관계없이 구성될 수 있는 동기 커밋 모드에 대해 설명합니다.
자동 장애 조치
자동 장애 조치(failover)가 수행되면 주 복제본을 사용할 수 없게 될 경우, 자격을 갖춘 보조 복제본이 주 역할을 자동으로 수행합니다. 자동 장애 조치(failover)는 주 복제본을 호스트하는 WSFC 노드가 보조 복제본을 호스트하는 노드에 로컬인 경우에 가장 적합합니다. 이는 컴퓨터 간의 메시지 대기 시간이 짧고 클라이언트 연결이 로컬로 유지될 수 있기 때문에 데이터 동기화가 가장 잘 작동하기 때문입니다.
자동 페일오버에 필요한 조건
자동 장애 조치(failover)는 다음 조건에서만 발생합니다.
자동 장애 조치(failover) 집합이 있습니다. 이 집합은 동기-커밋 모드로 구성된 주 복제본과 보조 복제본(자동 장애 조치 대상)으로 구성되며, 둘 다 자동 장애 조치로 설정되어 있습니다. HYPERLINK "file:///C:\\Users\\marshow\\AppData\\Local\\Temp\\DxEditor\\DduePreview\\Default\\6fe88e12-4df1-4025-ba24-7579635ccecf\\HTM\\html\\29e0ac5d-eb58-4801-82b9-e278f08db920" 주 복제본이 MANUAL 장애 조치(failover)로 설정된 경우 자동 장애 조치(failover)가 발생할 수 없습니다. 보조 복제본이 AUTOMATIC 장애 조치(failover)로 설정된 경우에도 해당합니다.
자세한 내용은 가용성 모드(AlwaysOn 가용성 그룹)를 참조하세요.
자동 장애 조치(failover) 대상의 동기화 상태가 정상입니다(장애 조치 대상의 모든 보조 데이터베이스가 해당 주 데이터베이스와 동기화됨을 나타냅니다).
팁 (조언)
AlwaysOn 가용성 그룹은 자동 장애 조치 전환 셋에서 두 복제본의 상태를 모니터링합니다. 복제본 중 하나가 실패하면 가용성 그룹의 상태가 CRITICAL로 설정됩니다. 보조 복제본에 장애가 발생하면, 자동 장애 조치를 수행할 수 없습니다. 이는 자동 장애 조치 대상이 사용할 수 없기 때문입니다. 주 데이터 복제본이 실패하면 가용성 그룹이 보조 데이터 복제본으로 전환됩니다. 이전 주 복제본이 온라인 상태가 될 때까지 자동 전환 대상이 없습니다. 두 경우 모두 연속 오류가 발생하는 드문 상황에서도 가용성을 보장하기 위해, 자동 장애 조치 대상으로 다른 보조 복제본을 구성하는 것이 좋습니다.
자세한 내용은 AlwaysOn 정책을 사용하여 가용성 그룹의 상태를 모니터링하는 방법(SQL Server) 및 가용성 복제본의 장애 조치(failover) 모드 변경 방법(SQL Server)을 참조하세요.
WSFC(Windows Server 장애 조치 클러스터링) 클러스터에는 쿼럼이 있습니다. 자세한 내용은 WSFC 쿼럼 모드 및 응답 구성(SQL Server)을 참조하세요.
주 복제본을 사용할 수 없게 되었으며, 탄력적인 장애 조치 정책에 의해 정의된 장애 조치 조건 수준이 충족되었습니다. 장애 조치(failover) 조건 수준에 대한 자세한 내용은 가용성 그룹의 자동 장애 조치(Failover)에 대한 유연한 장애 조치 정책(SQL Server)을 참조하세요.
자동 장애 조치의 작동 원리
자동 페일오버는 다음 일련의 작업을 시작합니다.
현재 주 복제본을 호스팅하는 서버 인스턴스가 여전히 실행 중인 경우 주 데이터베이스의 상태를 DISCONNECTED로 변경하고 모든 클라이언트의 연결을 끊습니다.
대상 보조 복제본의 복구 큐에서 대기 중인 로그 레코드가 있는 경우 보조 복제본은 나머지 로그 레코드를 적용하여 보조 데이터베이스 롤 포워드를 완료합니다.
비고
지정된 데이터베이스에 로그를 적용하는 데 필요한 시간은 시스템의 속도, 최근 작업 부하 및 복구 큐의 로그 양에 따라 달라집니다.
이전 보조 복제본이 주 역할을 맡습니다. 해당 데이터베이스는 주 데이터베이스가 됩니다. 새 주 복제본은 커밋되지 않은 트랜잭션(복구 실행 취소 단계)을 가능한 한 빨리 롤백합니다. 잠금은 커밋되지 않은 트랜잭션을 격리하여 클라이언트가 데이터베이스를 사용하는 동안 백그라운드에서 롤백이 수행되도록 합니다. 이 프로세스는 커밋된 트랜잭션을 롤백하지 않습니다.
지정된 보조 데이터베이스가 연결될 때까지 잠시 NOT_SYNCHRONIZED 표시됩니다. 롤백 복구가 시작되기 전에 보조 데이터베이스는 새 주 데이터베이스에 연결하고 SYNCHRONIZED 상태로 빠르게 전환할 수 있습니다. 가장 좋은 사례는 일반적으로 장애 조치(failover) 후 보조 역할에 남아 있는 세 번째 동기-커밋 복제본에 대한 것입니다.
나중에 이전 주 복제본을 호스팅하는 서버 인스턴스가 다시 시작되면 다른 가용성 복제본이 이제 주 역할을 소유하고 있음을 인식합니다. 이전 주 복제본은 보조 역할로 전환되고 해당 데이터베이스는 보조 데이터베이스가 됩니다. 새 보조 복제본은 현재 주 복제본에 연결하여 가능한 한 빨리 데이터베이스를 현재 주 데이터베이스 수준에 맞춰 동기화합니다. 새 보조 복제본의 데이터베이스가 다시 동기화되는 즉시 역방향으로 장애 조치가 가능합니다.
자동 장애 조치를 구성하려면
가용성 복제본은 언제든지 자동 장애 조치를 지원하도록 구성할 수 있습니다.
자동 페일오버 구성을 위해
보조 복제본이 동기-커밋 가용성 모드를 사용하도록 구성되어 있는지 확인합니다. 자세한 내용은 가용성 복제본의 가용성 모드 변경(SQL Server)을 참조하세요.
장애 조치 모드를 자동으로 설정합니다. 자세한 내용은 가용성 복제본의 장애 조치 모드(failover) 변경(SQL Server)을 참조하세요.
필요에 따라 가용성 그룹의 유연한 장애 조치(failover) 정책을 변경하여 자동 장애 조치(failover)가 발생할 수 있는 오류 종류를 지정합니다. 자세한 내용은 유연한 장애 조치(failover) 정책을 구성하여 자동 장애 조치의 조건을 제어하기 HYPERLINK "file:///C:\\Users\\marshow\\AppData\\Local\\Temp\\DxEditor\\DduePreview\\Default\\6a8d98a9-6e6a-40d1-9809-efa9013d7452\\HTM\\html\\1ed564b4-9835-4245-ae35-9ba67419a4ce" 및 장애 조치(failover) 클러스터 인스턴스에 대한 장애 조치 정책을 참조하세요.
계획된 수동 장애 조치 (데이터 손실 없음)
수동 장애 조치(failover)를 수행하면 데이터베이스 관리자가 대상 보조 복제본을 호스트하는 서버 인스턴스에서 수동 장애 조치(failover) 명령을 실행한 후 동기화된 보조 복제본이 주 역할로 전환됩니다. 수동 장애 조치(failover)를 지원하려면 보조 복제본과 현재 주 복제본을 모두 동기-커밋 모드(있는 경우)로 구성해야 합니다. 가용성 복제본의 모든 보조 데이터베이스는 가용성 그룹에 조인하고 해당 주 데이터베이스와 동기화되어야 합니다(즉, 보조 복제본을 동기화해야 합니다). 이렇게 하면 이전 주 데이터베이스에서 커밋된 모든 트랜잭션도 새 주 데이터베이스에서 커밋됩니다. 따라서 새 주 데이터베이스는 이전 주 데이터베이스와 동일합니다.
다음 그림에서는 계획된 장애 조치(failover)의 단계를 보여 줍니다.
장애 조치 전, 주 복제본이 서버 인스턴스에 의해 호스팅됩니다
Node01.데이터베이스 관리자가 계획된 장애 조치를 시작합니다. 장애 조치 대상은
Node02에 있는 서버 인스턴스가 호스팅하는 가용성 복제본입니다.장애 조치 대상(
Node02)이 새 주 복제본이 됩니다. 계획된 장애 조치(failover)이므로 이전 주 복제본은 장애 조치(failover) 중에 보조 역할로 전환하고 해당 데이터베이스를 즉시 보조 데이터베이스로 온라인 상태로 전환합니다.
수동 장애 조치에 필요한 조건
수동 장애 조치(failover)를 지원하려면 현재 주 복제본을 동기-커밋 모드로 설정해야 하며 보조 복제본은 다음이어야 합니다.
동기-커밋 모드로 구성됩니다.
현재 주 복제본과 동기화됩니다.
가용성 그룹을 수동으로 페일오버하려면 새 주 복제본이 될 보조 복제본에 연결해야 합니다.
계획된 수동 장애 조치(failover)의 작동 방식
대상 보조 복제본에서 시작해야 하는 계획된 수동 장애 조치(failover)는 다음 작업 시퀀스를 시작합니다.
원래 주 데이터베이스에서 새 사용자 트랜잭션이 발생하지 않도록 WSFC 클러스터는 오프라인으로 전환하기 위해 주 복제본에 요청을 보냅니다.
보조 데이터베이스의 복구 큐에서 로그가 대기 중인 경우 보조 복제본은 해당 보조 데이터베이스의 앞으로 진행을 처리합니다. 필요한 시간은 시스템의 속도, 최근 워크로드 및 복구 큐의 로그 양에 따라 달라집니다. 복구 큐의 현재 크기를 알아보려면 복구 큐 성능 카운터를 사용합니다. 자세한 내용은 SQL Server, 데이터베이스 복제본을 참조하세요.
비고
장애 조치(failover) 시간은 복구 큐의 크기를 제한하여 규제할 수 있습니다. 그러나 이로 인해 주 복제본의 속도가 느려져서 보조 복제본이 따라잡을 수 있게 됩니다.
보조 복제본은 새 주 복제본이 되고 이전 주 복제본은 새 보조 복제본이 됩니다.
새 주 복제본은 커밋되지 않은 트랜잭션을 롤백하고 데이터베이스를 주 데이터베이스로 온라인 상태로 설정합니다. 모든 보조 데이터베이스는 연결하고 새 주 데이터베이스에 다시 동기화할 때까지 잠시 동기화되지 않음으로 표시됩니다. 이 프로세스는 커밋된 트랜잭션을 롤백하지 않습니다.
이전 주 복제본이 다시 온라인 상태가 되면 보조 역할을 맡게 되고 이전 주 데이터베이스는 보조 데이터베이스가 됩니다. 새 보조 복제본은 해당 주 데이터베이스를 사용하여 새 보조 데이터베이스를 신속하게 다시 동기화합니다.
비고
새 보조 복제본이 데이터베이스를 다시 동기화하자마자 장애조치가 다시 가능해지지만 이번에는 역방향으로 가능합니다.
장애 조치(failover) 후 클라이언트는 현재 주 데이터베이스에 다시 연결해야 합니다. 자세한 내용은 가용성 그룹 수신기, 클라이언트 연결 및 애플리케이션 장애 조치(SQL Server)를 참조하세요.
업그레이드 중 가용성 유지 관리
가용성 그룹의 데이터베이스 관리자는 수동 장애 조치(failover)를 사용하여 하드웨어 또는 소프트웨어를 업그레이드할 때 데이터베이스 가용성을 유지할 수 있습니다. 소프트웨어 업그레이드에 가용성 그룹을 사용하려면 대상 보조 복제본을 호스트하는 서버 인스턴스 및/또는 컴퓨터 노드가 이미 업그레이드를 받았어야 합니다. 자세한 내용은 가동 중지 시간 및 데이터 손실을 최소화한 가용성 그룹 서버 업그레이드 및 업데이트를 참조하세요.
** 강제 장애 전환 (데이터 손실 가능성 탑재)
가용성 그룹 강제 장애 조치(가능한 데이터 손실)는 보조 복제본을 웜 대기 서버로 사용하는 재해 복구 방법입니다. 강제 장애 조치는 데이터 손실이 발생할 수 있으므로 신중하고 드물게 사용해야 합니다. 가용성 데이터베이스에 서비스를 즉시 복원해야 하며 데이터 손실 위험을 감수해야 하는 경우에만 장애 조치(failover)를 강제 적용하는 것이 좋습니다. 강제 장애 조치(failover)를 위한 필수 구성 요소 및 권장 사항 및 강제 장애 조치(failover)를 사용하여 치명적인 오류로부터 복구하는 예제 시나리오에 대한 자세한 내용은 가용성 그룹의 강제 수동 장애 조치(Failover) 수행(SQL Server)을 참조하세요.
경고
강제 장애 조치를 수행하려면 WSFC 클러스터가 쿼럼을 갖고 있어야 합니다. 쿼럼 구성 및 강제 쿼럼에 대한 자세한 내용은 SQL Server를 사용하여 WSFC(Windows Server 장애 조치(failover) 클러스터링)를 참조하세요.
강제 장애 조치(failover)의 작동 방식
강제 장애 조치는 주 역할을 SECONDARY 또는 RESOLVING 상태에 있는 타겟 복제본으로 전환하는 과정을 시작합니다. 장애 조치(failover) 대상은 새 주 복제본이 되며 데이터베이스 복사본을 클라이언트에 즉시 제공합니다. 이전 주 복제본을 사용할 수 있게 되면 보조 역할로 전환되고 해당 데이터베이스는 보조 데이터베이스가 됩니다.
모든 보조 데이터베이스(사용 가능할 경우 이전 주 데이터베이스 포함)가 일시 중지되었습니다. 일시 중단된 보조 데이터베이스의 이전 데이터 동기화 상태에 따라 해당 주 데이터베이스에 대해 누락된 커밋된 데이터를 회수하는 데 적합할 수 있습니다. 읽기 전용 액세스를 위해 구성된 보조 복제본에서 보조 데이터베이스를 쿼리하여 누락된 데이터를 수동으로 검색할 수 있습니다. 그런 다음 새 주 데이터베이스에 Transact-SQL 문을 실행하여 필요한 내용을 변경할 수 있습니다.
강제 장애 조치의 위험
강제 장애 조치(failover)로 인해 데이터가 손실될 수 있음을 이해해야 합니다. 대상 복제본이 주 복제본과 통신할 수 없으므로 데이터베이스가 동기화되도록 보장할 수 없으므로 데이터 손실이 발생할 수 있습니다. 강제 장애 조치 수행은 새 복구 포크를 시작합니다. 원래 주 데이터베이스와 보조 데이터베이스는 서로 다른 복구 포크에 있으므로 각 데이터베이스에는 다른 데이터베이스에 포함되지 않은 데이터가 포함됩니다. 각 원래 주 데이터베이스에는 송신 큐에서 이전 보조 데이터베이스(보내지 않은 로그)로 전송되지 않은 변경 내용이 모두 포함됩니다. 이전 보조 데이터베이스에는 장애 조치(failover)가 강제 적용된 후 발생하는 모든 변경 내용이 포함됩니다.
주 복제본이 실패하여 장애 조치(failover)가 강제로 수행되는 경우 잠재적인 데이터 손실은 오류가 발생하기 전에 트랜잭션 로그가 보조 복제본으로 전송되지 않았는지 여부에 따라 달라집니다. 비동기-커밋 모드에서는 전송되지 않은 로그가 항상 발생할 수 있습니다. 동기-커밋 모드에서는 보조 데이터베이스가 동기화될 때까지만 가능합니다.
다음 표에는 장애 조치(failover)를 강제 적용하는 복제본의 특정 데이터베이스에 대한 데이터 손실 가능성이 요약되어 있습니다.
| 보조 복제본의 가용성 모드 | 데이터베이스가 동기화되었나요? | 데이터 손실이 가능합니까? |
|---|---|---|
| 동기식 커밋 | 예 | 아니오 |
| 동기화 커밋 | 아니오 | 예 |
| 비동기-커밋 | 아니오 | 예 |
보조 데이터베이스는 두 개의 복구 포크만 추적하므로 여러 강제 장애 조치(failover)를 수행하는 경우 이전 강제 장애 조치(failover)와 데이터 동기화를 시작한 보조 데이터베이스가 다시 시작되지 않을 수 있습니다. 이 경우 다시 시작될 수 없는 보조 데이터베이스는 가용성 그룹에서 제거되고, 올바른 시점으로 복원되고, 가용성 그룹에 다시 가입되어야 합니다. 복원은 여러 복구 포크에서 작동하지 않으므로 둘 이상의 강제 장애 조치(failover)를 수행한 후 로그 백업을 수행해야 합니다.
강제 쿼럼 설정 후 왜 강제 장애 조치(failover)가 필요한가?
WSFC 클러스터에서 강제 쿼럼이 설정된 후, 각 가용성 그룹에서 강제 장애 조치(failover)를 (데이터 손실이 발생할 수 있음) 수행해야 합니다. WSFC 클러스터 값의 실제 상태가 손실되었을 수 있으므로 강제 장애 조치(failover)가 필요합니다. 동기화되지 않은 보조 복제본이 다시 구성된 WSFC 클러스터에서 동기화된 것처럼 보일 가능성이 있기 때문에, 강제 쿼럼 후에는 일반적인 장애 조치를 방지하는 것이 필요합니다.
예를 들어 노드 A는 주 복제본을 호스트하고 노드 B와 노드 C는 각각 보조 복제본을 호스트하는 세 개의 노드에서 가용성 그룹을 호스트하는 WSFC 클러스터를 고려합니다. 로컬 보조 복제본이 동기화된 상태로 WSFC 클러스터에서 노드 C의 연결이 끊어집니다. 그러나 노드 A 및 노드 B는 정상 쿼럼을 유지하고 가용성 그룹은 온라인 상태로 유지됩니다. 노드 A에서 주 복제본은 업데이트를 계속 수락하고 노드 B에서는 보조 복제본이 주 복제본과 계속 동기화됩니다. 노드 C의 보조 복제본은 동기화되지 않고 주 복제본에 점점 뒤처집니다. 그러나 노드 C의 연결이 끊어지므로 복제본이 SYNCHRONIZED 상태로 잘못 유지됩니다.
쿼럼이 손실되고 노드 A에서 강제 적용된 경우 WSFC 클러스터의 가용성 그룹의 동기화 상태가 UNSYNCHRONIZED로 표시된 노드 C의 보조 복제본과 올바르게 일치해야 합니다. 그러나 노드 C에서 쿼럼이 강제로 적용되면 가용성 그룹의 동기화가 올바르지 않습니다. 클러스터의 동기화 상태는 노드 C가 연결이 끊어진 시점으로 되돌아가며, 노드 C의 보조 복제본이 잘못 SYNCHRONIZED 상태로 표시됩니다. 계획된 수동 장애 조치는 데이터의 안전을 보장하지만, 쿼럼이 강제로 적용된 후에는 가용성 그룹을 다시 온라인 상태로 전환하는 데 사용이 금지됩니다.
잠재적인 데이터 손실 추적
WSFC 클러스터에 정상 쿼럼이 있는 경우 데이터베이스의 현재 데이터 손실 가능성을 예측할 수 있습니다. 지정된 보조 복제본의 경우 현재 데이터 손실 가능성은 로컬 보조 데이터베이스가 해당 주 데이터베이스보다 뒤쳐지는 정도에 따라 달라집니다. 지연 시간은 시간에 따라 다르므로 비동기화된 보조 데이터베이스에 대한 잠재적인 데이터 손실을 주기적으로 추적하는 것이 좋습니다. 지연 추적에는 다음과 같이 각 주 데이터베이스 및 보조 데이터베이스에 대한 마지막 커밋 LSN 및 마지막 커밋 시간을 비교하는 작업이 포함됩니다.
주 복제본에 연결합니다.
last_commit_lsnsys.dm_hadr_database_replica_states 동적 관리 뷰의 (마지막으로 커밋된 트랜잭션의 LSN) 및last_commit_time(마지막 커밋 시간) 열을 쿼리합니다.각 주 데이터베이스와 각 보조 데이터베이스에 대해 반환되는 값을 비교합니다. 마지막 커밋 LSN 간의 차이는 지연의 양을 나타냅니다.
데이터베이스 또는 데이터베이스 집합의 지연 시간이 지정된 기간 동안 원하는 최대 지연 시간을 초과하는 경우 경고를 트리거할 수 있습니다. 예를 들어 각 주 데이터베이스에서 매 분마다 실행되는 작업에서 쿼리를 실행할 수 있습니다. 작업이 마지막으로 실행된 이후 주 데이터베이스와 보조 데이터베이스 간의 차이가
last_commit_timeRPO(복구 지점 목표)(예: 5분)를 초과하면 작업이 경고를 발생할 수 있습니다.
중요합니다
WSFC 클러스터에 쿼럼이 없거나 쿼럼이 강제로 적용된 경우, last_commit_lsn 및 last_commit_time는 NULL입니다. 쿼럼을 강제 적용한 후 데이터 손실을 방지할 수 있는 방법에 대한 자세한 내용은 가용성 그룹(SQL Server)의 강제 수동 장애 조치(failover) 수행에서 "쿼럼이 강제 적용된 후 데이터 손실을 방지하는 잠재적 방법"을 참조하세요.
잠재적인 데이터 손실 관리
장애 조치(failover)가 강제로 수행되면 모든 보조 데이터베이스가 일시 중단됩니다. 여기에는 예전의 기본 데이터베이스가 포함되며, 예전의 주 복제본이 온라인으로 돌아와 현재의 보조 복제본임을 확인한 후에 포함됩니다. 각 보조 복제본에서 일시 중지된 각 데이터베이스를 개별적으로 수동 재개해야 합니다.
이전 주 복제본을 사용할 수 있게 되면 데이터베이스가 손상되지 않은 것으로 가정하여 잠재적인 데이터 손실을 관리할 수 있습니다. 잠재적인 데이터 손실을 관리하는 데 사용할 수 있는 방법은 원래 주 복제본이 새 주 복제본에 연결되었는지 여부에 따라 달라집니다. 원래 주 복제본이 새 주 인스턴스에 액세스할 수 있다고 가정하면 다시 연결이 자동으로 투명하게 수행됩니다.
원래 주 복제본이 다시 연결되었습니다.
일반적으로 오류가 발생한 후 원래 주 복제본이 다시 시작되면 해당 파트너와 빠르게 다시 연결됩니다. 다시 연결할 때 원래 주 복제본은 보조 복제본이 됩니다. 해당 데이터베이스는 보조 데이터베이스가 되고 SUSPENDED 상태를 입력합니다. 새 보조 데이터베이스는 다시 시작하지 않는 한 롤백되지 않습니다.
그러나 일시 중단된 데이터베이스에 액세스할 수 없으므로 지정된 데이터베이스를 다시 시작하면 손실될 데이터를 평가하기 위해 검사할 수 없습니다. 따라서 보조 데이터베이스를 다시 시작하거나 제거할지 여부에 대한 결정은 다음과 같이 데이터 손실을 허용할지 여부에 따라 달라집니다.
데이터 손실이 허용되지 않는 경우 가용성 그룹에서 데이터베이스를 제거하여 복구해야 합니다.
이제 데이터베이스 관리자는 이전 주 데이터베이스를 복구하고 손실된 데이터를 복구할 수 있습니다. 그러나 이전 주 데이터베이스가 온라인 상태가 되면 현재 주 데이터베이스와는 다릅니다. 따라서 데이터베이스 관리자는 데이터베이스의 추가 차이를 방지하고 클라이언트 장애 조치(failover) 문제를 방지하기 위해 클라이언트에서 제거된 데이터베이스 또는 현재 주 데이터베이스에 액세스할 수 없도록 해야 합니다.
데이터 손실이 비즈니스 목표에 허용되는 경우 보조 데이터베이스를 다시 시작할 수 있습니다.
새 보조 데이터베이스를 다시 시작하면 데이터베이스 동기화의 첫 번째 단계로 롤백됩니다. 실패 시 송신 큐에서 대기 중인 로그 레코드가 있으면 커밋된 경우에도 해당 트랜잭션이 손실됩니다.
원래 주 복제본이 다시 연결되지 않았습니다.
원래 주 복제본이 네트워크를 통해 새 주 복제본에 다시 연결되지 않도록 일시적으로 방지할 수 있는 경우 원래 주 데이터베이스를 검사하여 다시 시작된 경우 손실될 데이터를 평가할 수 있습니다.
잠재적인 데이터 손실이 허용되는 경우
원래 주 복제본이 새 주 복제본에 다시 연결되도록 허용합니다. 다시 연결하면 새 보조 데이터베이스가 일시 중단됩니다. 데이터베이스에서 데이터 동기화를 시작하려면 다시 시작하면 됩니다. 새 보조 복제본은 해당 데이터베이스에 대한 원래 복구 포크를 삭제하여 이전 보조 복제본으로 전송되거나 받은 적이 없는 트랜잭션을 손실합니다.
데이터 손실이 허용되지 않는 경우
원래 주 데이터베이스에 일시 중단된 데이터베이스를 다시 시작하면 손실되는 중요한 데이터가 포함된 경우 가용성 그룹에서 데이터를 제거하여 원래 주 데이터베이스의 데이터를 유지할 수 있습니다. 이로 인해 데이터베이스가 RESTORING 상태가 됩니다. 이 시점에서 제거된 데이터베이스 로그의 꼬리를 백업하는 것이 좋습니다. 그런 다음 원래 주 데이터베이스에서 복구할 데이터를 내보내고 현재 주 데이터베이스로 가져와 현재 주 데이터베이스(이전 보조 데이터베이스)를 업데이트할 수 있습니다. 업데이트된 주 데이터베이스의 전체 데이터베이스 백업을 가능한 한 빨리 수행하는 것이 좋습니다.
그런 다음, 새 보조 복제본을 호스트하는 서버 인스턴스에서 RESTORE WITH NORECOVERY를 사용하여 이 백업(및 하나 이상의 후속 로그 백업)을 복원하여 일시 중단된 보조 데이터베이스를 삭제하고 새 보조 데이터베이스를 만들 수 있습니다. 해당 보조 데이터베이스가 다시 시작될 때까지 현재 주 데이터베이스의 추가 로그 백업을 지연하는 것이 좋습니다.
경고
보조 데이터베이스가 일시 중단이 된 동안 주 데이터베이스에서 트랜잭션 로그 잘림이 지연됩니다. 또한 일시 중지된 상태로 남아 있는 로컬 데이터베이스가 있으면 동기 커밋 보조 복제본의 동기화 상태가 정상으로 전환될 수 없습니다.
관련 작업
장애 조치(failover) 동작을 구성하려면
수동 장애 전환(failover)을 수행하려면
WSFC 쿼럼 구성을 구성하려면
관련 내용
또한 참조하십시오
AlwaysOn 가용성 그룹 개요(SQL Server)
가용성 모드(AlwaysOn 가용성 그룹)
Windows Server 장애 조치 클러스터링(WSFC)과 SQL Server
데이터베이스 미러링 또는 AlwaysOn 가용성 그룹에 대해 지원되지 않는 데이터베이스 간 트랜잭션(SQL Server)
장애 조치 클러스터 인스턴스에 대한 정책
SQL Server 가용성 그룹의 자동 장애 조치를 위한 유연한 장애 조치 정책