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

적용 대상:SQL Server

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

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

Important

보조 데이터베이스가 다시 시작될 때까지 주 데이터베이스와 데이터 동기화는 발생하지 않습니다. 보조 데이터베이스를 재개 방법에 관한 자세한 내용은 이 문서의 뒷부분에 나와 있는 강제 장애 조치(failover) 후의 후속 작업: 필수 작업을 참조해 주세요.

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

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

  Important

  강제로 하는 것 대신에 자연스러운 방법으로 쿼럼을 되찾는 경우 가용성 복제본(replica) 정상적인 복구를 하게 됩니다. 쿼럼을 되찾은 후에도 주 복제본(replica) 계속 사용할 수 없는 경우 동기화된 보조 복제본(replica) 계획된 수동 장애 조치(failover)를 실행할 수 있습니다.

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

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

  팁

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

참고 항목

강제 장애 조치(failover)를 위한 필수 조건 및 권장 사항에 대한 자세한 내용과 강제 장애 조치(failover)를 사용하여 치명적인 오류에서 복구하는 예제 시나리오는 이 항목의 뒷부분에 나오는 예제 시나리오: 강제 장애 조치(Failover)를 사용하여 치명적인 오류 복구를 참조하세요.

제한 사항

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

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

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

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

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

  참고

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

필수 조건

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

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

권장 사항

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

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

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

  팁

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

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

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

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

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

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

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

  쿼럼이 손실되고 WSFC 쿼럼 강제 적용이 가용성 그룹에 대해 동기화된 보조 복제본(replica) 호스트하는 클러스터 노드를 복원하는 경우 이 가용성 그룹에 대한 데이터 손실을 방지할 수 있어야 합니다. 쿼럼이 손실된 시점에 복원된 노드가 작동 중이었던 경우 sys.dm_hadr_database_복제본(replica)_cluster_states 동적 관리 뷰의 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')  
  

  주의

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

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

  is_failover_ready = 0이면 데이터베이스가 클러스터에서 동기화된 것으로 표시되지 않으며 계획된 수동 장애 조치(failover)를 실행할 준비도 되지 않은 것입니다. 호스트 보조 복제본(replica) 강제로 장애 조치(failover)를 적용하는 경우 이 데이터베이스에서는 데이터가 손실되게 됩니다.

  참고 항목

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

사용 권한

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

SQL Server Management Studio 사용

강제 장애 조치(failover)를 하기 위하여(데이터가 손실의 가능성이 있음)

1. 개체 탐색기에서 장애 조치를 해야 할 가용성 그룹에서 역할이 SECONDARY 또는 RESOVLING 상태인 복제본을 호스팅하는 서버 인스턴스에 연결하고 서버 트리를 확장합니다.

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

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

4. 그러면 가용성 그룹 장애 조치 마법사가 시작됩니다. 자세한 내용은 가용성 그룹 장애 조치(failover) 마법사 사용(SQL Server Management Studio)을 참조하세요.

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

Transact-SQL 사용

강제 장애 조치(failover)를 하기 위하여(데이터가 손실의 가능성이 있음)

1. 장애 조치를 해야 하는 가용성 그룹의 SECONDARY 또는 RESOLVING 상태에 있는 복제본(replica) 호스팅하는 서버 인스턴스에 연결합니다.

2. 다음과 같은 ALTER AVAILABILITY GROUP 문을 사용합니다.

   ALTER AVAILABILITY GROUP group_name FORCE_FAILOVER_ALLOW_DATA_LOSS

   여기에서 group_name은 가용성 그룹의 이름입니다.

   다음 예제에서는 AccountsAG가용성 그룹이 로컬 복제본으로 장애 조치(Failover)를 강제로 하도록 해야만 합니다.

   ALTER AVAILABILITY GROUP AccountsAG FORCE_FAILOVER_ALLOW_DATA_LOSS;  
   

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

PowerShell 사용

강제 장애 조치(failover)를 하기 위하여(데이터가 손실의 가능성이 있음)

1. 디렉터리(cd)를 장애 조치(failover)를 해야 하는 가용성 그룹의 SECONDARY 또는 RESOLVING 상태에 있는 복제본(replica) 호스트하는 서버 인스턴스로 변경합니다.

