강제 쿼럼을 통해 WSFC 재해 복구(SQL Server)

  • 아티클

적용 대상:SQL Server

쿼럼 실패는 일반적으로 시스템 관련 재해, 지속적인 통신 오류 또는 WSFC 클러스터의 여러 노드를 잘못 구성하여 발생합니다. 쿼럼 실패를 복구하려면 수동 개입이 필요합니다.

시작하기 전에

필수 조건

쿼럼 강제 절차에서는 쿼럼 실패 전에 정상 쿼럼이 있었다고 가정합니다.

Warning

사용자는 Windows Server 장애 조치(failover) 클러스터링, WSFC 쿼럼 모델, SQL Server 및 환경 배포 구성의 개념과 상호 작용에 대해 잘 알고 있어야 합니다.

자세한 내용은 SQL Server의 WSFC(Windows Server 장애 조치(failover) 클러스터링), WSFC 쿼럼 모드 및 투표 구성(SQL Server)을 참조하세요.

보안

사용자는 WSFC 클러스터의 각 노드에 대한 로컬 Administrators 그룹의 멤버인 도메인 계정이어야 합니다.

강제 쿼럼 절차를 통해 WSFC 재해 복구

쿼럼이 실패하면 WSFC 클러스터의 모든 클러스터형 서비스, SQL Server 인스턴스 및 Always On 가용성 그룹이 오프라인으로 설정됩니다. 클러스터가 구성된 대로 노드 수준 내결함성을 보장할 수 없기 때문입니다. 쿼럼 실패는 WSFC 클러스터의 정상 투표 노드가 더 이상 쿼럼 모델을 충족하지 않음을 의미합니다. 완전히 실패한 노드도 있을 것이고, 쿼럼과 통신하는 기능이 손실된 경우를 제외하고 단지 WSFC 서비스만 종료했을 뿐 정상인 노드도 있을 것입니다.

WSFC 클러스터를 다시 온라인 상태로 전환하려면 기존 구성에서 쿼럼 실패의 근본 원인을 해결하고 필요한 경우 영향을 받은 데이터베이스를 복구해야 하며 실패에서 살아남은 클러스터 토폴로지를 반영하도록 WSFC 클러스터의 나머지 노드를 다시 구성해야 합니다.

클러스터를 오프라인 상태로 전환한 보안 장치를 무시하기 위해 WSFC 클러스터 노드에서 강제 쿼럼 절차를 수행할 수 있습니다. 이렇게 하면 클러스터에 쿼럼 투표 검사를 일시 중단하도록 효과적으로 지시하고, 클러스터의 노드에서 WSFC 클러스터 리소스 및 SQL Server를 다시 온라인으로 전환할 수 있습니다.

이 유형의 재해 복구 프로세스에는 다음 단계가 포함되어야 합니다.

