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

적용 대상:SQL Server

이 문서에서는 SQL Server에서 SQL Server Management Studio, Transact-SQL 또는 PowerShell을 사용하여 Always On 가용성 그룹에서 강제 장애 조치(failover)(데이터 손실 가능)를 수행하는 방법을 설명합니다. 강제 장애 조치(failover)는 계획된 수동 장애 조치(failover)를 수행할 수 없는 경우, 재해 복구 전용으로 의도된 수동 장애 조치(failover)의 한 형태입니다. 동기화되지 않은 보조 복제본(replica)으로 강제 장애 조치(failover)를 하는 경우 일부 데이터 손실이 발생할 수 있습니다. 따라서 가용성 그룹에 서비스를 즉시 복원해야 하고 데이터 손실 위험을 감수해야 하는 경우에만 장애 조치(failover)를 강제 적용하는 것이 좋습니다.

강제 장애 조치 후 가용성 그룹이 장애 조치된 대상은 새 기본 복제본이 됩니다. 나머지 보조 복제본(replica)에 있는 보조 데이터베이스는 일시 중단되기 때문에 수동으로 다시 시작해야만 합니다. 이전 주 복제본을 사용할 수 있게 되면 보조 역할로 전환되어 이전 주 데이터베이스가 보조 데이터베이스가 되고 상태로 전환 SUSPENDED 됩니다. 지정된 보조 데이터베이스를 다시 시작하기 전에 해당 데이터베이스에서 손실된 데이터를 복구할 수도 있습니다. 그러나, 보조 데이터베이스 중 하나라도 일시 중지되어 있는 동안 주 데이터베이스에서 트랜잭션 로그 잘림이 지연되게 됩니다.

다음과 같은 긴급 상황에서는 반드시 강제 장애 조치(failover)를 실행해야 합니다.

• WSFC 클러스터에서 쿼럼을 강제 적용한 후에는, 각 가용성 그룹에 대해 데이터 손실 가능성을 감수하고 강제 장애 조치를 수행해야 합니다. WSFC 클러스터 값의 실제 상태가 손실되었을 수 있기 때문에 강제 장애 조치(failover)가 필요한 것입니다. 그러나 강제 쿼럼을 강제 적용하기 전에 주 복제본이었던 복제본을 호스팅하고 있던 서버 인스턴스 또는 강제 쿼럼 전에 동기화된 보조 복제본에 대해 강제로 장애 조치(failover)할 수 있는 경우 데이터 손실을 방지할 수 있습니다. 자세한 내용은 이 문서의 뒷부분에 있는 쿼럼 강제 적용 후 데이터 손실을 방지하는 잠재적 방법을 참조하세요.

  중요한

  쿼럼이 강제 적용되지 않고 자연스러운 방법으로 복구되는 경우 가용성 복제본은 정상적인 복구를 거닐게 됩니다. 기본 복제본을 사용할 수 없는 상태로 쿼럼이 회복된 후에는, 동기화된 보조 복제본으로 계획된 수동 장애 조치를 수행할 수 있습니다.

  쿼럼 강제에 대한 자세한 내용은 쿼럼 강제를 통해 WSFC 재해 복구(SQL Serve)를 참조하세요. 쿼럼을 강제한 후 강제 장애 조치(failover)가 필요한 이유에 대한 자세한 내용은 장애 조치 및 장애 조치 모드(Always On 가용성 그룹)를 참조하세요.

• WSFC 클러스터에 정상 쿼럼이 있을 때 주 복제본을 사용할 수 없게 되면 역할이 SECONDARY 또는 RESOLVING 상태에 있는 모든 복제본에 장애 조치(failover)(데이터 손실이 발생할 수 있음)를 강제 적용할 수 있습니다. 가능한 경우, 기본 복제본이 손실되었을 때 동기화된 상태였던 동기 커밋 보조 복제본으로 강제 장애 조치를 실행합니다.

  팁

  WSFC 클러스터에 정상 상태의 쿼럼이 있을 때 동기화된 보조 복제본에서 강제 장애 조치(failover) 명령을 실행하면 해당 복제본이 실제로 예정된 수동 장애 조치(failover)를 수행합니다.