2. Switch-SqlAvailabilityGroup cmdlet을 다음 형식 중 하나로 된 AllowDataLoss 매개 변수와 함께 사용합니다.

   • -AllowDataLoss

     기본적으로 -AllowDataLoss 매개 변수 때문에 Switch-SqlAvailabilityGroup은 강제 장에 조치를 실행하게 되면 커밋되지 않은 트랜잭션이 손실될 수 있음을 알리고 확인을 요청하라는 메시지를 표시합니다. 계속하려면 Y;를 입력하고, 작업을 취소하려면 N을 입력해 주세요.

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

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

   • -AllowDataLoss-Force

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

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

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

   참고 항목

   cmdlet의 구문을 보려면 PowerShell 환경에서 Get-Help SQL Server cmdlet을 사용합니다. 자세한 내용은 Get Help SQL Server PowerShell을 참조하세요.

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

SQL Server PowerShell 공급자를 설정하고 사용하려면

• SQL Server PowerShell 공급자

후속 작업: 강제 장애 조치(Failover)를 한 후에 필수 작업

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

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

     참고 항목

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

     쿼럼 투표를 조정하려면

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

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

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

   • 동기-커밋 장애 조치(failover) 집합 외부에서 장애 조치(failover)를 한 경우: 원하는 동기 커밋 및 자동 장애 조치를 만든 것을 반영해 주도록 새 기본 복제본과 나머지 보조 복제본에서 가용성 모두 및 장애 조치 모드를 조정하는 것을 권장해 드립니다.

     참고 항목

     동기-커밋 장애 조치(failover) 집합은 현재의 기본 복제본(replica) 동기-커밋 모드로 만들어진 경우에만 존재합니다.

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

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

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

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

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

   Important

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

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

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

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

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

   주의

   모든 보조 데이터베이스를 다시 시작한 후에 그룹을 다시 장애 조치를 다시 시도하려고 하기 이전에 다음 장애 조치 대상의 모든 보조 데이터베이스가 동기화 상태로 전환될 때까지 기다려 주세요. 아직 동기화되지 않은 데이터베이스의 경우 해당 데이터베이스는 주 데이터베이스로 온라인 상태가 되지 않으며 데이터베이스에 대한 데이터 동기화를 다시 설정하기 위해서는 트랜잭션 로그 복원이나 전체 데이터베이스 백업 복원 또는 이전 주 복제본(replica) 장애 복구(failover)가 필요할 수도 있습니다.

3. 실패한 가용성 복제본이 가용성 복제본으로 반환되지 않거나 너무 늦게 반환되어 새 주 데이터베이스에서 트랜잭션 로그 잘림을 지연시키는 경우에는 로그 파일의 디스크 공간이 부족하지 않게 하기 위하여 가용성 그룹에서 실패한 복제본을 제거하는 것을 고려해 보세요.

   보조 복제본을 제거하기 위하여

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

4. 하나 이상의 추가 강제 장애 조치(failover)가 포함된 강제 장애 조치를 따라야 하는 경우 시리즈의 각 추가 강제 장애 조치(failover)를 한 후에 로그 백업을 실행해 보세요. 그 이유에 대한 자세한 내용은 장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹)의 “강제 수동 장애 조치(Failover)(데이터가 손실될 수 있음)” 섹션에 있는 “강제 장애 조치(Failover)의 위험”을 참조하세요.

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

   • 트랜잭션 로그 백업(SQL Server)

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

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

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

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

DBA(데이터베이스 관리자)는 가용성 그룹을 원격 비동기 커밋 보조 복제본(replica) 중 하나로 강제 장애 조치(failover)하는 것이 가장 좋은 응답이라고 결정합니다. 이 예제에서는 가용성 그룹을 원격 복제본(replica) 강제 장애 조치(failover)하여 결국에는 가용성 그룹을 원래 토폴로지로 반환할 때 발생하는 일반적인 단계를 보여 줍니다.

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

• 기본 데이터 센터의 치명적인 오류에 대응

• 가용성 그룹을 원래 토폴로지로 복귀

주 데이터 센터의 치명적인 실패에 대응

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

이 그림의 단계에서는 다음 단계를 나타냅니다:

단계	작업	링크
1.	DBA 또는 네트워크 관리자는 WSFC 클러스터에 정상적인 쿼럼이 있는지를 확인합니다. 이 예제에서는 쿼럼을 강제 실행해야 합니다.	WSFC 쿼럼 모드 및 투표 구성(SQL Server) 강제 쿼럼을 통해 WSFC 재해 복구(SQL Server)
2.	DBA는 최소 대기 시간(노드 04 )으로 서버 인스턴스에 연결하여 강제 수동 장애 조치를 실행합니다. 강제 장애 조치(failover)는 이 보조 복제본을 주 역할로 전환하고 나머지 보조 복제본( 노드 05)에서 보조 데이터베이스를 일시 중지합니다.	sys.dm_hadr_database_replica_states(Transact-SQL)(end_of_log_lsn 열을 쿼리합니다. 자세한 내용은 이 항목의 앞부분에 있는 권장 사항을 참조하세요.)
3.	DBA는 다시 기본 보조 복제본(replica)과 각 보조 데이터베이스를 수동으로 다시 시작합니다.	가용성 데이터베이스를 다시 시작

