Linux での Always On 可用性グループのフェールオーバー

適用対象: SQL Server - Linux

可用性グループ (AG) のコンテキストでは、可用性レプリカのプライマリ ロールとセカンダリ ロールは、通常、フェールオーバーと呼ばれるプロセスで入れ替えることができます。 フェールオーバーには、自動フェールオーバー (データ損失なし)、計画的な手動フェールオーバー (データ損失なし)、および " 強制フェールオーバー" と通常呼ばれる強制手動フェールオーバー (データ損失の可能性あり) の 3 つの形式があります。 自動フェールオーバーと計画的な手動フェールオーバーでは、すべてのデータが保持されます。 AG は、可用性レプリカのレベルでフェールオーバーされます。 つまり、AG はセカンダリ レプリカのいずれか (現在のフェールオーバー ターゲット) にフェールオーバーされます。

フェールオーバーに関する背景情報については、「フェールオーバーとフェールオーバー モード (AlwaysOn 可用性グループ)」を参照してください。

手動フェールオーバー

外部のクラスター マネージャーによって管理されている AG をフェールオーバーするには、クラスター管理ツールを使います。 たとえば、ソリューションで Pacemaker を使って Linux クラスターが管理されている場合、Red Hat Enterprise Linux (RHEL) または Ubuntu で手動フェールオーバーを実行するには、pcs を使います。 SUSE Linux Enterprise Server (SLES) の場合は、crm を使います。

重要

通常の動作では、SSMS や PowerShell などの Transact-SQL または SQL Server 管理ツールを使って、フェールオーバーを行わないでください。 CLUSTER_TYPE = EXTERNAL の場合、FAILOVER_MODE に対して指定できる値は EXTERNAL だけです。 これらの設定では、手動または自動のフェールオーバー操作はすべて、外部クラスター マネージャーによって実行されます。 データ損失の可能性がある強制的なフェールオーバーを実行する手順については、「フェールオーバーを強制的に実行する」をご覧ください。

手動フェールオーバーの手順

フェールオーバーを行うには、プライマリ レプリカになるセカンダリ レプリカが同期されている必要があります。 セカンダリ レプリカが非同期の場合は、可用性モードを変更します。

手動フェールオーバーは 2 つのステップで行います。

1. 最初に、リソースを所有しているクラスター ノードから新しいノードに AG リソースを移動することによって手動でフェールオーバーを行います。

   クラスターによって AG リソースがフェールオーバーされ、場所の制約が追加されます。 この制約により、新しいノードで実行されるようにリソースが構成されます。 後で正常にフェールオーバーを行うには、この制約を削除します。

2. 次に、場所の制約を削除します。

手順 1. 可用性グループ リソースを移動することにより手動でフェールオーバーを行う

ag_cluster という名前の AG リソースを nodeName2 という名前のクラスター ノードに手動でフェールオーバーするには、ディストリビューションに適したコマンドを実行します。

• 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 クラスターのフェールオーバーの動作には影響しません。 リソースを移動するときに --lifetime オプションを使用しない場合は、次のセクションに示すように、自動的に追加される場所の制約を削除する必要があります。

ステップ 2. 場所の制約の削除

手動フェールオーバーの間に、pcs のコマンド move または crm のコマンド migrate によって、新しいターゲット ノードに配置されるリソースに対する場所の制約が追加されます。 新しい制約を表示するには、リソースを手動で移動した後に次のコマンドを実行します。

• RHEL/Ubuntu の例

  sudo pcs constraint list --full
  

• SLES の例

  crm config show
  

  手動フェールオーバーによって作成される制約の例を次に示します。

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

  Note

  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
  

  また、次のように、自動生成された制約の移動と消去の両方を 1 行で実行することもできます。 次の例では、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
  

Note

自動フェールオーバーでは場所の制約が追加されないため、クリーンアップは不要です。

詳細情報:

• Red Hat - クラスター リソースの管理
• Pacemaker - 手動でのリソースの移動
• SLES 管理ガイド - クラスター リソースの管理

フェールオーバーを強制的に実行する

強制フェールオーバーは、厳密にディザスター リカバリーを目的としたものです。 この場合、プライマリ データセンターがダウンしているため、クラスター管理ツールでフェールオーバーを行うことはできません。 非同期のセカンダリ レプリカに対して強制フェールオーバーを実行した場合、データ損失の可能性があります。 強制フェールオーバーは、AG にサービスをすぐに復元する必要があり、データが失われてもかまわない場合に限り、実行してください。