강제 장애 조치(failover)를 위한 필수 구성 요소 및 권장 사항 및 강제 장애 조치(failover)를 사용하여 치명적인 오류로부터 복구하는 예제 시나리오에 대한 자세한 내용은 예제 시나리오: 강제 장애 조치(failover)를 사용하여 치명적인 오류로부터 복구합니다. 이 문서의 뒷부분에서 참조하세요.

제한점

• 강제 장애 조치(failover)를 수행할 수 없는 유일한 경우는 WSFC(Windows Server 장애 조치(failover) 클러스터링) 클러스터에 쿼럼이 없는 경우입니다.

• 가용성 그룹의 강제 장애 조치(failover)를 하는 도중에 데이터 손실이 발생할 수 있습니다. 또한 강제 장애 조치(failover)를 시작할 때 기본 복제본(replica) 실행 중인 경우에도 클라이언트는 예전의 주 데이터베이스에 연결될 수 있습니다. 따라서 주 복제본이 더 이상 실행되지 않고 가용성 그룹의 데이터베이스에 대한 액세스를 복원하기 위해 데이터가 손실될 위험이 있는 경우에만 장애 조치(failover)를 강제 적용하는 것이 좋습니다.

• 보조 데이터베이스가 REVERTING 또는 INITIALIZING 상태에 있을 때, 강제 장애 조치(failover)를 수행하면 데이터베이스가 주 데이터베이스로 시작되지 않습니다. 데이터베이스가 상태에 있는 INITIALIZING 경우 데이터베이스 백업에서 누락된 로그 레코드를 적용하거나 데이터베이스를 처음부터 완전히 복원해야 합니다. 데이터베이스가 상태인 REVERTING 경우 백업에서 데이터베이스를 완전히 복원해야 합니다.

• 장애 조치 명령은 장애 조치 대상에서 해당 명령을 수락하는 즉시 반환됩니다. 데이터베이스 복구는 가용성 그룹의 장애 조치가 끝난 후 비동기로 수행됩니다.

• 가용성 그룹 내에서 여러 데이터베이스 간의 일관성이 장애 조치(failover) 시 유지되지 않을 수 있습니다.

  참고

  데이터베이스 간 트랜잭션 및 분산 트랜잭션 지원은 SQL Server 및 운영 체제 버전에 따라 달라집니다. 자세한 내용은 트랜잭션 - 가용성 그룹 및 데이터베이스 미러링을 참조하세요.

필수 조건

• WSFC 클러스터에 쿼럼이 있습니다. 클러스터에 쿼럼이 없는 경우 쿼럼 강제를 통해 WSFC 재해 복구(SQL Server)를 참조하세요.

• SECONDARY 또는 RESOLVING 상태에 있는 역할의 복제본을 호스트하는 서버 인스턴스에 연결할 수 있어야 합니다.

권장 사항

• 주 복제본이 계속 실행되는 동안에는 장애 조치(failover)를 강제로 수행하지 마세요.

• 가능하면 보조 데이터베이스가 NOT SYNCHRONIZED, SYNCHRONIZED, 또는 SYNCHRONIZING 상태에 있는 장애 조치 대상에만 장애 조치를 강제로 수행합니다. 보조 데이터베이스 INITIALIZING 가 또는 REVERTING 상태에 있을 때 강제 장애 조치(failover)가 미치는 영향에 대한 자세한 내용은 이 문서의 앞부분에 있는 제한 사항을 참조하세요.