가용성 그룹을 원래 토폴로지로 복귀

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

Important

WSFC 클러스터 쿼럼이 강제로 적용된 경우 오프라인 노드가 다시 시작된다면 다음 조건에 모두 해당하는 경우 새 쿼럼을 만들 수 있습니다. (a) 강제 쿼럼 집합의 노드 간에 네트워크 연결이 없으며 (b) 다시 시작 노드는 클러스터 노드의 대부분입니다. 이에 따라 가용성 그룹이 각 데이터 센터에서 하나씩 두 개의 독립적인 기본 복제본(replica)을 소유하게 되는 "분할 브레인" 상태가 발생하게 됩니다. 쿼럼을 강제 실행하여 소수 쿼럼 집합을 만들기 전에 쿼럼 강제를 통해 WSFC 재해 복구(SQL Serve)를 참조하세요.

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

	단계	링크
1.	기본 데이터 센터의 노드는 다시 온라인 상태가 되며 WSFC 클러스터와의 통신을 다시 설정합니다. 가용성 복제본(replica) 일시 중단된 데이터베이스가 있는 보조 복제본(replica) 온라인 상태가 되며 DBA는 이러한 각 데이터베이스를 곧 수동으로 다시 시작해야 합니다.	가용성 데이터베이스 다시 시작(SQL Server) 팁: 사후 장애 조치(failover) 주 데이터베이스에서 데이터가 손실될 가능성이 있는 경우에는 동기 커밋 보조 데이터베이스 중 하나에서 일시 중지된 데이터베이스에 대한 데이터베이스 스냅샷을 만들어야 합니다. 보조 데이터베이스 중 하나라도 일시 중지되어 있는 동안에는 주 데이터베이스에서 트랜잭션 로그 잘림이 지연됩니다. 또한 일시 중지된 상태로 남아 있는 로컬 데이터베이스가 있으면 동기 커밋 보조 복제본의 동기화 상태가 정상으로 전환될 수 없습니다.
2.	데이터베이스가 다시 시작되면 DBA는 새 주 복제본(replica) 일시적으로 동기-커밋 모드로 변경합니다. 여기에는 다음 두 단계가 포함됩니다. 1) 오프라인 가용성 복제본 하나를 비동기 커밋 모드로 변경합니다. 2) 새 주 복제본을 동기 커밋 가용성 모드로 변경합니다. 이 단계를 통해 다시 시작된 동기-커밋 보조 데이터베이스는 동기화가 될 수 있습니다.	가용성 복제본의 가용성 모드 변경(SQL Server)
3.	노드 03(원래 주 복제본(replica))의 동기 커밋 보조 복제본(replica) 정상적인 동기화 상태가 되면 DBA는 해당 복제본(replica) 계획된 수동 장애 조치(failover)를 실행하여 다시 기본 복제본(replica)을 만듭니다. 노드 04의 복제본(replica)은 보조 복제본(replica)으로 반환됩니다.	sys.dm_hadr_database_복제본(replica)_states (Transact-SQL) Always On 정책을 사용하여 가용성 그룹의 상태 보기 (SQL Server) 가용성 그룹의 계획된 수동 장애 조치(Failover) 실행(SQL Server)
4.	DBA는 새 기본 복제본(replica) 연결하고 다음 사항을 실행합니다. 1) 이전 기본 복제본(replica)(원격 가운데)을 다시 비동기 커밋 모드로 변경합니다. 2) 기본 데이터 센터의 비동기 커밋 보조 복제본(replica) 동기-커밋 모드로 다시 변경합니다.	가용성 복제본의 사용 가능 모드 변경(SQL Server)

관련 작업

쿼럼 투표를 조정하려면

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

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

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

계획된 수동 장애 조치(failover):

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

• 가용성 그룹 장애 조치(failover)마법사 사용(SQL Server Management Studio)

문제점을 해결하려면:

• Always On 가용성 그룹 구성 문제 해결(SQL Server)

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

관련 내용

• 블로그:

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

  CSS SQL Server 엔지니어 블로그

• 백서:

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

  • SQL Server 고객 자문 팀 백서

참고 항목

Always On 가용성 그룹 개요(SQL Server)
가용성 모드(Always On 가용성 그룹)
장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹)
가용성 복제본에 대한 클라이언트 연결 액세스 정보(SQL Server)
가용성 그룹 모니터링(SQL Server)
SQL Server의 WSFC(Windows Server 장애 조치(Failover) 클러스터링)