Linux에서 SQL Server에 대 한 HA 가용성 그룹 동작Operate HA availability group for SQL Server on Linux

이 항목 적용 대상: 예(Linux에만 해당) SQL Server없습니다Azure SQL 데이터베이스없습니다Azure SQL 데이터 웨어하우스없는병렬 데이터 웨어하우스THIS TOPIC APPLIES TO: yesSQL Server (Linux only)noAzure SQL DatabasenoAzure SQL Data WarehousenoParallel Data Warehouse

가용성 그룹 장애 조치Fail over availability group

에 외부 클러스터 관리자에서 관리 하는 가용성 그룹 장애 조치 클러스터 관리 도구를 사용 합니다.Use the cluster management tools to fail over an availability group managed by an external cluster manager. 예를 들어 Pacemaker를 사용 하 여 Linux 클러스터를 관리 하는 솔루션을 사용 하 여 pcs RHEL 또는 Ubuntu에서 수동 장애 조치를 수행할 수 있습니다.For example, if a solution uses Pacemaker to manage a Linux cluster, use pcs to perform manual failovers on RHEL or Ubuntu. SLES에서 사용 하 여 crm합니다.On SLES use crm.

중요

정상 작업에서 장애 조치 하지 마십시오 SSMS 또는 PowerShell과 같은 TRANSACT-SQL 또는 SQL Server 관리 도구를 사용 합니다.Under normal operations, do not fail over with Transact-SQL or SQL Server management tools like SSMS or PowerShell. CLUSTER_TYPE = EXTERNAL만 사용 가능한 값에 대 한 FAILOVER_MODEEXTERNAL합니다.When CLUSTER_TYPE = EXTERNAL, the only acceptable value for FAILOVER_MODE is EXTERNAL. 이러한 설정을 사용 하 여 모든 수동 또는 자동 장애 조치 작업이 외부 클러스터 관리자에서 실행 됩니다.With these settings, all manual or automatic failover actions are executed by the external cluster manager.

수동 장애 조치 예제Manual failover examples

수동으로 외부 클러스터 관리 도구와 함께 가용성 그룹 장애 조치할 합니다.Manually fail over the availability group with the external cluster management tools. 정상 작업에서 TRANSACT-SQL로 장애 조치를 시작 하지 마십시오.Under normal operations, do not initiate failover with Transact-SQL. 외부 클러스터 관리 도구, 응답 하지 않는 경우에 가용성 그룹이 장애 조치를 강제로 수 있습니다.If the external cluster management tools do not respond, you can force the availability group to fail over. 강제 수동 장애 조치를 참조 하십시오 클러스터 도구 응답 하지 않습니다. 수동 이동합니다.For instructions to force the manual failover, see Manual move when cluster tools are not responsive.

두 가지 단계로 수동 장애 조치를 완료 합니다.Complete the manual failover in two steps.

  1. 새 노드는 리소스를 소유 하 고 클러스터 노드에서 가용성 그룹 리소스를 이동 합니다.Move the availability group resource from the cluster node that owns the resources to a new node.

    클러스터 관리자의 가용성 그룹 리소스가 이동한 위치 제약 조건을 추가 합니다.The cluster manager moves the availability group resource and adds a location constraint. 이 제약 조건은 새 노드에서 실행 하는 리소스를 구성 합니다.This constraint configures the resource to run on the new node. 하거나 수동 또는 자동으로 장애 조치 앞으로 이동 하려면이 제약 조건을 제거 해야 합니다.You must remove this constraint in order to move either manually or automatically fail over in the future.

  2. 위치 제약 조건을 제거 합니다.Remove the location constraint.

1. 수동 장애 조치1. Manually fail over

수동 장애 조치 라는 가용성 그룹 리소스를 ag_cluster 라는 클러스터 노드로 nodeName2, 배포에 필요한 적절 한 명령을 실행:To manually fail over an availability group resource named ag_cluster to cluster node named nodeName2, run appropriate command for your distribution:

  • RHEL/Ubuntu 예제RHEL/Ubuntu example

    sudo pcs resource move ag_cluster-master nodeName2 --master
    
  • SLES 예제SLES example

    crm resource migrate ag_cluster nodeName2
    