• 일반적으로 주 데이터베이스를 기준으로 지정된 보조 데이터베이스의 대기 시간은 서로 다른 비동기 커밋 보조 복제본(replica)에서도 비슷해야 합니다. 그러나 장애 조치(failover)를 강제할 때 데이터 손실은 심각한 문제가 될 수 있습니다. 따라서 서로 다른 보조 복제본에서 데이터베이스 복사본의 상대적 대기 시간을 결정하는 데 시간이 걸린다는 사실을 고려해야 합니다. 지정된 보조 데이터베이스에서 어떤 복사본의 지연 시간이 가장 적은지를 확인하기 위해서는 해당 복사본의 로그 종료 LSN을 비교합니다. 로그 종료 LSN이 높을수록 대기 시간이 줄어듭니다.

  팁

  로그 끝 LSN을 비교하려면 차례로 각 온라인 보조 복제본에 연결하고, 각 로컬 보조 데이터베이스의 sys.dm_hadr_database_replica_states 값을 쿼리합니다. 그런 다음 각 데이터베이스의 여러 다른 복사본의 로그 끝 LSN을 비교합니다. 다른 데이터베이스는 다른 보조 복제본에서 가장 높은 LSN을 가질 수 있습니다. 이 경우 가장 적절한 장애 조치(failover) 대상은 서로 다른 데이터베이스의 데이터에 두는 상대적 중요도에 따라 달라집니다. 즉, 이러한 데이터베이스 중 데이터 손실 가능성을 최소화고자 하는 데이터베이스는 무엇인가요?

• 클라이언트가 원래 주 서버에 연결할 수 있는 경우, 강제 장애 조치(failover)를 수행하면 분리된 상태(split-brain) 동작이 발생할 위험이 있습니다. 장애 조치(failover)를 강제로 적용하기 이전에 클라이언트가 원래 기본 복제본(replica)에 액세스하지 못하도록 차단하는 것을 권장해 드립니다. 그렇지 않으면 장애 조치(failover)가 강제로 실행된 후 원래 주 데이터베이스와 현재 주 데이터베이스가 서로 독립적으로 업데이트될 수 있습니다.

쿼럼 강제 적용 후 데이터 손실을 방지하는 잠재적 방법

쿼럼이 손실된 후 일부 오류 조건에서 다음과 같이 데이터 손실을 방지할 수 있습니다.

• 원래 기본 복제본이 온라인 상태가 된 경우

  쿼럼이 손실되고 강제로 WSFC 쿼럼이 가용성 그룹의 주 복제본을 호스팅하는 클러스터 노드를 복원하는 경우, 이 가용성 그룹에 대한 데이터 손실을 방지할 수 있습니다. 기본 복제본에 연결하고 데이터 손실을 허용하는 강제 장애 조치(FAILOVER_ALLOW_DATA_LOSS)를 수행합니다. 이러면 기본 복제본(replica)은 다시 온라인 상태가 됩니다. 원래 주 복제본에 대한 강제 장애 조치(failover)를 수행하므로 데이터가 손실되지 않습니다.

• 동기화된 동기-커밋 보조 복제본이 온라인 상태가 된 경우

  쿼럼이 손실되고 WSFC 쿼럼 강제 적용이 가용성 그룹에 대해 동기화된 보조 복제본(replica) 호스팅하는 클러스터 노드를 복원하는 경우 이 가용성 그룹에 대한 데이터 손실을 방지할 수 있어야 합니다. 쿼럼이 손실되었을 때 복원된 노드가 위로 올라온 경우 is_failover_ready 동적 관리 뷰의 열을 쿼리하여 지정된 데이터베이스에서 데이터 손실이 발생할 수 있는지 여부를 확인할 수 있습니다. 예를 들어 이름이 지정된sql108w2k8r22 서버 인스턴스의 경우 다음 쿼리를 실행합니다:

  SELECT *
  FROM sys.dm_hadr_database_replica_cluster_states
  WHERE replica_id = (
      SELECT replica_id
      FROM sys.availability_replicas
      WHERE replica_server_name = 'sql108w2k8r22'
  );
  

  주의

  쿼럼이 손실 is_failover_ready 될 때 복원된 노드가 작동하지 않는 경우 주 복제본이 오프라인 상태가 되었을 때 클러스터의 실제 상태가 반영되지 않을 수 있습니다. 따라서 is_failover_ready 이 값은 실패 시 호스트 노드에만 적합합니다. 자세한 내용은 장애 조치 및 장애 조치 모드(Always On 가용성 그룹)에서 "쿼럼 강제 후 강제 장애 조치가 필요한 이유"를 참조하세요.

  is_failover_ready = 1인 경우, 데이터베이스가 클러스터에서 동기화된 것으로 표시되고 장애 조치(failover)가 준비되었음을 나타냅니다. 지정된 보조 복제본의 모든 데이터베이스에서 is_failover_ready = 1 있다면, 이 보조 복제본에 대해 데이터 손실 없이 강제 장애 조치(FORCE_FAILOVER_ALLOW_DATA_LOSS)를 수행할 수 있습니다. 동기화된 보조 복제본(replica)은 모든 데이터가 그대로 유지된 상태인 채로 주 역할, 즉 새로운 기본 복제본으로서의 온라인 상태가 됩니다.

  조건 is_failover_ready = 0가 충족되면, 데이터베이스는 클러스터에서 동기화된 것으로 표시되지 않으며 계획된 수동 장애 조치를 수행할 준비가 되지 않습니다. 호스트 보조 복제본으로 강제 장애 조치 시 이 데이터베이스에서 데이터가 손실될 수 있습니다.

  참고

  보조 복제본으로 강제 장애 조치(failover)하는 경우 데이터 손실의 양은 장애 조치(failover) 대상이 주 복제본보다 뒤쳐지는 정도에 따라 달라집니다. 아쉽게도 WSFC 클러스터에 쿼럼이 없거나 쿼럼이 강제로 적용된 경우 잠재적인 데이터 손실의 양을 평가할 수 없습니다. 그러나 WSFC 클러스터가 정상 쿼럼을 회복하면 잠재적인 데이터 손실 추적을 시작할 수 있습니다. 자세한 내용은 장애 조치 및 장애 조치 모드(Always On 가용성 그룹)에서 "잠재적인 데이터 손실 추적"을 참조하세요.

