Linux 上の always On 可用性グループのフェールオーバーAlways On Availability Group failover on Linux

このトピックの対象: はいSQL サーバー (Linux のみ)ありませんAzure SQL DatabaseありませんAzure SQL Data WarehouseありませんParallel Data Warehouse THIS TOPIC APPLIES TO: yesSQL Server (Linux only)noAzure SQL DatabasenoAzure SQL Data WarehousenoParallel Data Warehouse

、可用性グループ (AG) のコンテキスト内でプライマリ ロールとセカンダリ ロールの可用性レプリカは通常、フェールオーバーと呼ばれるプロセスで交換されることです。Within the context of an availability group (AG), the primary role and secondary role of availability replicas are typically interchangeable in a process known as failover. フェールオーバーには、自動フェールオーバー (データ損失なし)、計画的な手動フェールオーバー (データ損失なし)、および " 強制フェールオーバー" と通常呼ばれる強制手動フェールオーバー (データ損失の可能性あり) の 3 つの形式があります。Three forms of failover exist: automatic failover (without data loss), planned manual failover (without data loss), and forced manual failover (with possible data loss), typically called forced failover. 自動フェールオーバーと計画的な手動フェールオーバーでは、すべてのデータを保持します。Automatic and planned manual failovers preserve all your data. AG は、可用性レプリカのレベルでフェールオーバーします。An AG fails over at the availability-replica level. つまり、AG はそのセカンダリ レプリカ (現在のフェールオーバー ターゲット) のいずれかにフェールオーバーします。That is, an AG fails over to one of its secondary replicas (the current failover target).

フェールオーバーの背景については、次を参照してください。フェールオーバーとフェールオーバー モードします。For background information about failover, see Failover and failover modes.

手動フェールオーバーManual failover

クラスターの管理ツールを使用して、外部のクラスター マネージャーによって管理されている AG をフェールオーバーする場合します。Use the cluster management tools to fail over an AG managed by an external cluster manager. たとえば、ソリューションでは、Linux クラスターを管理する Pacemaker を使用している場合を使用してpcsRHEL または 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. データ損失のフェールオーバーを強制する手順については、次を参照してください。を強制的にフェールオーバーします。For instructions to force failover with potential data loss, see Force failover.

手動のフェールオーバー手順Manual failover steps

フェールオーバーすると、プライマリ レプリカになるセカンダリ レプリカが同期される必要があります。To fail over, the secondary replica that will become the primary replica must be synchronous. セカンダリ レプリカは非同期で場合可用性モードを変更します。If a secondary replica is asynchronous, change the availability mode.

手動で 2 つの手順でフェールオーバーします。Manually fail over in two steps.

まず、 AG リソースを移動して手動フェールオーバーを新しいノードにリソースを所有するクラスター ノードから。First, manually fail over by moving AG resource from the cluster node that owns the resources to a new node.

クラスターでは、可用性グループ リソースをフェールオーバーし、場所の制約を追加します。The cluster fails the AG resource over and adds a location constraint. この制約は、新しいノードで実行するリソースを構成します。This constraint configures the resource to run on the new node. 将来的で正常にフェールオーバーするには、この制約を削除します。Remove this constraint in order to successfully fail over in the future.

2 番目、場所の制約を削除します。Second, remove the location constraint.

手順 1 です。Step 1. 可用性グループ リソースを移動して手動で失敗します。Manually fail over by moving availability group resource

という名前の可用性グループ リソースを手動でフェールオーバーするag_clusterという名前のクラスター ノードにnodeName2、お使いのディストリビューションの適切なコマンドを実行します。To manually fail over an AG resource named ag_cluster to cluster node named nodeName2, run the 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.

手順 2 です。 Step 2. 場所の制約の削除Remove the location constraint

手動のフェールオーバー中に、pcsコマンドmoveまたはcrmコマンドmigrate新しいターゲット ノードに配置するリソースの場所の制約を追加します。During a manual failover, 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 list --full
  • SLES の例SLES example

    crm config show

手動フェールオーバーのために作成される制約の例です。An example of the constraint which gets created becuase of a manual failover. Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

  • 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 list --full によってこの ID が返されます。sudo pcs constraint list --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 


自動フェールオーバーでは場所の制約が追加されないため、削除は不要です。Automatic failover does not add a location constraint, so no cleanup is necessary.

詳細:For more information:

強制フェールオーバーForce failover