중요

리소스에 대해 수동으로 장애 후 자동으로 이동 하는 동안 추가 된 위치 제약 조건부 터 제거 해야 합니다.After you manually fail over a resource, you need to remove a location constraint that is automatically added during the move.

2. 위치 제약 조건 제거2. Remove the location constraint

수동 이동 중의 pcs 명령 move 또는 crm 명령 migrate 새 대상 노드에 배치 될 리소스에 대 한 위치 제약 조건을 추가 합니다.During a manual move, the pcs command move or crm command migrate adds a location constraint for the resource to be placed on the new target node. 새 제약 조건을 확인하려면 리소스를 수동으로 이동한 후 다음 명령을 실행합니다.To see the new constraint, run the following command after manually moving the resource:

  • RHEL/Ubuntu 예제RHEL/Ubuntu example

    sudo pcs constraint --full
    
  • SLES 예제SLES example

    crm config show
    

위치 제약 조건을 제거해야 자동 장애 조치(failover)를 포함한 이후 이동이 성공합니다.You need to remove the location constraint so future moves - including automatic failover - succeed.

제약 조건을 제거하려면 다음 명령을 실행합니다.To remove the constraint run the following command.

  • RHEL/Ubuntu 예제RHEL/Ubuntu example

    이 예에서 ag_cluster-master 이동 된 리소스의 이름입니다.In this example ag_cluster-master is the name of the resource that was moved.

    sudo pcs resource clear ag_cluster-master 
    
  • SLES 예제SLES example

    이 예에서 ag_cluster 이동 된 리소스의 이름입니다.In this example ag_cluster is the name of the resource that was moved.

    crm resource clear ag_cluster
    

또는 다음 명령을 실행하여 위치 제약 조건을 제거할 수 있습니다.Alternatively, you can run the following command to remove the location constraint.

  • RHEL/Ubuntu 예제RHEL/Ubuntu example

    다음 명령에서 cli-prefer-ag_cluster-master는 제거해야 하는 제약 조건의 ID입니다.In the following command cli-prefer-ag_cluster-master is the ID of the constraint that needs to be removed. sudo pcs constraint --full은 이 ID를 반환합니다.sudo pcs constraint --full returns this ID.

    sudo pcs constraint remove cli-prefer-ag_cluster-master  
    
  • SLES 예제SLES example

    다음 명령에서 cli-prefer-ms-ag_cluster 제약 조건의 ID입니다.In the following command cli-prefer-ms-ag_cluster is the ID of the constraint. crm config show은 이 ID를 반환합니다.crm config show returns this ID.

    crm configure
    delete cli-prefer-ms-ag_cluster 
    commit
    

참고

자동 장애 조치(failover)는 위치 제약 조건을 추가하지 않으므로 정리가 필요하지 않습니다.Automatic failover does not add a location constraint, so no cleanup is necessary.

자세한 내용은 다음을 참조하세요.For more information:

수동 이동할 때 클러스터 도구 응답 하지 않습니다.Manual move when cluster tools are not responsive

극단적인 경우 클러스터와의 상호 작용 하기 위한 사용자 클러스터 관리 도구를 사용할 수 없는 경우 (즉, 클러스터 응답 하지 않으면, 클러스터 관리 도구에는 잘못 된 동작이) 사용자-수동으로 장애 조치 해야 할 수는 외부 클러스터 관리자를 무시 합니다.In extreme cases, if a user cannot use the cluster management tools for interacting with the cluster (i.e. the cluster is unresponsive, cluster management tools have a faulty behavior), the user might have to fail over manually - bypassing the external cluster manager. 이 정기적인 작업에 권장 되지 않습니다 및 클러스터는 클러스터 관리 도구를 사용 하 여 장애 조치 작업 실행에 실패 하는 경우 내에서 사용 해야 합니다.This is not recommended for regular operations, and should be used within cases cluster is failing to execute the failover action using the cluster management tools.

