この記事では、Linux ベースのSQL Serverインストールでの可用性グループ (AG) の特性について説明します。 また、Linux と Windows Server フェールオーバー クラスター (WSFC) ベースの AG の違いについても説明します。 Windows と Linux で同様に動作する AG の基本については、WSFC の違いを除き、Always On 可用性グループとは を参照してください。
注
Windows Server フェールオーバー クラスタリング (WSFC) を使用しない可用性グループ (read-scale 可用性グループ、Linux 上の可用性グループでは、クラスターに関連する 可用性グループ DMV の列に、内部の既定のクラスターに関するデータが表示されることがあります。 これらの列は内部使用のみを目的としており、無視できます。
大まかに言えば、SQL Server on Linuxの可用性グループは WSFC ベースの実装の場合と同じです。 つまり、制限事項や機能は基本的に同じですが、いくつかの例外があります。 主な違いは次のとおりです。
- Microsoft 分散トランザクション コーディネーター (DTC) は、SQL Server 2017 CU 16 以降の Linux でサポートされています。 ただし、Linux 上の可用性グループでは DTC はまだサポートされていません。 アプリケーションで分散トランザクションを使用する必要があり、AG が必要な場合は、WindowsにSQL Serverをデプロイします。
- 高可用性を必要とする Linux ベースのデプロイでは、クラスタリングに WSFC ではなく Pacemaker が使われます。
- ワークグループ クラスター シナリオを除き、Windows上の AG のほとんどの構成とは異なり、Pacemaker では Active Directory Domain Services (AD DS) は必要ありません。
- あるノードから別のノードに AG を失敗させる方法は、Linux とWindowsで異なります。
-
required_synchronized_secondaries_to_commitなどの特定の設定は Linux 上の Pacemaker でのみ変更できますが、WSFC ベースのインストールではTransact-SQLが使用されます。
レプリカとクラスター ノードの数
SQL Server Standard エディションの AG には、2 つの合計レプリカ (1 つのプライマリと、可用性の目的でのみ使用できる 1 つのセカンダリ) を持つことができます。 他の目的 (読み取り可能なクエリなど) には使用できません。 SQL Server Enterprise エディションの AG には、最大 9 つの合計レプリカを含めることができます。1 つのプライマリと最大 8 つのセカンダリで、そのうち最大 3 つ (プライマリを含む) を同期できます。 基になるクラスターを使用している場合で、Corosync が使用されている場合には、最大で 16 個のノードを使用できます。 可用性グループは、SQL Server Enterprise エディションを持つ 16 個のノードのうち最大 9 個、および SQL Server Standard エディションを持つ 2 つのノードにまたがることができます。
レプリカ 2 個の構成で、別のレプリカに自動的にフェールオーバーする機能が必要な場合は、構成専用レプリカを使用する必要があります (「構成専用レプリカとクォーラム」で説明されています)。 構成のみのレプリカは、SQL Server 2017 (14.x) 累積的な更新プログラム 1 (CU 1) で導入されているため、この構成用に展開される最小バージョンである必要があります。
Pacemaker が使用されている場合は、その実行を維持できるように適切に構成する必要があります。 つまり、構成のみのレプリカなどのSQL Serverの要件に加えて、Pacemakerの観点から、クォーラムとフェンシングを含めた失敗したノードの適切な実装が必要です。
読み取り可能なセカンダリ レプリカは、SQL Server Enterprise エディションでのみサポートされます。
クラスターの種類とフェールオーバー モード
SQL Server 2017 (14.x) の新機能は、AG のクラスターの種類の導入です。 Linux の場合、External と None の 2 つの有効な値があります。 "External" というクラスターの種類は、AG の下で Pacemaker が使用されることを意味します。 クラスターの種類に External を使用するには、フェールオーバー モードも外部に設定されている必要があります (SQL Server 2017 (14.x) でも新しいモード)。 自動フェールオーバーはサポートされていますが、WSFC とは異なり、Pacemaker が使用されている場合はフェールオーバー モードが (自動ではなく) External に設定されます。 WSFC とは異なり、AG の Pacemaker 部分は AG の構成後に作成されます。
クラスターの種類が None の場合は、Pacemaker に対する要件がない (AG でも使用されない) ことを意味します。 Pacemaker が構成されているサーバー上でも、クラスターの種類を None にして AG が構成されている場合、Pacemaker ではその AG は表示されず、管理もされません。 クラスターの種類が None の場合は、プライマリからセカンダリ レプリカへの手動フェールオーバーのみがサポートされます。 None で作成された AG は、主にアップグレードと読み取りスケールアウトに使用されます。ディザスター リカバリーやローカルの可用性など、自動フェールオーバーを必要としないシナリオでも機能しますが、推奨はされません。 リスナー ストーリーも、Pacemaker を使わない場合より複雑になります。
クラスターの種類は、SQL Server動的管理ビュー (DMV) sys.availability_groups の列 cluster_type および cluster_type_desc に格納されます。
コミットするために同期が必要なセカンダリ
SQL Server 2017 (14.x) の新機能は、required_synchronized_secondaries_to_commit と呼ばれる AG によって使用される設定です。 これは、プライマリと同期する必要があるセカンダリ レプリカの数を AG に伝えるためのものです。 これにより、自動フェールオーバー などの処理が可能になります (クラスターの種類を External にして Pacemaker と統合されている場合のみ)。また、適切な数のセカンダリ レプリカがオンラインまたはオフラインの場合に、プライマリの可用性などに関する動作を制御できるようになります。 このしくみの詳細については、「可用性グループの構成の高可用性とデータの保護」を参照してください。
required_synchronized_secondaries_to_commitの値は既定で設定され、Pacemaker/SQL Server によって維持されます。 この値は手動でオーバーライドできます。
required_synchronized_secondaries_to_commit と新しいシーケンス番号 (sys.availability_groups に格納) の組み合わせにより、Pacemaker と SQL Server に対して自動フェールオーバーが発生する可能性を伝えます。 その場合、セカンダリ レプリカはプライマリと同じシーケンス番号を持っていることになります。つまり、最新の構成情報がすべて含まれた状態であるということです。
required_synchronized_secondaries_to_commit に設定できる値は、0、1、2 の 3 つです。 これらの値によって、レプリカが使用できなくなったときの動作が制御されます。 これらの数は、プライマリと同期する必要があるセカンダリ レプリカの数に対応しています。 Linux では、動作は次のようになります。
| 設定 | 説明 |
|---|---|
0 |
セカンダリ レプリカがプライマリと同期された状態である必要はありません。 ただし、セカンダリが同期されていない場合、自動フェールオーバーは行われません。 |
1 |
1 つのセカンダリ レプリカがプライマリと同期された状態である必要があります。自動フェールオーバーが可能です。 プライマリ データベースは、セカンダリの同期レプリカが使用可能になるまで使用できません。 |
2 |
3 ノード以上の AG 構成内にある両方のセカンダリ レプリカが、プライマリと同期されている必要があります。自動フェールオーバーが可能です。 |
required_synchronized_secondaries_to_commit は、同期レプリカを使用したフェールオーバーの動作だけでなく、データ損失も制御します。 値が 1 または 2 の場合、データの冗長性を確保するためにセカンダリ レプリカが常に同期されている必要があります。 つまり、データ損失は発生しません。
required_synchronized_secondaries_to_commit の値を変更するには、次の構文を使用します。
注
値を変更すると、リソースが再起動されます。つまり、短時間停止します。 これを回避する唯一の方法は、リソースが一時的にクラスターによって管理されないように設定することです。
Red Hat Enterprise Linux (RHEL) と Ubuntu
sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<value>
SUSE Linux Enterprise Server (SLES)
sudo crm resource param ms-<AGResourceName> set required_synchronized_secondaries_to_commit <value>
注
SQL Server 2025 (17.x) 以降、SUSE Linux Enterprise Server (SLES) はサポートされていません。
この例では、<AGResourceName> は AG 用に構成されているリソースの名前で、<value> は 0、1、または 2 です。 パラメーターを管理する Pacemaker の既定の設定に戻すには、値を指定せずに同じステートメントを実行します。
次の条件が満たされている場合は、AG の自動フェールオーバーが可能です。
- プライマリ レプリカとセカンダリ レプリカが、同期データ移動に設定されている。
- セカンダリは同期中ではなく同期済みの状態である。つまり、2 つのシステムが同じデータ ポイントにある。
- クラスターの種類が External に設定されている。 クラスターの種類が None の場合、自動フェールオーバーは実行できません。
- プライマリになるセカンダリ レプリカの
sequence_numberが、最大のシーケンス番号になっている。つまり、セカンダリ レプリカのsequence_numberが、元のプライマリ レプリカの番号と一致している。
これらの条件が満たされている場合、プライマリ レプリカをホストしているサーバーで障害が発生すると、AG は所有者を同期レプリカに変更します。 同期レプリカ (1 つのプライマリ レプリカと 2 つのセカンダリ レプリカで合計 3 つ) の動作は、required_synchronized_secondaries_to_commit によってさらに制御することができます。 これは、Windowsと Linux の両方の AG で動作しますが、構成は異なります。 Linux の場合、この値は AG リソース自体のクラスターによって自動的に構成されます。
構成専用レプリカとクォーラム
Pacemaker でのクォーラム処理 (特に障害が発生したノードをフェンスする場合) の制限に対処するために、構成専用レプリカが導入されました。 AG では、2 ノード構成だけでは機能しません。 FCI の場合、Pacemaker によって提供されるクォーラム メカニズムは問題ありません。これは、すべての FCI フェールオーバーのアービトレーションがクラスター レイヤーで行われるためです。 AG の場合、Linux での判定は、すべてのメタデータが格納されているSQL Serverで行われます。 そこで必要となるのが、構成専用レプリカです。
3 つ目のノードと、少なくとも 1 つの同期されたレプリカがどうしても必要となります。 構成専用レプリカは、AG 構成内の他のレプリカと同じように、AG 構成を master データベースに格納します。 構成専用レプリカでは、AG に参加しているユーザー データベースは保持されません。 構成データは、プライマリから同期的に送信されます。 この構成データは、自動か手動かにかかわらず、フェールオーバー中に使用されます。
AG でクォーラムを維持し、External のクラスターで自動フェールオーバーを有効にするには、次のいずれかが必要です。
- 三つの同期レプリカ (SQL Server Enterprise エディションのみ対応) または
- 2 つのレプリカ (プライマリとセカンダリ) と、構成専用レプリカがある。
手動フェールオーバーは、AG 構成に使用しているクラスターの種類が External か None かにかかわらず実行できます。 構成専用レプリカは、クラスターの種類が None の AG でも構成できますが、デプロイが複雑になるため推奨されません。 そのように構成する場合は、値が少なくとも 1 になるように required_synchronized_secondaries_to_commit を手動で変更して、同期されたレプリカが少なくとも 1 つ存在するようにしてください。
構成専用レプリカは、SQL Server Express を含む任意のエディションのSQL Serverでホストできます。 これにより、ライセンス コストが最小限に抑えられます。これにより、SQL Server Standard エディションの AG で動作することが保証されます。 つまり、3 番目に必要なサーバーは、AG のユーザー トランザクション トラフィックを受信していないため、SQL Serverの最小仕様を満たす必要があります。
構成専用レプリカを使用する場合、その動作は次のようになります。
既定では、
required_synchronized_secondaries_to_commitは 0 に設定されています。 これは、必要に応じて手動で 1 に変更できます。プライマリで障害が発生し、
required_synchronized_secondaries_to_commitが 0 の場合は、セカンダリ レプリカが新しいプライマリになり、読み取りと書き込みの両方に使用できるようになります。 値が 1 の場合は、自動フェールオーバーが実行されますが、他のレプリカがオンラインになるまで新しいトランザクションは受け入れられません。セカンダリ レプリカで障害が発生し、
required_synchronized_secondaries_to_commitが 0 の場合、プライマリ レプリカは引き続きトランザクションを受け入れますが、その時点でプライマリ レプリカに障害が発生した場合は、セカンダリ レプリカが使用できないため、データ保護もフェールオーバーも (手動と自動のいずれを問わず) 提供されません。構成専用レプリカで障害が発生した場合、AG は正常に機能しますが、自動フェールオーバーは実行できません。
同期セカンダリ レプリカと構成専用レプリカの両方で障害が発生した場合、プライマリはトランザクションを受け付けることができず、プライマリからのフェールオーバー先もなくなります。
複数の可用性グループ
AG は、Pacemaker クラスターまたは一連のサーバーごとに複数作成できます。 唯一の制限は、システム リソースです。 AG の所有権はプライマリによって示されます。 複数の AG を異なるノードで所有することもできます。それらがすべて同じノードで実行されている必要はありません。
データベースのドライブとフォルダーの場所
Windows ベースの AG と同様に、AG に参加しているユーザー データベースのドライブとフォルダー構造は同じである必要があります。 たとえば、ユーザー データベースがサーバー A の /var/opt/mssql/userdata にある場合、その同じフォルダーがサーバー B に存在する必要があります。これに対する唯一の例外は、「Windows ベースの可用性グループとレプリカを使用した相互運用に関するセクションに示されています。
Linuxにおけるリスナー
リスナーは、AG のオプション機能です。 これは、すべての接続 (プライマリ レプリカへの読み取り/書き込み接続や、セカンダリ レプリカへの読み取り専用接続) に対する単一のエントリ ポイントを提供するものです。これにより、アプリケーションとエンド ユーザーは、どのサーバーがデータをホストしているのかを認識しなくて済むようになります。 WSFC では、これはネットワーク名リソースと IP リソースの組み合わせであり、AD DS (必要な場合) と DNS に登録されます。 この抽象化は、AG リソース自体との組み合わせによって提供されます。 リスナーの詳細については、「Always On 可用性グループ リスナーに接続する」を参照してください。
Linux ではリスナーの構成方法が異なりますが、その機能は同じです。 Pacemaker にはネットワーク名リソースの概念がなく、AD DS で作成されたオブジェクトもありません。Pacemaker で作成された IP アドレス リソースしかなく、それらを任意のノードで実行できます。 "フレンドリ名" を使用して、DNS 内のリスナーの IP リソースに関連付けられたエントリを作成する必要があります。 リスナーの IP リソースは、その可用性グループのプライマリ レプリカをホストしているサーバー上でのみアクティブになります。
Pacemaker が使用されていて、リスナーに関連付けられた IP アドレス リソースが作成されている場合は、1 つのサーバーで IP アドレスが停止し、もう 1 つのサーバーで起動する際に、システムがしばらく停止します (フェールオーバーが自動か手動かにかかわらず)。 これにより、単一の名前と IP アドレスの組み合わせによる抽象化が提供されますが、システム停止はマスクされません。 アプリケーションでは、この問題を検出して再接続するための何らかの機能を設けて、切断に対応できるようにする必要があります。
ただし、DNS 名と IP アドレスを組み合わせても、WSFC のリスナーで提供されるすべての機能 (セカンダリ レプリカのための読み取り専用ルーティングなど) を提供するのに十分ではありません。 AG を構成する場合でも、リスナーを SQL Server で構成する必要があります。 これは、ウィザードとTransact-SQL構文で確認できます。 Windowsの場合と同じように機能するように構成するには、次の 2 つの方法があります。
- クラスターの種類が External の AG の場合、SQL Serverで作成されたリスナーに関連付けられている IP アドレスは、Pacemaker で作成されたリソースの IP アドレスである必要があります。
- クラスターの種類を None にして作成された AG の場合は、プライマリ レプリカに関連付けられた IP アドレスを使用します。
指定された IP アドレスに関連付けられたインスタンスは、アプリケーションからの読み取り専用ルーティング要求などに対するコーディネーターになります。
Windows ベースの可用性グループとレプリカとの相互運用性
クラスターの種類が External または WSFC である AG では、そのレプリカをクロスプラットフォームにすることはできません。 これは、AG が Standard エディションSQL Server場合でも、Enterprise エディションSQL Server場合にも当てはまります。 つまり、基になるクラスターを持つ従来の AG 構成では、一方のレプリカを WSFC に配置し、もう一方のレプリカを、Pacemaker を使用して Linux 上に配置することはできません。
クラスターの種類が NONE の AG は、そのレプリカが OS の境界を越える可能性があるため、同じ AG に Linux ベースと Windows ベースのレプリカの両方が存在する可能性があります。 プライマリ レプリカが Windows ベースで、セカンダリが Linux ディストリビューションの 1 つにある場合の例を次に示します。
分散型 AG も、OS 境界をまたぐことができます。 基になる AG は、構成方法に関する規則によって制約を受けます (External で構成されたものは Linux のみだが、それが参加している AG は WSFC を使用して構成できるなど)。 次の例を確認してください。