사용 권한

ALTER AVAILABILITY GROUP 가용성 그룹, 사용 권한, CONTROL AVAILABILITY GROUPALTER ANY AVAILABILITY GROUP 사용 권한 또는 CONTROL SERVER 사용 권한에 대한 권한이 필요합니다.

SQL Server Management Studio 사용

1. 개체 탐색기에서 가용성 그룹의 SECONDARY 또는 RESOLVING 상태에 있는 복제본을 호스팅하는 서버 인스턴스에 연결한 후, 서버 트리를 확장합니다. 이 가용성 그룹은 장애 조치(failover)되어야 합니다.

2. Always On 고가용성 노드 및 가용성 그룹 노드를 확장합니다.

3. 장애 조치할 가용성 그룹을 마우스 오른쪽 단추로 클릭하고 장애 조치(Failover) 명령을 선택합니다.

4. 이것은 장애 조치 가용성 그룹 마법사를 시작합니다. 자세한 내용은 Fail Over 가용성 그룹 마법사 사용(SQL Server Management Studio)을 참조하세요.

5. 가용성 그룹을 강제로 장애 조치 전환을 한 후에 필요한 후속 단계를 완료합니다. 자세한 내용은 이 문서의 뒷부분에 있는 후속 작업: 강제 장애 조치(Failover) 후의 필수 작업을 참조하세요.

Transact-SQL 사용

1. 역할이 SECONDARY 또는 RESOLVING 상태인 복제본을 호스트하는 서버 인스턴스에 연결합니다. 이 복제본은 장애 조치(failover)가 필요한 가용성 그룹에 속해 있습니다.

2. 다음과 같이 ALTER AVAILABILITY GROUP 문을 사용합니다. 여기서 group_name 가용성 그룹의 이름입니다.

   ALTER AVAILABILITY GROUP <group_name> FORCE_FAILOVER_ALLOW_DATA_LOSS;

   다음 예시에서는 AccountsAG 가용성 그룹이 로컬 보조 복제본으로 강제로 장애 조치되도록 합니다.

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

3. 가용성 그룹을 강제로 장애 조치 전환을 한 후에 필요한 후속 단계를 완료합니다. 자세한 내용은 이 기사의 뒷부분에 강제 장애 조치(failover) 후 필수 작업을 참조하세요.

PowerShell 사용

1. 디렉터리(cd)를 장애 조치가 필요한 가용성 그룹의 SECONDARY 또는 RESOLVING 상태의 역할이 있는 복제본을 호스팅하는 서버 인스턴스로 변경합니다.