클러스터 관리 도구와 함께 가용성 그룹으로 실패할 수 없는 경우 SQL Server 도구에서 장애 조치 하려면 다음이 단계를 따르십시오.If you cannot fail over the availability group with the cluster management tools, follow these steps to fail over from SQL Server tools:

  1. 가용성 그룹 리소스 관리 되지 않도록 클러스터에서 더 이상 확인 합니다.Verify that the availability group resource is not managed by the cluster any more.

    • 리소스를 관리 되지 않는 모드로 설정 하려고 합니다.Attempt to set the resource to unmanaged mode. 이 신호를 리소스 에이전트 리소스 모니터링을 중지 하 고 관리 합니다.This signals the resource agent to stop resource monitoring and management. 예를 들어For example:

      sudo pcs resource unmanage <**resourceName**>
      
    • 관리 되지 않는 모드로 리소스 모드를 설정 하 고 시도가 실패 하는 경우에 리소스를 삭제 합니다.If the attempt to set the resource mode to unmanaged mode fails, delete the resource. 예를 들어For example:

      sudo pcs resource delete <**resourceName**>
      

      참고

      리소스를 삭제 하는 경우 또한 삭제 모든 관련된 제약 조건을 합니다.When you delete a resource it also deletes all of the associated constraints.

  2. 세션 컨텍스트 변수를 수동으로 설정 external_cluster합니다.Manually set the session context variable external_cluster.

    EXEC sp_set_session_context @key = N'external_cluster', @value = N'yes';
    
  3. TRANSACT-SQL은 가용성 그룹을 장애 조치할 합니다.Fail over the availability group with Transact-SQL. 바꾸기 아래 예제에서는 <**MyAg**> 가용성 그룹의 이름으로 합니다.In the example below replace <**MyAg**> with the name of your availability group. 대상 보조 복제본을 호스팅하는 SQL Server의 인스턴스에 연결 하 고 다음 명령을 실행 합니다.Connect to the instance of SQL Server that hosts the target secondary replica and run the following command:

    ALTER AVAILABILITY GROUP <**MyAg**> FAILOVER;
    
  4. 클러스터 리소스 모니터링 및 관리를 다시 시작 합니다.Restart cluster resource monitoring and management. 다음 명령을 실행합니다.Run the following command:

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

데이터베이스 수준 모니터링 및 장애 조치 트리거Database level monitoring and failover trigger

에 대 한 CLUSTER_TYPE=EXTERNAL, 장애 조치 트리거 의미 체계는 다른 WSFC에 비해 합니다.For CLUSTER_TYPE=EXTERNAL, the failover trigger semantics are different compared to WSFC. 가용성 그룹 wsfc에서 SQL Server의 인스턴스로 설정 하면 아웃의 전환을 ONLINE 데이터베이스 하면 오류를 보고 하기 위해 가용성 그룹 상태에 대 한 상태입니다.When the availability group is on an instance of SQL Server in a WSFC, transitioning out of ONLINE state for the database causes the availability group health to report a fault. 이 신호를 장애 조치 작업을 트리거하는 클러스터 관리자를 보내는 합니다.This will signal the cluster manager to trigger a failover action. Linux에서 SQL Server 인스턴스 클러스터와 통신할 수 없습니다.On Linux, the SQL Server instance cannot communicate with the cluster. "외부의" 데이터베이스 상태에 대 한 모니터링이 수행 됩니다.Monitoring for database health is done "outside-in". 데이터베이스 수준 장애 조치 모니터링 및 장애 조치에 대 한 사용자에 옵트인 하는 경우 (옵션을 설정 하 여 DB_FAILOVER=ON 가용성 그룹을 만들 때), 클러스터 데이터베이스 상태 인지 확인 합니다 ONLINE 될 때마다 모니터링 작업을 실행 합니다.If user opted in for database level failover monitoring and failover (by setting the option DB_FAILOVER=ON when creating the availability group), the cluster will check if the database state is ONLINE every time when it runs a monitoring action. 클러스터의 상태를 쿼리 sys.databases합니다.The cluster queries the state in sys.databases. 다른 모든 상태에 대 한 ONLINE, 자동으로 (자동 장애 조치 조건이 충족 될 경우)는 장애 조치를 트리거합니다.For any state different than ONLINE, it will trigger a failover automatically (if automatic failover conditions are met). 장애 조치의 실제 시간 sys.databases에서 업데이트 되는 데이터베이스 상태 뿐만 아니라 모니터링 작업의 빈도에 따라 달라 집니다.The actual time of the failover depends on the frequency of the monitoring action as well as the database state being updated in sys.databases.