たとえばプライマリ データ センターでの障害のためにクラスターが応答しないときなど、クラスター管理ツールを使ってクラスターを操作できない場合は、フェールオーバーを強制的に行って、外部クラスター マネージャーをバイパスすることが必要になる場合があります。 この手順は、データ損失のリスクがあるため、通常の操作にはお勧めしません。 クラスター管理ツールでフェールオーバー アクションを実行できないときに使用してください。 機能的には、この手順は、Windows の AG で強制手動フェールオーバーを実行することと似ています。

この強制フェールオーバーのプロセスは、SQL Server on Linux に固有のものです。

1. クラスターが AG リソースを管理しなくなったことを確認します。

   • ターゲット クラスター ノードで、リソースをアンマネージド モードに設定します。 このコマンドでは、リソースの監視と管理を停止するように、リソース エージェントに通知されます。 次に例を示します。

     sudo pcs resource unmanage <resourceName>
     

   • リソース モードをアンマネージド モードに設定しようとして失敗する場合は、リソースを削除します。 次に例を示します。

     sudo pcs resource delete <resourceName>
     

     注意

     リソースを削除すると、関連付けられているすべての制約も削除されます。

2. セカンダリ レプリカがホストされている SQL Server のインスタンスで、セッション コンテキスト変数 external_cluster を設定します。

   EXEC sp_set_session_context @key = N'external_cluster', @value = N'yes';
   

3. Transact-SQL で AG をフェールオーバーします。 次の例では、<MyAg> を実際の AG の名前に置き換えます。 ターゲット セカンダリ レプリカがホストされている SQL Server のインスタンスに接続し、次のコマンドを実行します。

   ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

4. 強制フェールオーバーの後、クラスター リソースの監視と管理を再開する前、または AG リソースを再作成する前に、AG を正常な状態にします。 「強制フェールオーバー後の必須タスク」を確認してください。

5. クラスター リソースの監視と管理を再開します。

   クラスター リソースの監視と管理を再開するには、次のコマンドを実行します。

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

   クラスター リソースを削除した場合は、作成し直します。 クラスター リソースを再作成するには、「可用性グループのリソースを作成する」の手順に従います。

重要

データが失われる可能性があるため、ディザスター リカバリー訓練に対する前の手順は使用しないでください。 代わりに、非同期レプリカを同期に変更し、通常の手動フェールオーバーの手順に従います。

データベース レベルの監視とフェールオーバーのトリガー

CLUSTER_TYPE=EXTERNAL の場合、フェールオーバー トリガーのセマンティクスは WSFC の場合と異なります。 AG が WSFC 内の SQL Server のインスタンス上にある場合、状態がデータベースに対する ONLINE から変わると、AG の正常性でエラーが報告されます。 それに対して、クラスター マネージャーでフェールオーバー アクションがトリガーされます。 Linux では、SQL Server インスタンスはクラスターと通信できません。 データベースの正常性の監視は、"アウトサイドイン" で行われます。 ユーザーが (AG の作成時にオプション DB_FAILOVER=ON を設定することにより) データベース レベルのフェールオーバー監視とフェールオーバーにオプトインしている場合、クラスターでは監視アクションが実行されるたびにデータベースの状態が ONLINE であるかどうかがチェックされます。 クラスターでは、sys.databases で状態のクエリが実行されます。 ONLINE 以外の状態の場合は、フェールオーバーが自動的にトリガーされます (自動フェールオーバーの条件が満たされている場合)。 フェールオーバーの実際の時間は、監視アクションの頻度と、sys.databases. で更新されているデータベースの状態によって異なります。

自動フェールオーバーには、少なくとも 1 つの同期レプリカが必要です。

関連するコンテンツ

• SQL Server 可用性グループ クラスター リソースに対して Red Hat Enterprise Linux クラスターを構成する
• SQL Server 可用性グループ クラスター リソースに対して SUSE Linux Enterprise Server クラスターを構成する
• SQL Server 可用性グループ クラスター リソースに対して Ubuntu クラスターを構成する

SQL ドキュメントへの投稿

SQL コンテンツを自分で編集できることはご存じですか。 これにより、ドキュメントが改善されるだけでなく、ページの共同作成者としてもクレジットされます。

詳細については、「SQL Server のドキュメントに投稿する方法」を参照してください。