2. 다음 형식 중 하나로 Switch-SqlAvailabilityGroup cmdlet과 AllowDataLoss 매개 변수를 사용합니다.

   • -AllowDataLoss

     기본적으로 -AllowDataLoss 매개 변수는 Switch-SqlAvailabilityGroup 강제 장애 조치(failover)로 인해 커밋되지 않은 트랜잭션이 손실될 수 있음을 상기시키고 확인을 요청하라는 메시지를 표시합니다. 계속하려면 ;를 입력 Y하여 작업을 취소하려면 .를 입력합니다 N.

     다음 예시에서는 MyAg이라는 서버 인스턴스의 보조 복제본에 대한 가용성 그룹SecondaryServer\InstanceName의 강제 장애 조치(failover)(데이터가 손실의 가능성이 있음)를 실행합니다. 이 작업을 확인하라는 메시지가 표시됩니다.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss
     

   • -AllowDataLoss-Force

     확인 없이 강제 장애 조치를 시작하려면 -AllowDataLoss 매개 변수와 -Force 매개 변수를 모두 지정해야 합니다. 이것은 스크립트에 명령을 포함하고 사용자의 개입이 없이도 실행하려는 경우에 유용합니다. 그러나 강제 장애 조치(failover)로 인해 가용성 그룹에 참여하는 데이터베이스의 데이터가 손실될 수 있으므로 이 옵션을 주의해서 사용합니다 -Force .

     다음 예시에서는 MyAg 이라는 서버 인스턴스로 가용성 그룹 SecondaryServer\InstanceName의 강제 장애 조치(failover)(데이터가 손실될 수 있음)를 수행합니다. 이 -Force 옵션은 이 작업에 대한 확인을 제거합니다.

     Switch-SqlAvailabilityGroup `
        -Path SQLSERVER:\Sql\SecondaryServer\InstanceName\AvailabilityGroups\MyAg `
        -AllowDataLoss -Force
     

   참고

   cmdlet의 구문을 보려면 SQL Server PowerShell 환경에서 Get-Help cmdlet을 사용하십시오. 자세한 내용은 SQL Server PowerShell 도움말을 참조하세요.

3. 가용성 그룹을 강제로 장애 조치 전환을 한 후에 필요한 후속 단계를 완료합니다. 자세한 내용은 이 문서의 뒷부분에 있는 후속 작업: 강제 장애 조치(Failover) 후의 필수 작업을 참조하세요.

SQL Server PowerShell 공급자 설정 및 사용

• SQL Server PowerShell 공급자

후속 작업: 강제 페일오버 후 필수 작업

