다음을 통해 공유


Linux의 Always On 가용성 그룹 장애 조치(failover)

적용 대상: SQL Server - Linux

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

장애 조치에 대한 배경 정보는 장애 조치(Failover) 및 장애 조치(Failover) 모드(Always On 가용성 그룹)를 참조하세요.

수동 장애 조치

클러스터 관리 도구를 사용하여 외부 클러스터 관리자가 관리하는 AG를 장애 조치(failover)합니다. 예를 들어 솔루션에서 Pacemaker를 사용하여 Linux 클러스터를 관리하는 경우 pcs를 사용하여 RHEL(Red Hat Enterprise Linux) 또는 Ubuntu에서 수동 장애 조치(failover)를 수행합니다. SLES(SUSE Linux Enterprise Server)에서는 crm를 사용합니다.

Important

정상적으로 작동하는 경우 Transact-SQL 또는 SQL Server 관리 도구(예: SSMS 또는 PowerShell)를 사용하여 장애 조치(failover)하지 마세요. CLUSTER_TYPE = EXTERNAL의 경우 FAILOVER_MODE에 허용되는 유일한 값은 EXTERNAL입니다. 이 설정을 사용하면 모든 수동 또는 자동 장애 조치(failover) 작업이 외부 클러스터 관리자에 의해 실행됩니다. 데이터 손실 가능성이 있는 장애 조치(failover)를 강제 적용하는 지침은 강제 장애 조치(failover)를 참조하세요.

수동 장애 조치(failover) 단계

장애 조치(failover)를 수행하려면 주 복제본(replica) 될 보조 복제본이 동기적이어야 합니다. 보조 복제본 비동기인 경우 가용성 모드를 변경합니다.

수동으로 두 단계를 거쳐 장애 조치(failover)합니다.

  1. 먼저, 리소스를 소유하는 클러스터 노드에서 새 노드로 AG 리소스를 이동하여 수동으로 장애 조치(failover)합니다.

    클러스터는 AG 리소스를 장애 조치(failover)를 수행하고 위치 제약 조건을 추가합니다. 이 제약 조건은 새 노드에서 실행되도록 리소스를 구성합니다. 나중에 성공적으로 장애 조치(failover)하려면 이 제약 조건을 제거하세요.

  2. 둘째, 위치 제약 조건을 제거합니다.

1단계. 가용성 그룹 리소스를 이동하여 수동으로 장애 조치(failover)

ag_cluster라는 이름의 AG 리소스스를 nodeName2라는 이름의 클러스터 노드로 수동으로 장애 조치(fail over)하려면 배포에 적절한 명령을 실행합니다.

  • RHEL/Ubuntu 예제

    sudo pcs resource move ag_cluster-master nodeName2 --master --lifetime=30S
    
  • SLES 예제

    crm resource migrate ag_cluster nodeName2 --lifetime=30S
    

--lifetime 옵션을 사용하는 경우 리소스를 이동하기 위해 만든 위치 제약 조건은 본질적으로 일시적이며 이전 예제에서 30초 동안 유효합니다.

임시 제약 조건은 자동으로 지워지지 않으며 제약 조건 목록에 표시될 수 있지만 만료된 제약 조건으로 표시될 수 있습니다. 만료된 제약 조건은 Pacemaker 클러스터의 장애 조치(failover) 동작에 영향을 주지 않습니다. 리소스를 이동할 때 --lifetime 옵션을 사용하지 않는 경우 다음 섹션에 설명된 대로 자동으로 추가되는 위치 제약 조건을 제거해야 합니다.

2단계. 위치 제약 조건을 제거합니다.

수동 장애 조치(failover) 중에 pcs 명령 move 또는 crm 명령 migrate은(는) 새 대상 노드에 배치될 리소스에 대한 위치 제약 조건을 추가합니다. 새 제약 조건을 보려면 리소스를 수동으로 이동한 후 다음 명령을 실행하세요.

  • RHEL/Ubuntu 예제

    sudo pcs constraint list --full
    
  • SLES 예제

    crm config show
    

    이는 수동 장애 조치(failover)로 인해 만들어지는 제약 조건의 예제입니다.

    Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

    참고 항목

    Red Hat Enterprise Linux 8.x 및 Ubuntu 18.04의 Pacemaker 클러스터에 있는 AG 리소스 이름은 리소스에 대한 명명법이 승격 가능한 복제를 사용하도록 발전함에 따라 ag_cluster-clone과 유사할 수 있습니다.

  • RHEL/Ubuntu 예제

    다음 명령 cli-prefer-ag_cluster-master은(는) 제거해야 할 제약 조건의 ID입니다. sudo pcs constraint list --full은 이 ID를 반환합니다.

    sudo pcs resource clear ag_cluster-master
    

    또는

    sudo pcs constraint remove cli-prefer-ag_cluster-master
    

    또는 다음과 같이 한 줄로 자동 생성된 제약 조건의 이동 및 지우기를 모두 수행할 수 있습니다. 다음 예제에서는 Red Hat Enterprise Linux 8.x에 따라 복제라는 용어를 사용합니다.

    sudo pcs resource move ag_cluster-clone --master nodeName2 && sleep 30 && sudo pcs resource clear ag_cluster-clone
    
  • SLES 예제

    다음 명령 cli-prefer-ms-ag_cluster은(는) 제약 조건의 ID입니다. crm config show은 이 ID를 반환합니다.

    crm configure
    delete cli-prefer-ms-ag_cluster
    commit
    

참고 항목

자동 장애 조치(failover)는 위치 제약 조건을 추가하지 않으므로 정리가 필요하지 않습니다.