쿼럼 실패에서 복구하려면

  1. 실패의 범위 확인. 응답하지 않는 가용성 그룹 또는 SQL Server 인스턴스를 확인합니다. 어떤 클러스터 노드가 온라인이고 재해 후 사용할 수 있는지 확인하고, Windows 이벤트 로그 및 SQL Server 시스템 로그를 검사합니다. 실제로는 나중에 분석할 수 있도록 포렌식 데이터 및 시스템 로그를 보존해야 합니다.

    팁

    SQL Server의 응답하는 인스턴스에서 sys.dm_hadr_availability_group_states DMV(동적 관리 뷰)를 쿼리하여 로컬 서버 인스턴스에서 가용성 복제본을 소유하는 가용성 그룹의 상태에 대한 정보를 얻을 수 있습니다.

  2. 단일 노드에서 강제 쿼럼을 수행하여 WSFC 클러스터 시작. WSFC 클러스터 서비스가 종료된 노드 이외의 노드 중에서 구성 요소 오류 수가 가장 적은 노드를 파악합니다. 이 노드가 대부분의 다른 노드와 통신할 수 있는지 확인합니다.

    이 노드에서 쿼럼 강제 절차를 사용하여 수동으로 클러스터를 온라인으로 전환합니다. 잠재적 데이터 손실을 최소화할 수 있도록, 가용성 그룹 주 복제본을 마지막으로 호스팅한 노드를 선택합니다.

    자세한 내용은 쿼럼 없이 WSFC 클러스터 강제 시작을 참조하세요.

    참고

    쿼럼 강제 설정은 클러스터 전체에 영향을 미쳐 논리 WSFC 클러스터가 과반수 득표를 달성하고 자동으로 일반 작업 쿼럼 모드로 전환될 때까지 쿼럼 검사를 차단합니다.

  3. 각 정상 노드에서 WSFC 서비스를 한 번에 하나씩 정상적으로 시작합니다. 다른 노드에서 클러스터 서비스를 시작할 때에는 쿼럼 강제 옵션을 지정할 필요가 없습니다.

    각 노드의 WSFC 서비스는 온라인으로 전환되면 다른 정상 노드와 협상하여 새 클러스터 구성 상태를 동기화합니다. 클러스터의 마지막으로 알려진 상태를 확인할 때 경합 상태가 발생하지 않도록 한 번에 한 노드에서 이 작업을 수행해야 합니다.

    Warning

    시작하는 각 노드가 다른 새 온라인 노드와 통신할 수 있어야 합니다. 다른 노드에서 WSFC 서비스를 사용하지 않도록 설정하는 것이 좋습니다. 그렇지 않으면 쿼럼 노드 집합이 둘 이상 만들어져 분리 장애(split-brain) 시나리오가 발생할 수 있습니다. 1단계의 결과가 정확하다면 이 문제가 발생하지 않습니다.

  4. 새 쿼럼 모드 및 노드 투표 구성 적용. 쿼럼 강제가 클러스터의 모든 노드를 성공적으로 다시 시작하고 쿼럼 실패의 근본 원인을 수정했으면 원래 쿼럼 모드 및 노드 투표 구성을 변경할 필요가 없습니다.

    그렇지 않은 경우에는 새로 복구한 클러스터 노드와 가용성 복제본 토폴로지를 평가하여 각 노드의 쿼럼 모드 및 투표 수 할당을 적절히 변경해야 합니다. 복구되지 않은 노드는 오프라인으로 설정하거나 노드 투표를 0으로 설정해야 합니다.

    팁

    현재 클러스터의 노드 및 SQL Server 인스턴스가 일반 작업으로 복원된 것처럼 보일 수 있습니다. 정상 상태의 쿼럼은 아직 없을 수도 있습니다. 장애 조치(failover) 클러스터 관리자, SQL Server Management Studio의 Always On 대시보드 또는 적절한 DMV를 사용하여 쿼럼이 복원되었는지 확인합니다.

  5. 필요한 대로 가용성 그룹 데이터베이스 복제본을 복구합니다. 비가용성 그룹 데이터베이스는 일반 SQL Server 시작 프로세스에서 자체적으로 복구되고 다시 온라인으로 전환됩니다.

    주 복제본, 동기 보조 복제본, 비동기 보조 복제본의 순서로 가용성 그룹 복제본을 다시 온라인 상태로 전환하여 데이터 손실 위험 및 복구 시간을 최소화할 수 있습니다.

참고

쿼럼 강제를 사용한 후에는 데이터 손실이 발생할 수 있는 강제 장애 조치(failover)를 수행하여 가용성 그룹을 다시 온라인 상태로 전환해야 합니다. 자세한 내용은 가용성 그룹의 계획된 강제 장애 조치(failover) 수행(SQL Server)을 참조하세요.

  1. 실패한 구성 요소 복구 또는 교체 후 클러스터에 대해 유효성 검사 다시 수행. 이제 초기 재해 및 쿼럼 실패에서 복구했으므로 실패한 노드를 복구 또는 교체하고 관련 WSFC 및 Always On 구성을 적절히 조정해야 합니다. 여기에는 가용성 그룹 복제본을 삭제하고, 노드를 클러스터에서 제거하고, 노드에서 소프트웨어를 정리하고 다시 설치하는 작업이 포함될 수 있습니다.

    실패한 모든 가용성 복제본을 복구하거나 제거해야 합니다. SQL Server는 가용성 복제본의 마지막으로 알려진 가장 오래된 시점 이후의 트랜잭션 로그를 자르지 않습니다. 실패한 복제본을 복구하거나 가용성 그룹에서 제거하지 않으면 트랜잭션 로그 크기가 계속 증가하여 다른 복제본의 트랜잭션 로그 공간이 부족해질 수 있습니다.

    참고

    WSFC 클러스터에 가용성 그룹 수신기가 있을 때 WSFC 구성 유효성 검사 마법사를 실행하면 마법사에서 다음과 같은 잘못된 경고 메시지를 생성합니다.

    “네트워크 이름 'Name:<network_name>'의 RegisterAllProviderIP 속성이 1로 설정되어 있습니다. 현재 클러스터 구성에서는 이 값을 0으로 설정해야 합니다.”

    이 메시지는 무시하세요.

  2. 필요한 대로 4단계를 반복합니다. 목표는 정상 작업에 적합한 수준의 내결함성 및 고가용성을 다시 설정하는 것입니다.

  3. RPO/RTO 분석을 수행합니다. SQL Server 시스템 로그, 데이터베이스 타임스탬프 및 Windows 이벤트 로그를 분석하여 실패의 근본 원인을 확인하고 실제 복구 지점 및 복구 시간 환경을 문서화해야 합니다.

관련 작업

관련 내용

참고 항목

SQL Server의 WSFC(Windows Server 장애 조치(Failover) 클러스터링)