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

このトピックに適用されますはいSQL Server (Linux の場合のみ)ありませんAzure SQL DatabaseありませんAzure SQL 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 クラスターを管理するペースが使用されている場合を使用して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 --full
  • SLES 例SLES example

    crm config show

(自動フェールオーバーを含む) の将来のフェールオーバーが成功するために、場所の制約を削除します。Remove the location constraint so future failovers - 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 failed over.

    sudo pcs resource clear ag_cluster-master 
  • SLES 例SLES example

    この例ではag_cluster中に失敗したリソースの名前を指定します。In this example ag_cluster is the name of the resource that failed over.

    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 


自動フェールオーバーでは場所の制約が追加されないため、削除は不要です。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 を使用した可用性グループをフェールオーバーします。Fail over the AG with Transact-SQL. 次の例では、置換<MyAg>可用性グループの名前に置き換えます。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. 強制フェールオーバー後に、クラスター リソースの監視と管理を再起動するか、可用性グループ リソースを再作成する前に正常な状態に、可用性グループを表示します。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 のインスタンスに、可用性グループがある場合は、out の遷移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=ON、可用性グループを作成するとき)、クラスターは、データベースの状態が確認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

Ubuntu クラスターは、SQL Server 可用性グループのクラスター リソースを構成します。Configure Ubuntu Cluster for SQL Server Availability Group Cluster Resources