자세한 내용은 페이지를 참조하십시오.

강제 장애 조치(failover)

강제 장애 조치(failover)는 철저히 재해 복구만을 위한 것입니다. 이 경우 주 데이터 센터가 다운되었기 때문에 클러스터 관리 도구를 사용하여 장애 조치(failover)할 수 없습니다. 동기화되지 않은 보조 복제본(replica)으로 강제 장애 조치(failover)를 하는 경우 일부 데이터 손실이 발생할 수 있습니다. 즉시 AG에 서비스를 복구해야 하며 일부 데이터가 손실되는 위험을 감수하려는 경우에만 서비스를 강제 실행하는 것이 좋습니다.

클러스터와 상호 작용하는 데 클러스터 관리 도구를 사용할 수 없는 경우(예: 주 데이터 센터의 재해 이벤트로 인해 클러스터가 응답하지 않는 경우) 강제 장애 조치(failover)를 수행하여 외부 클러스터 관리자를 우회해야 할 수도 있습니다. 이 절차는 데이터 손실 위험이 있으므로 일반 작업에는 권장되지 않습니다. 이 절차는 클러스터 관리 도구가 장애 조치(failover) 작업을 실행하지 못할 때 사용합니다. 기능적으로 이 절차는 Windows의 AG에서 강제 수동 장애 조치(failover)를 수행하는 것과 유사합니다.

강제 장애 조치(failover)를 위한 이 프로세스는 SQL Server on Linux에만 해당됩니다.

  1. 클러스터가 더 이상 AG 리소스를 관리하지 않는지 확인합니다.

    • 대상 클러스터 노드에서 리소스를 비관리형 모드로 설정합니다. 이 명령은 리소스 모니터링 및 관리를 중지하도록 리소스 에이전트에 신호를 보냅니다. 예시:

      sudo pcs resource unmanage <resourceName>
      
    • 리소스 모드를 비관리리형 모드로 설정하지 못하는 경우에는 리소스를 삭제합니다. 예시:

      sudo pcs resource delete <resourceName>
      

      참고 항목

      리소스를 삭제하면 연결된 제약 조건도 모두 삭제됩니다.

  2. 보조 복제본(replica) 호스트하는 SQL Server 인스턴스에서 세션 컨텍스트 변수 external_cluster을(를) 설정합니다.

    EXEC sp_set_session_context @key = N'external_cluster', @value = N'yes';
    
  3. Transact-SQL을 사용하여 AG를 장애 조치(failover)합니다. 다음 예제에서는 <MyAg>을(를) AG 이름으로 바꿉니다. 대상 보조 복제본을 호스팅하는 SQL Server 인스턴스에 연결하고 다음 명령을 실행합니다.

    ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;
    
  4. 강제 장애 조치(failover) 후 클러스터 리소스 모니터링 및 관리를 다시 시작하거나 AG 리소스를 다시 만들기 전에 AG를 정상 상태로 만듭니다. 강제 장애 조치(failover) 후 필수 작업을 검토합니다.

  5. 클러스터 리소스 모니터링 및 관리를 다시 시작합니다.

    클러스터 리소스 모니터링 및 관리를 다시 시작하려면 다음 명령을 실행합니다.

    sudo pcs resource manage <resourceName>
    sudo pcs resource cleanup <resourceName>
    

    클러스터 리소스를 삭제한 경우 다시 만듭니다. 클러스터 리소스를 다시 만들려면 가용성 그룹 리소스 만들기의 지침을 따르세요.

Important

데이터가 손실될 위험이 있으므로 재해 복구 연습에는 앞의 단계를 사용하지 마세요. 대신 비동기 복제본(replica) 동기로 변경하고 일반적인 수동 장애 조치(failover)에 대한 지침을 따르세요.

데이터베이스 수준 모니터링 및 장애 조치(failover) 트리거

CLUSTER_TYPE=EXTERNAL의 경우 장애 조치(failover) 트리거 의미 체계는 WSFC와 다릅니다. AG가 WSFC의 SQL Server 인스턴스에 있는 경우 데이터베이스의 ONLINE 상태에서 전환하면 AG 상태에서 오류가 보고됩니다. 이에 대한 응답으로 클러스터 관리자는 장애 조치(failover) 작업을 트리거합니다. Linux에서 SQL Server 인스턴스는 클러스터와 통신할 수 없습니다.다. 데이터베이스 상태에 대한 모니터링은 외부에서 수행됩니다. 사용자가 데이터베이스 수준 장애 조치(failover) 모니터링 및 장애 조치(failover)(AG 생성 시 옵션 DB_FAILOVER=ON 설정)를 선택한 경우 클러스터는 모니터링 작업을 실행할 때마다 데이터베이스 상태가 ONLINE인지 확인합니다. 클러스터는 sys.databases의 상태를 쿼리합니다. ONLINE와 다른 상태의 경우 자동으로 장애 조치(failover)를 트리거합니다(자동 장애 조치(failover) 조건이 충족되는 경우). 장애 조치(failover)의 실제 시간은 모니터링 작업의 빈도와 sys.databases.에서 업데이트되는 데이터베이스 상태에 따라 달라집니다

자동 장애 조치(failover)에는 하나 이상의 동기 복제본(replica) 필요합니다.

SQL 설명서 작성에 참여하세요.

SQL 콘텐츠를 직접 편집할 수 있다는 것을 알고 계셨나요? 직접 편집하여 설명서를 개선하고, 페이지에 기여자로 참여하세요.

자세한 내용은 SQL Server 설명서에 기여하는 방법을 참조하세요