가용성 그룹을 업그레이드Upgrade availability group

가용성 그룹을 업그레이드 하기 전에에서 모범 사례를 검토 가용성 그룹 복제본 인스턴스 업그레이드합니다.Before you upgrade an availability group, review the best practices at Upgrading availability group replica instances.

다음 섹션에서는 Linux에서 가용성 그룹이 포함 된 SQL Server 인스턴스에서 롤링 업그레이드를 수행 하는 방법을 설명 합니다.The following sections explain how to perform a rolling upgrade with SQL Server instances on Linux with availability groups.

Linux에서 업그레이드 단계Upgrade steps on Linux

Linux에서 SQL Server의 인스턴스에서 가용성 그룹 복제본을 가용성 그룹의 클러스터 유형 중 하나는 EXTERNAL 또는 NONE합니다.When availability group replicas are on instances of SQL Server in Linux, the cluster type of the availability group is either EXTERNAL or NONE. 이외에 Windows Server 장애 조치 클러스터 (WSFC)는 클러스터 관리자에서 관리 되는 가용성 그룹 EXTERNAL합니다.An availability group that is managed by a cluster manager besides Windows Server Failover Cluster (WSFC) is EXTERNAL. Corosync와 pacemaker는 외부 클러스터 관리자의 예시입니다.Pacemaker with Corosync is an example of an external cluster manager. 클러스터 관리자가 없습니다 포함 된 가용성 그룹에 클러스터 형식이 NONE 여기에 설명 된 업그레이드 단계는 클러스터 유형의 가용성 그룹에 대 한 특정 EXTERNAL 또는 NONE합니다.An availability group with no cluster manager has cluster type NONE The upgrade steps outlined here are specific for availability groups of cluster type EXTERNAL or NONE.

  1. 시작 하기 전에 각 데이터베이스를 백업 합니다.Before you begin, backup each database.
  2. 보조 복제본을 호스팅하는 SQL Server의 인스턴스를 업그레이드 합니다.Upgrade instances of SQL Server that host secondary replicas.

    a.a. 비동기 보조 복제본을 먼저 업그레이드 합니다.Upgrade asynchronous secondary replicas first.

    b.b. 동기 보조 복제본을 업그레이드 합니다.Upgrade synchronous secondary replicas.

    참고

    가용성 그룹에 있는 비동기 데이터 손실을 방지 하기 위해 복제본-하나의 복제본을 동기 변경한 동기화 될 때까지 기다립니다.If an availability group only has asynchronous replicas - to avoid any data loss change one replica to synchronous and wait until it is synchronized. 이 복제를 업그레이드 합니다.Then upgrade this replica.

    b.1 합니다.b.1. 업그레이드에 대 한 대상 보조 복제본을 호스팅하는 노드의에 리소스를 중지 합니다.Stop the resource on the node hosting the secondary replica targeted for upgrade

    업그레이드 명령을 실행 하기 전에 클러스터 모니터링은 되 불필요 하 게 실패 하지 하도록 리소스를 중지 합니다.Before running the upgrade command, stop the resource so the cluster will not monitor it and fail it unnecessarily. 다음 예제에서는 중지 될 리소스에 취소할 수 있는 노드의 위치 제약 조건을 추가 합니다.The following example adds a location constraint on the node that will result on the resource to be stopped. 업데이트 ag_cluster-master 리소스 이름으로 및 nodeName1 노드를 복제본을 호스팅하는 업그레이드에 대 한 대상으로 합니다.Update ag_cluster-master with the resource name and nodeName1 with the node hosting the replica targeted for upgrade.

    pcs constraint location ag_cluster-master avoids nodeName1
    

    b.2 합니다.b.2. 보조 복제본에서 SQL Server 업그레이드Upgrade SQL Server on the secondary replica

    다음 예제에서는 업그레이드 mssql-servermssql-server-ha 패키지 합니다.The following example upgrades mssql-server and mssql-server-ha packages.

    sudo yum update mssql-server
    sudo yum update mssql-server-ha
    

    b.3 합니다.b.3. 위치 제약 조건 제거Remove the location constraint

    업그레이드 명령을 실행 하기 전에 클러스터 모니터링은 되 불필요 하 게 실패 하지 하도록 리소스를 중지 합니다.Before running the upgrade command, stop the resource so the cluster will not monitor it and fail it unnecessarily. 다음 예제에서는 중지 될 리소스에 취소할 수 있는 노드의 위치 제약 조건을 추가 합니다.The following example adds a location constraint on the node that will result on the resource to be stopped. 업데이트 ag_cluster-master 리소스 이름으로 및 nodeName1 노드를 복제본을 호스팅하는 업그레이드에 대 한 대상으로 합니다.Update ag_cluster-master with the resource name and nodeName1 with the node hosting the replica targeted for upgrade.

    pcs constraint remove location-ag_cluster-master-rhel1--INFINITY
    

    모범 사례로, 리소스에서 시작 되었는지 확인 하십시오 (사용 하 여 pcs status 명령) 보조 복제본 연결 되어 있으며 업그레이드 후 상태를 동기화 하 고 있습니다.As a best practice, ensure the resource is started (using pcs status command) and the secondary replica is connected and synchronized state after upgrade.

  3. 보조 복제본을 모두를 업그레이드 한 후 수동 장애 조치를 동기 보조 복제본 중 하나입니다.After all secondary replicas are upgraded, manually fail over to one of the synchronous secondary replicas.

    인 가용성 그룹에 대 한 EXTERNAL 형식 클러스터, 클러스터 관리 도구를 사용 하 여 장애 조치; 인 가용성 그룹 NONE 클러스터 유형 TRANSACT-SQL을 사용 하 여 장애 조치 해야 합니다.For availability groups with EXTERNAL cluster type, use the cluster management tools to fail over; availability groups with NONE cluster type should use Transact-SQL to fail over. 다음 예제에서는 클러스터 관리 도구를 사용 하는 가용성 그룹을 통해 실패합니다.The following example fails over an availability group with the cluster management tools. 대체 <targetReplicaName> 주 역할을 할 때 동기 보조 복제본의 이름으로:Replace <targetReplicaName> with the name of the synchronous secondary replica that will become primary:

    sudo pcs resource move ag_cluster-master <targetReplicaName> --master  
    

    중요

    다음 단계는 클러스터 관리자를 갖지 않는 가용성 그룹에만 적용 합니다.The following steps only apply to availability groups that do not have a cluster manager.
    가용성 그룹 클러스터 유형이 NONE수동으로 장애 조치 합니다.If the availability group cluster type is NONE, manually fail over. 다음 단계를 순서대로 수행하세요.Complete the following steps in order:

    a.a. 다음 명령은 보조를 주 복제본을 설정합니다.The following command sets the primary replica to secondary. 대체 AG1 가용성 그룹의 이름으로 합니다.Replace AG1 with the name of your availability group. 주 복제본을 호스팅하는 SQL Server의 인스턴스에 TRANSACT-SQL 명령을 실행 합니다.Run the Transact-SQL command on the instance of SQL Server that hosts the primary replica.

    ALTER AVAILABILITY GROUP [ag1] SET (ROLE = SECONDARY);
    

    b.b. 다음 명령은 기본 동기 보조 복제본으로 설정 합니다.The following command sets a synchronous secondary replica to primary. 대상 인스턴스의 SQL Server-동기 보조 복제본을 호스팅하는 인스턴스에 다음 TRANSACT-SQL 명령을 실행 합니다.Run the following Transact-SQL command on the target instance of SQL Server - the instance that hosts the synchronous secondary replica.

    ALTER AVAILABILITY GROUP [ag1] FAILOVER;
    
  4. 장애 조치 후 이전 주 복제본에서 SQL Server b.1 b.3 위의 단계에서 설명한 동일한 절차를 반복 하 여 업그레이드 합니다.After failover, upgrade SQL Server on the old primary replica by repeating the same procedure described in steps b.1-b.3 above.

    다음 예제에서는 업그레이드 mssql-servermssql-server-ha 패키지 합니다.The following example upgrades mssql-server and mssql-server-ha packages.

    # add constraint for the resource to stop on the upgraded node
    # replace 'nodename2' with the name of the cluster node targeted for upgrade
    pcs constraint location ag_cluster-master avoids nodeName2
    sudo yum update mssql-server
    sudo yum update mssql-server-ha
    
    # upgrade mssql-server and mssql-server-ha packages
    sudo yum update mssql-server
    sudo yum update mssql-server-ha
    
    # remove the constraint; make sure the resource is started and replica is connected and synchronized
    pcs constraint remove location-ag_cluster-master-rhel1--INFINITY
    
  5. 외부 클러스터와는 가용성 그룹에 대 한 관리자-클러스터 입력할 수 있는 EXTERNAL, 정리 수동 장애 조치에 의해 발생 한 위치 제약 조건입니다.For an availability groups with an external cluster manager - where cluster type is EXTERNAL, cleanup the location constraint that was caused by the manual failover.

    sudo pcs constraint remove cli-prefer-ag_cluster-master  
    
  6. 새로 업그레이드 된 보조 복제본-이전 주 복제본에 대 한 데이터 이동을 다시 시작 합니다.Resume data movement for the newly upgraded secondary replica - the former primary replica. 이 가용성 그룹에서 더 낮은 버전 인스턴스를 더 높은 버전 인스턴스에 SQL Server의 로그 블록을 전송 하는 경우에 필요 합니다.This is required when a higher version instance of SQL Server is transferring log blocks to a lower version instance in an availability group. 새로운 보조 복제본 (이전의 주 복제본)에서 다음 명령을 실행 합니다.Run the following command on the new secondary replica (the previous primary replica).

    ALTER DATABASE database_name SET HADR RESUME;
    