厳密に強制フェールオーバーはディザスター リカバリー、です。A forced failover is intended strictly for disaster recovery. この場合は、ことはできませんフェールオーバーを実行するクラスター管理ツールを使用して、プライマリ データ センターがダウンしているためです。In this case, you cannot fail over with cluster management tools because the primary datacenter is down. 非同期のセカンダリ レプリカに対して強制フェールオーバーを実行した場合、データ損失の可能性があります。If you force failover to an unsynchronized secondary replica, some data loss is possible. サービスをすぐに、可用性グループに復元し、データの損失を許容する場合は、フェールオーバーを強制のみです。Only force failover if you must restore service to the AG immediately and are willing to risk losing data.

場合は、クラスターが、プライマリ データ センターで障害が原因で応答していない場合など、クラスターと対話するため、クラスター管理ツールを使用することはできません、外部のクラスター マネージャーをバイパスするフェールオーバーを強制する必要があります。If you cannot use the cluster management tools for interacting with the cluster - for example, if the cluster is unresponsive due to a disaster event in the primary data center, you might have to force failover to bypass the external cluster manager. この手順は、データ損失のリスクがありますので、通常の操作は推奨されません。This procedure is not recommended for regular operations because it risks data loss. フェールオーバー アクションを実行するクラスターの管理ツールが失敗したときに使用します。Use it when the cluster management tools fail to execute the failover action. 機能的には、この手順は、のような強制手動フェールオーバーを実行するWindows での AG にします。Functionally, this procedure is similar to performing a forced manual failover on an AG in Windows.

強制フェールオーバーを実行するためにこのプロセスは、SQL Server on Linux に固有です。This process for forcing failover is specific to SQL Server on Linux.

  1. 以上、可用性グループ リソースをクラスターによって管理されませんを確認します。Verify that the AG resource is not managed by the cluster any more.

    • ターゲット クラスターのノードで、リソースを非管理対象モードに設定します。Set the resource to unmanaged mode on the target cluster node. このコマンドは、停止リソースの監視および管理するリソース エージェントを通知します。This command 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. セカンダリ レプリカをホストする SQL Server のインスタンスで、セッションのコンテキスト変数を設定external_clusterします。On the instance of SQL Server that hosts the secondary replica, set the session context variable external_cluster.

    EXEC sp_set_session_context @key = N'external_cluster', @value = N'yes';
  3. Transact SQL を使用した AG をフェールオーバーします。Fail over the AG with Transact-SQL. 次の例では、置き換える<MyAg>AG の名前に置き換えます。In the following example, replace <MyAg> with the name of your AG. 対象のセカンダリ レプリカをホストする SQL Server のインスタンスに接続し、次のコマンドを実行します。Connect to the instance of SQL Server that hosts the target secondary replica and run the following command:

  4. 強制フェールオーバー後、正常な状態にクラスター リソースの監視と管理を再起動するか、可用性グループ リソースを再作成する前に、AG をもたらします。After a forced failover, bring the AG to a healthy state before either restarting the cluster resource monitoring and management or recreating the AG resource. レビュー、強制フェールオーバー後の必須タスクします。Review the Essential Tasks After a Forced Failover.

  5. クラスター リソースの監視と管理を再起動するか。Either restart cluster resource monitoring and management:

    クラスター リソースの監視と管理を再起動するには、次のコマンドを実行します。To restart the cluster resource monitoring and management, run the following command:

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

    クラスター リソースを削除した場合は、それを再作成します。If you deleted the cluster resource, recreate it. クラスター リソースを再作成する」の手順に従います可用性グループ リソースを作成するします。To recreate the cluster resource, follow the instructions at Create availability group resource.


データの損失になる可能性があるために、ディザスター リカバリーの訓練を前の手順を使用しないでください。Do not use the preceding steps for disaster recovery drills because they risk data loss. 非同期レプリカを同期的でとための手順を変更する代わりに通常の手動フェールオーバーします。Instead change the asynchronous replica to synchronous, and the instructions for normal manual failover.

データベース レベルの監視とフェールオーバーのトリガー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 AG is on an instance of SQL Server in a WSFC, transitioning out of ONLINE state for the database causes the AG health to report a fault. 応答では、クラスター マネージャーは、フェールオーバー アクションをトリガーします。In response, the cluster manager triggers 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=ONAG を作成するときに)、クラスターは、データベースの状態が確認ONLINE監視アクションを実行するたびにします。If user opted in for database level failover monitoring and failover (by setting the option DB_FAILOVER=ON when creating the AG), the cluster will check if the database state is ONLINE every time 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.

自動フェールオーバーでは、少なくとも 1 つの同期レプリカが必要です。Automatic failover requires at least one synchronous replica.

次のステップ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