1. 강제 장애 조치 후에는 장애 조치된 보조 복제본이 새 기본 복제본이 됩니다. 그러나 클라이언트에서 해당 가용성 복제본(replica) 액세스할 수 있게 하려면 다음과 같이 WSFC 쿼럼을 다시 만들거나 가용성 그룹의 가용성 모드 구성을 조정해야 할 수도 있습니다.

   • 자동 장애 조치 설정 외부에서 장애 조치를 수행한 경우: 새로운 가용성 그룹 구성을 반영하도록 WSFC 노드의 쿼럼 투표를 조정하세요. 대상 보조 복제본을 호스트하는 WSFC 노드에 WSFC 쿼럼 투표가 없는 경우 WSFC 쿼럼을 강제로 적용해야 할 수 있습니다.

     자동 장애 조치(failover) 집합은 두 개의 가용성 복제본(예전의 기본 복제본 포함)이 자동 장애 조치(failover)를 사용하는 동기-커밋 모드로 만들어진 경우에만 존재합니다.

     쿼럼 투표를 조정하려면

     • 클러스터 쿼럼 NodeWeight 설정 보기
     • 클러스터 쿼럼 노드 가중치 설정 구성
     • 쿼럼 없이 WSFC 클러스터를 강제로 시작하기

   • 동기-커밋 장애 조치 집합 외부에서 장애 조치가 발생한 경우: 원하는 동기 커밋 및 자동 장애 조치 구성을 반영할 수 있도록 새 기본 복제본과 나머지 보조 복제본에서 가용성 모드와 장애 조치 모드를 조정할 것을 권장합니다.

     참고

     동기-커밋 장애 조치(failover) 집합은 현재 기본 복제본이 동기-커밋 모드로 설정된 경우에만 존재합니다.

     가용성 모드 및 장애 조치(failover) 모드를 변경하기 위하여

     • Always On 가용성 그룹 내에서 복제본의 가용성 모드 변경
     • Always On 가용성 그룹 내의 복사본의 장애 조치 모드를 변경

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

   보조 데이터베이스가 다시 시작될 때 해당 주 데이터베이스와 데이터 동기화를 시작합니다. 보조 데이터베이스는 새 주 데이터베이스에서 커밋되지 않은 로그 레코드를 롤백합니다. 따라서 장애 조치(failover) 후 주 데이터베이스의 데이터 손실이 우려되는 경우 동기 커밋 보조 데이터베이스 중 하나에서 일시 중단된 데이터베이스에 데이터베이스 스냅샷을 만들려고 시도해야 합니다.

   중요한

   보조 데이터베이스가 일시 중단이 된 동안 주 데이터베이스에서 트랜잭션 로그 잘림이 지연됩니다. 로컬 데이터베이스가 일시 중단된 상태로 유지되는 한, 동기 커밋 보조 복제본의 동기화 상태는 HEALTHY으로 전환할 수 없습니다.

   데이터베이스 스냅샷을 만들려면

   • 데이터베이스 스냅샷 만들기(Transact-SQL)

   가용성 데이터베이스를 재개하려면

   • 가용성 데이터베이스를 재개하기

   주의

   모든 보조 데이터베이스를 다시 시작한 후, 그룹 장애 조치를 다시 시도하기 전에, 다음 장애 조치 대상의 모든 보조 데이터베이스가 SYNCHRONIZING 상태로 전환될 때까지 기다립니다. 아직 SYNCHRONIZING데이터베이스가 없으면 해당 데이터베이스가 주 데이터베이스로 온라인 상태가 되지 않으며 데이터베이스에 대한 데이터 동기화를 다시 설정하려면 트랜잭션 로그를 복원하거나, 전체 데이터베이스 백업을 복원하거나, 이전 주 복제본으로 장애 복구해야 할 수 있습니다.

3. 실패한 가용성 복제본이 가용성 복제본으로 반환되지 않거나 너무 늦게 반환될 경우, 새 주 데이터베이스에서 트랜잭션 로그 잘림을 지연시킬 수 없다는 것을 고려하여 로그 파일의 디스크 공간이 부족하지 않도록 가용성 그룹에서 실패한 복제본을 제거하는 것이 좋습니다.

   보조 복제본을 제거하려면

   • 가용성 그룹에서 보조 복제본 제거(SQL Server)

4. 하나 이상의 추가 강제 장애 조치를 수행하는 경우, 시리즈의 각 강제 장애 조치 후에 로그 백업을 실행하십시오. 그 이유에 대한 자세한 내용은 장애 조치 및 장애 조치 모드(Always On 가용성 그룹)의 "강제 수동 장애 조치(데이터 손실 가능성 있음)" 섹션에 있는 "강제 장애 조치의 위험"을 참조하세요.

   로그 백업을 실행하기 위하여

   • 트랜잭션 로그 백업

예제 시나리오: 강제 장애 조치(failover)를 사용하여 치명적인 오류로부터 복구

기본 복제본이 실패하고 사용할 수 있는 동기화된 보조 복제본이 없는 경우 가용성 그룹을 강제 장애 조치(failover)하는 것이 적절한 대처 방법이 될 수 있습니다. 장애 조치(failover)를 강제 적용하는 적합성은 (1) 주 복제본이 SLA(서비스 수준 계약)가 용인하는 것보다 오랫동안 오프라인 상태가 될 것으로 예상하는지 여부 및 (2) 주 데이터베이스를 신속하게 사용할 수 있도록 하기 위해 잠재적인 데이터 손실을 감수할 의향이 있는지 여부에 따라 달라집니다. 가용성 그룹에 강제 장애 조치(failover)가 필요하다고 결정한 경우 실제 강제 장애 조치(failover)는 여러 개의 프로세스 중 한 단계에 불과합니다.