-장애 복구를 할 수 있습니다 모든 서버를 업그레이드 한 후 다시 장애 조치 원본 주-필요한 경우.After upgrading all servers, you can failback - fail over back to the original primary - if necessary.

가용성 그룹 삭제Drop an availability group

가용성 그룹을 삭제 하려면 실행 DROP AVAILABILITY GROUP합니다.To delete an availability group, run DROP AVAILABILITY GROUP. 클러스터 형식이 EXTERNAL 또는 NONE 복제본을 호스팅하는 SQL Server의 모든 인스턴스에서 명령을 실행 합니다.If the cluster type is EXTERNAL or NONE run the command on every instance of SQL Server that hosts a replica. 예를 들어 라는 가용성 그룹을 삭제 하려면 group_name 다음 명령을 실행 합니다.For example, to drop an availability group named group_name run the following command:

DROP AVAILABILITY GROUP group_name

다음 단계Next steps

SQL Server 가용성 그룹 클러스터 리소스에 대 한 Red Hat Enterprise Linux 클러스터를 구성 합니다.Configure Red Hat Enterprise Linux Cluster for SQL Server Availability Group Cluster Resources

SQL Server 가용성 그룹 클러스터 리소스에 대 한 SUSE Linux Enterprise Server 클러스터 구성Configure SUSE Linux Enterprise Server Cluster for SQL Server Availability Group Cluster Resources

SQL Server 가용성 그룹 클러스터 리소스에 대 한 Ubuntu 클러스터 구성Configure Ubuntu Cluster for SQL Server Availability Group Cluster Resources