강제 장애 조치(failover)를 사용하여 치명적인 오류를 복구하는 데 필요한 단계를 설명하기 위해 이 문서에서는 가능한 재해 복구 시나리오 중 하나를 제공합니다. 예시 시나리오에서는 원래 토폴로지의 가용성 그룹이 기본 복제본(replica) 포함하여 동기 커밋 가용성 복제본(replica) 3개를 호스팅하는 주 데이터 센터와 두 개의 비동기 커밋 보조 복제본(replica) 호스팅하는 원격 데이터 센터로 만들어진 가용성 그룹을 고려합니다. 다음 그림에서는 이 예시 가용성 그룹의 원래 토폴로지를 보여 줍니다. 가용성 그룹은 기본 데이터 센터(노드 01, 노드 02 및 노드 03)에 3개의 노드가 있고 원격 데이터 센터(노드 04 및 노드 05)에 2개의 노드가 있는 다중 서브넷 WSFC 클러스터에서 호스팅됩니다.

기본 데이터 센터가 예기치 않게 종료됩니다. 3개의 가용성 복제본이 오프라인 상태로 전환이 되며, 해당 데이터베이스를 사용할 수 없게 됩니다. 다음 그림에서는 가용성 그룹의 토폴로지에서 이 오류가 미치는 영향을 보여 줍니다.

데이터베이스 관리자(DBA)는 원격에 위치한 비동기 커밋 방식의 보조 복제본 중 하나로 가용성 그룹을 강제로 장애 조치(failover)하는 것이 최선의 대응이라고 판단합니다. 이 예시에서는 가용성 그룹을 원격 복제본으로 강제 장애 조치하여, 결과적으로 가용성 그룹을 원래의 토폴로지로 되돌릴 때 수행하는 일반적인 단계를 보여 줍니다.

여기에서 제시된 실패 응답은 다음 두 단계로 구성됩니다.

• 주 데이터 센터의 치명적인 오류에 대응
• 가용성 그룹을 원래 토폴로지로 반환

주 데이터 센터의 치명적인 오류에 대응

다음 그림에서는 기본 데이터 센터에서 치명적인 오류에 대응하여 원격 데이터 센터에서 실행되고 있는 일련의 작업을 보여주고 있습니다.

이 그림의 단계는 다음 단계를 나타냅니다.

가용성 그룹을 원래 토폴로지로 반환

다음 그림에서는 기본 데이터 센터가 다시 온라인 상태가 되고 난 후에 가용성 그룹을 원래 토폴로지로 반환하고 WSFC 노드가 WSFC 클러스터와의 통신을 다시 설정하는 일련의 작업을 보여 줍니다.

이 그림의 단계는 다음 단계를 나타냅니다.

관련 작업

쿼럼 투표 조정

• 클러스터 쿼럼 NodeWeight 설정 보기
• 클러스터 쿼럼 노드 가중치 설정 구성
• 쿼럼 없이 WSFC 클러스터를 강제로 시작하기

계획된 수동 장애 전환

• Always On 가용성 그룹의 계획된 수동 장애 조치 수행(SQL Server)
• 장애 조치 가용성 그룹 마법사 사용(SQL Server Management Studio)

Troubleshoot

• Always On 가용성 그룹 구성 문제 해결(SQL Server)
• 실패한 파일 추가 작업 문제 해결(Always On 가용성 그룹)

관련 콘텐츠

• SQL Server Always On 팀 블로그: 공식 SQL Server Always On 팀 블로그
• CSS SQL Server 엔지니어 블로그
• 고가용성 및 재해 복구를 위한 Microsoft SQL Server Always On 솔루션 가이드
• Always On 가용성 그룹은 무엇인가요?
• Always On 가용성 그룹의 가용성 모드 간 차이점
• 장애 조치 및 모드 (Failover 및 장애 조치 모드, Always On 가용성 그룹)
• Always On 가용성 그룹 내의 복제본에 대한 클라이언트 연결 유형
• Always On 가용성 그룹을 모니터링하는 도구
• SQL Server의 Windows Server 장애 조치(Failover) 클러스터링