Linux 上の AlwaysOn 可用性グループAlways On Availability Groups on Linux

適用対象: ○SQL Server (Linux のみ) ×Azure SQL Database ×Azure SQL Data Warehouse ×Parallel Data Warehouse APPLIES TO: yesSQL Server (Linux only) noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

この記事では、Linux ベースの SQL ServerSQL Server インストールでの、Always On 可用性グループ (AG) の特性について説明します。This article describes the characteristics of Always On Availability Groups (AGs) under Linux-based SQL ServerSQL Server installations. また、Linux ベースの AG と、Windows Server フェールオーバー クラスター (WSFC) ベースの AG の違いについても説明します。It also covers differences between Linux- and Windows Server failover cluster (WSFC)-based AGs. AG の基本については、Windows ベースのドキュメントを参照してください (WSFC を除き、AG は Windows 上でも Linux 上でも同様に機能します)。See the Windows-based documentation for the basics of AGs, as they work the same on Windows and Linux except for the WSFC.

全体的に見ると、Linux 上の SQL ServerSQL Server の可用性グループは、WSFC ベースの実装で使用する場合と同様に機能します。From a high-level standpoint, availability groups under SQL ServerSQL Server on Linux are the same as they are on WSFC-based implementations. つまり、制限事項や機能は基本的に同じですが、いくつかの例外があります。That means that all the limitations and features are the same, with some exceptions. 主な違いは次のとおりです。The main differences include:

  • SQL Server 2017 CU16 以降では、Linux で Microsoft 分散トランザクション コーディネーター (DTC) がサポートされています。Microsoft Distributed Transaction Coordinator (DTC) is supported under Linux starting with SQL Server 2017 CU16. ただし、Linux 上の可用性グループでは DTC はまだサポートされていません。However, DTC is not yet supported on Availability Groups on Linux. アプリケーションで分散トランザクションを使用する必要があり、AG が必要な場合は、Windows 上で SQL ServerSQL Server をデプロイしてください。If your applications require the use of distributed transactions and need an AG, deploy SQL ServerSQL Server on Windows.
  • 高可用性を必要とする Linux ベースのデプロイでは、クラスタリングに WSFC ではなく Pacemaker が使われます。Linux-based deployments that require high availability use Pacemaker for clustering instead of a WSFC.
  • Windows 上の AG のほとんどの構成 (ワークグループクラスターのシナリオを除く) とは異なり、Pacemaker では Active Directory Domain Services (AD DS) が必要とされることはありません。Unlike most configurations for AGs on Windows except for the Workgroup Cluster scenario, Pacemaker never requires Active Directory Domain Services (AD DS).
  • 1 つのノードから別のノードに AG をフェールオーバーする方法は、Linux と Windows で異なります。How to fail an AG from one node to another is different between Linux and Windows.
  • 特定の設定 (required_synchronized_secondaries_to_commit など) は、Linux 上の Pacemaker を使用してのみ変更できます。一方、WSFC ベースのインストールでは Transact-SQL を使用します。Certain settings such as required_synchronized_secondaries_to_commit can only be changed via Pacemaker on Linux, whereas a WSFC-based install uses Transact-SQL.

レプリカとクラスター ノードの数Number of replicas and cluster nodes

SQL Server StandardSQL Server Standard 内の AG には、2 つのレプリカを含めることができます。1 つはプライマリ、もう 1 つは可用性の目的にのみ使用できます。An AG in SQL Server StandardSQL Server Standard can have two total replicas: one primary, and one secondary that can only be used for availability purposes. 他の目的 (読み取り可能なクエリなど) には使用できません。It cannot be used for anything else, such as readable queries. SQL Server EnterpriseSQL Server Enterprise 内の AG は、最大 9 個のレプリカを持つことができます。1 つのプライマリと最大 8 つのセカンダリで構成し、最大 3 つ (プライマリを含む) を同期できます。An AG in SQL Server EnterpriseSQL Server Enterprise can have up to nine total replicas: one primary and up to eight secondaries, of which up to three (including the primary) can be synchronous. 基になるクラスターを使用している場合で、Corosync が使用されている場合には、最大で 16 個のノードを使用できます。If using an underlying cluster, there can be a maximum of 16 nodes total when Corosync is involved. 可用性グループでは、SQL Server EnterpriseSQL Server Enterprise なら 16 ノードのうち最大 9 ノードを使用でき、SQL Server StandardSQL Server Standard なら 2 ノードまで使用できます。An availability group can span at most nine of the 16 nodes with SQL Server EnterpriseSQL Server Enterprise, and two with SQL Server StandardSQL Server Standard.

レプリカ 2 個の構成で、別のレプリカに自動的にフェールオーバーする機能が必要な場合は、構成専用レプリカを使用する必要があります (「構成専用レプリカとクォーラム」で説明されています)。A two-replica configuration that requires the ability to automatically fail over to another replica requires the use of a configuration-only replica, as described in Configuration-only replica and quorum. 構成専用レプリカは SQL Server 2017 (14.x)SQL Server 2017 (14.x) Cumulative Update 1 (CU1) で導入されたので、このバージョンが、この構成用にデプロイできる最低のバージョンになります。Configuration-only replicas were introduced in SQL Server 2017 (14.x)SQL Server 2017 (14.x) Cumulative Update 1 (CU1), so that should be the minimum version deployed for this configuration.

Pacemaker が使用されている場合は、その実行を維持できるように適切に構成する必要があります。If Pacemaker is used, it must be properly configured so it remains up and running. つまり、SQL ServerSQL Server の要件 (構成専用レプリカなど) に加えて、Pacemaker の観点からクォーラムと STONITH を適切に実装する必要があります。That means that quorum and STONITH must be implemented properly from a Pacemaker perspective, in addition to any SQL ServerSQL Server requirements such as a configuration-only replica.

読み取り可能なセカンダ リレプリカは、SQL Server EnterpriseSQL Server Enterprise でのみサポートされます。Readable secondary replicas are only supported with SQL Server EnterpriseSQL Server Enterprise.

クラスターの種類とフェールオーバー モードCluster type and failover mode

SQL Server 2017 (14.x)SQL Server 2017 (14.x) では、AG のクラスターの種類が新たに導入されました。New to SQL Server 2017 (14.x)SQL Server 2017 (14.x) is the introduction of a cluster type for AGs. Linux の場合、有効な値は次の 2 つです。External と None。For Linux, there are two valid values: External and None. "External" というクラスターの種類は、AG の下で Pacemaker が使用されることを意味します。A cluster type of External means that Pacemaker will be used underneath the AG. クラスターの種類として External を使用するには、フェールオーバー モードも External に設定する必要があります (これも SQL Server 2017 (14.x)SQL Server 2017 (14.x) の新機能です)。Using External for cluster type requires that the failover mode be set to External as well (also new in SQL Server 2017 (14.x)SQL Server 2017 (14.x)). 自動フェールオーバーはサポートされていますが、WSFC とは異なり、Pacemaker が使用されている場合はフェールオーバー モードが (自動ではなく) External に設定されます。Automatic failover is supported, but unlike a WSFC, failover mode is set to External, not automatic, when Pacemaker is used. WSFC とは異なり、AG の Pacemaker 部分は AG の構成後に作成されます。Unlike a WSFC, the Pacemaker portion of the AG is created after the AG is configured.

クラスターの種類が None の場合は、Pacemaker に対する要件がない (AG でも使用されない) ことを意味します。A cluster type of None means that there is no requirement for, nor will the AG use, Pacemaker. Pacemaker が構成されているサーバー上でも、クラスターの種類を None にして AG が構成されている場合、Pacemaker ではその AG は表示されず、管理もされません。Even on servers that have Pacemaker configured, if an AG is configured with a cluster type of None, Pacemaker will not see or manage that AG. クラスターの種類が None の場合は、プライマリからセカンダリ レプリカへの手動フェールオーバーのみがサポートされます。A cluster type of None only supports manual failover from a primary to a secondary replica. None で作成された AG は、主に読み取りスケールアウトのシナリオやアップグレードに使用されます。An AG created with None is primarily targeted for the read-scale out scenario as well as upgrades. ディザスター リカバリーやローカルの可用性など、自動フェールオーバーを必要としないシナリオでも機能しますが、推奨はされません。While it can work in scenarios like disaster recovery or local availability where no automatic failover is necessary, it is not recommended. リスナーの取り扱いも、Pacemaker を使わない場合より複雑になります。The listener story is also more complex without Pacemaker.

クラスターの種類は、SQL ServerSQL Server 動的管理ビュー (DMV) sys.availability_groupscluster_typecluster_type_desc の列に格納されます。Cluster type is stored in the SQL ServerSQL Server dynamic management view (DMV) sys.availability_groups, in the columns cluster_type and cluster_type_desc.


SQL Server 2017 (14.x)SQL Server 2017 (14.x) では、AG によって使用される、required_synchronized_secondaries_to_commit という設定が新たに導入されました。New to SQL Server 2017 (14.x)SQL Server 2017 (14.x) is a setting that is used by AGs called required_synchronized_secondaries_to_commit. これは、プライマリと同期する必要があるセカンダリ レプリカの数を AG に伝えるためのものです。This tells the AG the number of secondary replicas that must be in lockstep with the primary. これにより、自動フェールオーバー などの処理が可能になります (クラスターの種類を External にして Pacemaker と統合されている場合のみ)。また、適切な数のセカンダリ レプリカがオンラインまたはオフラインの場合に、プライマリの可用性などに関する動作を制御できるようになります。This enables things like automatic failover (only when integrated with Pacemaker with a cluster type of External), and controls the behavior of things like the availability of the primary if the right number of secondary replicas is either online or offline. このしくみの詳細については、「可用性グループの構成の高可用性とデータの保護」を参照してください。To understand more about how this works, see High availability and data protection for availability group configurations. required_synchronized_secondaries_to_commit の値は既定で設定され、Pacemaker/ SQL ServerSQL Server によって管理されます。The required_synchronized_secondaries_to_commit value is set by default and maintained by Pacemaker/ SQL ServerSQL Server. この値は手動でオーバーライドできます。You can manually override this value.

required_synchronized_secondaries_to_commit と新しいシーケンス番号 (sys.availability_groups に格納されます) の組み合わせにより、たとえば、自動フェールオーバーを実行できることが Pacemaker と SQL ServerSQL Server に通知されます。The combination of required_synchronized_secondaries_to_commit and the new sequence number (which is stored in sys.availability_groups) informs Pacemaker and SQL ServerSQL Server that, for example, automatic failover can happen. その場合、セカンダリ レプリカはプライマリと同じシーケンス番号を持っていることになります。つまり、最新の構成情報がすべて含まれた状態であるということです。In that case, a secondary replica would have the same sequence number as the primary, meaning it is up to date with all the latest configuration information.

required_synchronized_secondaries_to_commit に設定できる値は、次の 3 つです。0、1、2 のいずれか。There are three values that can be set for required_synchronized_secondaries_to_commit: 0, 1, or 2. これらの値によって、レプリカが使用できなくなったときの動作が制御されます。They control the behavior of what happens when a replica becomes unavailable. これらの数は、プライマリと同期する必要があるセカンダリ レプリカの数に対応しています。The numbers correspond to the number of secondary replicas that must be synchronized with the primary. Linux では、動作は次のようになります。The behavior is as follows under Linux:

  • 0 - セカンダ リレプリカがプライマリと同期された状態である必要はありません。0 - Secondary replicas do not need to be in synchronized state with the primary. ただし、セカンダリが同期されていない場合、自動フェールオーバーは行われません。However if the secondaries are not synchronized, there will be no automatic failover.
  • 1 - 1 つのセカンダリ レプリカがプライマリと同期された状態である必要があります。自動フェールオーバーが可能です。1 - One secondary replica must be in a synchronized state with the primary; automatic failover is possible. プライマリ データベースは、セカンダリの同期レプリカが使用可能になるまで使用できません。The primary database is unavailable until a secondary synchronous replica is available.
  • 2 - 3 ノード以上の AG 構成内にある両方のセカンダリ レプリカが、プライマリと同期されている必要があります。自動フェールオーバーが可能です。2 - Both secondary replicas in a three or more node AG configuration must be synchronized with the primary; automatic failover is possible.

required_synchronized_secondaries_to_commit は、同期レプリカを使用したフェールオーバーの動作だけでなく、データ損失も制御します。required_synchronized_secondaries_to_commit controls not only the behavior of failovers with synchronous replicas, but data loss. 値が 1 または 2 の場合、セカンダリ レプリカは常に同期されていることを要求されるため、常にデータの冗長性が確保されます。With a value of 1 or 2, a secondary replica is always required to be synchronized, so there will always be data redundancy. つまり、データ損失は発生しません。That means no data loss.

required_synchronized_secondaries_to_commit の値を変更するには、次の構文を使用します。To change the value of required_synchronized_secondaries_to_commit, use the following syntax:


値を変更すると、リソースが再起動されます。つまり、短時間停止します。Changing the value causes the resource to restart, meaning a brief outage. これを回避する唯一の方法は、リソースが一時的にクラスターによって管理されないように設定することです。The only way to avoid this is to set the resource to not be managed by the cluster temporarily.

Red Hat Enterprise Linux (RHEL) と UbuntuRed Hat Enterprise Linux (RHEL) and Ubuntu

sudo pcs resource update <AGResourceName> required_synchronized_secondaries_to_commit=<Value>

SUSE Linux Enterprise Server (SLES)SUSE Linux Enterprise Server (SLES)

sudo crm resource param ms-<AGResourceName> set required_synchronized_secondaries_to_commit <value>

ここで、AGResourceName は AG 用に構成されているリソースの名前で、Value は 0、1、または 2 です。where AGResourceName is the name of the resource configured for the AG, and Value is 0, 1, or 2. パラメーターを管理する Pacemaker の既定の設定に戻すには、値を指定せずに同じステートメントを実行します。To set it back to the default of Pacemaker managing the parameter, execute the same statement with no value.

次の条件が満たされている場合は、AG の自動フェールオーバーが可能です。Automatic failover of an AG is possible when the following conditions are met:

  • プライマリ レプリカとセカンダリ レプリカが、同期データ移動に設定されている。The primary and the secondary replica are set to synchronous data movement.
  • セカンダリが (同期中ではなく) 同期済みの状態である。つまり、2 つが同じデータ ポイントにある。The secondary has a state of synchronized (not synchronizing), meaning the two are at the same data point.
  • クラスターの種類が External に設定されている。The cluster type is set to External. クラスターの種類が None の場合、自動フェールオーバーは実行できません。Automatic failover is not possible with a cluster type of None.
  • プライマリになるセカンダリ レプリカの sequence_number が、最大のシーケンス番号になっている。つまり、セカンダリ レプリカの sequence_number が、元のプライマリ レプリカの番号と一致している。The sequence_number of the secondary replica to become the primary has the highest sequence number - in other words, the secondary replica's sequence_number matches the one from the original primary replica.

これらの条件が満たされている場合、プライマリ レプリカをホストしているサーバーで障害が発生すると、AG は所有者を同期レプリカに変更します。If these conditions are met and the server hosting the primary replica fails, the AG will change ownership to a synchronous replica. 同期レプリカ (1 つのプライマリ レプリカと 2 つのセカンダリ レプリカで合計 3 つ) の動作は、required_synchronized_secondaries_to_commit によってさらに制御することができます。The behavior for synchronous replicas (of which there can be three total: one primary and two secondary replicas) can further be controlled by required_synchronized_secondaries_to_commit. この設定は、Windows と Linux の両方で AG と連携しますが、構成の方法はまったく異なります。This works with AGs on both Windows and Linux, but is configured completely differently. Linux の場合、この値は AG リソース自体のクラスターによって自動的に構成されます。On Linux, the value is configured automatically by the cluster on the AG resource itself.

構成専用レプリカとクォーラムConfiguration-only replica and quorum

SQL Server 2017 (14.x)SQL Server 2017 (14.x) CU1 では、構成専用レプリカも新しく導入されました。Also new in SQL Server 2017 (14.x)SQL Server 2017 (14.x) as of CU1 is a configuration-only replica. Pacemaker は WSFC とは異なり、特にクォーラムと STONITH の使用に関しては大きく異なるため、2 ノードのみの構成では AG との連携が機能しません。Because Pacemaker is different than a WSFC, especially when it comes to quorum and requiring STONITH, having just a two-node configuration will not work when it comes to an AG. FCI については、Pacemaker で提供されるクォーラム メカニズムで問題ありません。これは、 FCI のフェールオーバーのアービトレーションがすべてクラスター レイヤーで行われるためです。For an FCI, the quorum mechanisms provided by Pacemaker can be fine, because all FCI failover arbitration happens at the cluster layer. AG の場合、Linux でのアービトレーションは、すべてのメタデータが格納されている SQL ServerSQL Server 内で発生します。For an AG, arbitration under Linux happens in SQL ServerSQL Server, where all the metadata is stored. そこで必要となるのが、構成専用レプリカです。This is where the configuration-only replica comes into play.

3 つ目のノードと、少なくとも 1 つの同期されたレプリカがどうしても必要となります。Without anything else, a third node and at least one synchronized replica would be required. 構成専用レプリカは、AG 構成内の他のレプリカと同じように、AG 構成を master データベースに格納します。The configuration-only replica stores the AG configuration in the master database, same as the other replicas in the AG configuration. 構成専用レプリカでは、AG に参加しているユーザー データベースは保持されません。The configuration-only replica does not have the user databases participating in the AG. 構成データは、プライマリから同期的に送信されます。The configuration data is sent synchronously from the primary. この構成データは、自動か手動かにかかわらず、フェールオーバー中に使用されます。This configuration data is then used during failovers, whether they are automatic or manual.

AG でクォーラムを維持し、External のクラスターについて自動フェールオーバーを有効にするには、次のいずれかの条件を満たす必要があります。For an AG to maintain quorum and enable automatic failovers with a cluster type of External, it either must:

  • 3 つの同期レプリカがある (SQL Server EnterpriseSQL Server Enterprise のみ)。またはHave three synchronous replicas (SQL Server EnterpriseSQL Server Enterprise only); or
  • 2 つのレプリカ (プライマリとセカンダリ) と、構成専用レプリカがある。Have two replicas (primary and secondary) as well as a configuration only replica.

手動フェールオーバーは、AG 構成に使用しているクラスターの種類が External か None かにかかわらず実行できます。Manual failovers can happen whether using External or None cluster types for AG configurations. 構成専用レプリカは、クラスターの種類が None の AG でも構成できますが、デプロイが複雑になるため推奨されません。While a configuration-only replica can be configured with an AG that has a cluster type of None, it is not recommended, since it complicates the deployment. そのように構成する場合は、値が少なくとも 1 になるように required_synchronized_secondaries_to_commit を手動で変更して、同期されたレプリカが少なくとも 1 つ存在するようにしてください。For those configurations, manually modify required_synchronized_secondaries_to_commit to have a value of at least 1, so that there is at least one synchronized replica.

構成専用レプリカは、SQL ServerSQL Server の任意のエディション (SQL Server ExpressSQL Server Express を含む) でホストできます。A configuration-only replica can be hosted on any edition of SQL ServerSQL Server, including SQL Server ExpressSQL Server Express. そのため、ライセンス コストを最小限に抑えつつ、SQL Server StandardSQL Server Standard の AG で動作させることができます。This will minimize licensing costs and ensures it works with AGs in SQL Server StandardSQL Server Standard. つまり、3 つ目の必須サーバーでは、SQL ServerSQL Server の最小の仕様を満たすだけで済みます (AG のユーザー トランザクション トラフィックを受信しないため)。This means that the third required server just needs to meet the minimum specification for SQL ServerSQL Server, since it is not receiving user transaction traffic for the AG.

構成専用レプリカを使用する場合、その動作は次のようになります。When a configuration-only replica is used, it has the following behavior:

  • 既定では、required_synchronized_secondaries_to_commit は 0 に設定されています。By default, required_synchronized_secondaries_to_commit is set to 0. これは、必要に応じて手動で 1 に変更できます。This can be manually modified to 1 if desired.
  • プライマリで障害が発生し、required_synchronized_secondaries_to_commit が 0 の場合は、セカンダリ レプリカが新しいプライマリになり、読み取りと書き込みの両方に使用できるようになります。If the primary fails and required_synchronized_secondaries_to_commit is 0, the secondary replica will become the new primary and be available for both reading and writing. 値が 1 の場合は、自動フェールオーバーが実行されますが、他のレプリカがオンラインになるまで新しいトランザクションは受け入れられません。If the value is 1, automatic failover will occur, but will not accept new transactions until the other replica is online.
  • セカンダリ レプリカで障害が発生し、required_synchronized_secondaries_to_commit が 0 の場合、プライマリ レプリカは引き続きトランザクションを受け入れますが、その時点でプライマリ レプリカに障害が発生した場合は、セカンダリ レプリカが使用できないため、データ保護もフェールオーバーも (手動と自動のいずれを問わず) 提供されません。If a secondary replica fails and required_synchronized_secondaries_to_commit is 0, the primary replica still accepts transactions, but if the primary fails at this point, there is no protection for the data nor failover possible (manual or automatic), since a secondary replica is not available.
  • 構成専用レプリカで障害が発生した場合、AG は正常に機能しますが、自動フェールオーバーは実行できません。If the configuration-only replicas fails, the AG will function normally, but no automatic failover is possible.
  • 同期セカンダリ レプリカと構成専用レプリカの両方で障害が発生した場合、プライマリはトランザクションを受け付けることができず、プライマリからのフェイルオーバー先もなくなります。If both a synchronous secondary replica and the configuration-only replica fail, the primary cannot accept transactions, and there is nowhere for the primary to fail to.

CU1 では、mssql-server-ha によって生成される corosync.log ファイルのログに既知のバグがあります。In CU1 there is a known bug in the logging in the corosync.log file that is generated via mssql-server-ha. 使用可能なレプリカの数が原因でセカンダリ レプリカがプライマリになることができない場合、現在のメッセージは "1 つのシーケンス番号を受け取る必要がありましたが、2 つしか受信されませんでした。If a secondary replica is not able to become the primary due to the number of required replicas available, the current message says "Expected to receive 1 sequence numbers but only received 2. ローカル レプリカを安全に昇格させるための十分なレプリカがオンラインになっていません。" です。Not enough replicas are online to safely promote the local replica." これらの数は逆にする必要があります。正しいメッセージは次のとおりです: "2 つのシーケンス番号を受け取る必要がありましたが、1 つしか受信されませんでした。The numbers should be reversed, and it should say "Expected to receive 2 sequence numbers but only received 1. ローカル レプリカを安全に昇格させるための十分なレプリカがオンラインになっていません。"Not enough replicas are online to safely promote the local replica."

複数の可用性グループMultiple availability groups

AG は、Pacemaker クラスターまたは一連のサーバーごとに複数作成できます。More than one AG can be created per Pacemaker cluster or set of servers. 唯一の制限は、システム リソースです。The only limitation is system resources. AG の所有権はマスターによって示されます。AG ownership is shown by the master. 複数の AG を異なるノードで所有することもできます。それらがすべて同じノードで実行されている必要はありません。Different AGs can be owned by different nodes; they do not all need to be running on the same node.

データベースのドライブとフォルダーの場所Drive and folder location for databases

Windows ベースの AG の場合と同様に、AG に参加しているユーザー データベースのドライブとフォルダーの構造は同じである必要があります。As on Windows-based AGs, the drive and folder structure for the user databases participating in an AG should be identical. たとえば、ユーザー データベースがサーバー A 上の /var/opt/mssql/userdata にある場合は、それと同じフォルダーがサーバー B にも存在する必要があります。これに関する唯一の例外については、「Windows ベースの可用性グループとレプリカとの相互運用性」に記載されています。For example, if the user databases are in /var/opt/mssql/userdata on Server A, that same folder should exist on Server B. The only exception to this is noted in the section Interoperability with Windows-based availability groups and replicas.

Linux 下のリスナーThe listener under Linux

リスナーは、AG のオプション機能です。The listener is optional functionality for an AG. これは、すべての接続 (プライマリ レプリカへの読み取り/書き込み接続や、セカンダリ レプリカへの読み取り専用接続) に対する単一のエントリ ポイントを提供するものです。これにより、アプリケーションとエンド ユーザーは、どのサーバーがデータをホストしているのかを認識しなくて済むようになります。It provides a single point of entry for all connections (read/write to the primary replica and/or read-only to secondary replicas) so that applications and end users do not need to know which server is hosting the data. WSFC では、これはネットワーク名リソースと IP リソースの組み合わせであり、AD DS (必要な場合) と DNS に登録されます。In a WSFC, this is the combination of a network name resource and an IP resource, which is then registered in AD DS (if needed) as well as DNS. この抽象化は、AG リソース自体との組み合わせによって提供されます。In combination with the AG resource itself, it provides that abstraction. リスナーの詳細については、「リスナー、クライアント接続、およびアプリケーションのフェールオーバー」を参照してください。For more information on a listener, see Listeners, Client Connectivity, and Application Failover.

Linux ではリスナーの構成方法が異なりますが、その機能は同じです。The listener under Linux is configured differently, but its functionality is the same. Pacemaker にはネットワーク名リソースの概念がなく、AD DS で作成されたオブジェクトもありません。Pacemaker で作成された IP アドレス リソースしかなく、それらを任意のノードで実行できます。There is no concept of a network name resource in Pacemaker, nor is an object created in AD DS; there is just an IP address resource created in Pacemaker that can run on any of the nodes. "フレンドリ名" を使用して、DNS 内のリスナーの IP リソースに関連付けられたエントリを作成する必要があります。An entry associated with the IP resource for the listener in DNS with a "friendly name" needs to be created. リスナーの IP リソースは、その可用性グループのプライマリ レプリカをホストしているサーバー上でのみアクティブになります。The IP resource for the listener will only be active on the server hosting the primary replica for that availability group.

Pacemaker が使用されていて、リスナーに関連付けられた IP アドレス リソースが作成されている場合は、1 つのサーバーで IP アドレスが停止し、もう 1 つのサーバーで起動する際に、システムがしばらく停止します (フェールオーバーが自動か手動かにかかわらず)。If Pacemaker is used and an IP address resource is created that is associated with the listener, there will be a brief outage as the IP address stops on the one server and starts on the other, whether it is automatic or manual failover. これにより、単一の名前と IP アドレスの組み合わせによる抽象化が提供されますが、システム停止はマスクされません。While this provides abstraction through the combination of a single name and IP address, it does not mask the outage. アプリケーションでは、この問題を検出して再接続するための何らかの機能を設けて、切断に対応できるようにする必要があります。An application must be able to handle the disconnect by having some sort of functionality to detect this and reconnect.

ただし、DNS 名と IP アドレスを組み合わせても、WSFC のリスナーで提供されるすべての機能 (セカンダリ レプリカのための読み取り専用ルーティングなど) を提供するのに十分ではありません。However, the combination of the DNS name and IP address is still not enough to provide all the functionality that a listener on a WSFC provides, such as read-only routing for secondary replicas. AG を構成する際、やはり SQL ServerSQL Server で "リスナー" を構成する必要があります。When configuring an AG, a "listener" still needs to be configured in SQL ServerSQL Server. これはウィザードだけでなく、Transact-SQL 構文でも確認できます。This can be seen in the wizard as well as the Transact-SQL syntax. これを Windows と同様に機能するように 構成するには、次の 2 つの方法があります。There are two ways that this can be configured to function the same as on Windows:

  • クラスターの種類が External の AG の場合、SQL ServerSQL Server で作成された "リスナー" に関連付けられた IP アドレスは、Pacemaker で作成されたリソースの IP アドレスである必要があります。For an AG with a cluster type of External, the IP address associated with the "listener" created in SQL ServerSQL Server should be the IP address of the resource created in Pacemaker.
  • クラスターの種類を None にして作成された AG の場合は、プライマリ レプリカに関連付けられた IP アドレスを使用します。For an AG created with a cluster type of None, use the IP address associated with the primary replica.

指定された IP アドレスに関連付けられたインスタンスは、アプリケーションからの読み取り専用ルーティング要求などに対するコーディネーターになります。The instance associated with the provided IP address then becomes the coordinator for things like the read-only routing requests from applications.

Windows ベースの可用性グループとレプリカとの相互運用性Interoperability with Windows-based availability groups and replicas

クラスターの種類が External または WSFC である AG では、そのレプリカをクロスプラットフォームにすることはできません。An AG that has a cluster type of External or one that is WSFC cannot have its replicas cross platforms. このことは、AG が SQL Server StandardSQL Server StandardSQL Server EnterpriseSQL Server Enterprise のどちらであっても同様です。This is true whether the AG is SQL Server StandardSQL Server Standard or SQL Server EnterpriseSQL Server Enterprise. つまり、基になるクラスターを持つ従来の AG 構成では、一方のレプリカを WSFC に配置し、もう一方のレプリカを、Pacemaker を使用して Linux 上に配置することはできません。That means in a traditional AG configuration with an underlying cluster, one replica cannot be on a WSFC and the other on Linux with Pacemaker.

クラスターの種類が NONE の AG では、OS の境界をまたいでレプリカを配置することができます。そのため、同じ AG 内に Linux ベースと Windows ベースの両方のレプリカを配置することができます。An AG with a cluster type of NONE can have its replicas cross OS boundaries, so there could be both Linux- and Windows-based replicas in the same AG. 次に示すのは、プライマリ レプリカが Windows ベースで、セカンダリが Linux ディストリビューション上にある場合の例です。An example is shown here where the primary replica is Windows-based, while the secondary is on one of the Linux distributions.

ハイブリッド None

分散型 AG も、OS 境界をまたぐことができます。A distributed AG can also cross OS boundaries. 基になる AG は、構成方法に関する規則によって制約を受けます (External で構成されたものは Linux のみだが、それが参加している AG は WSFC を使用して構成できるなど)。The underlying AGs are bound by the rules for how they are configured, such as one configured with External being Linux-only, but the AG that it is joined to could be configured using a WSFC. 次の例を参照してください。Consider the following example:

ハイブリッド分散型 AG

次の手順Next steps

SQL Server on Linux の可用性グループを構成するConfigure availability group for SQL Server on Linux

SQL Server on Linux の読み取りスケール可用性グループを構成するConfigure read-scale availability group for SQL Server on Linux

RHEL 上で可用性グループのクラスター リソースを追加するAdd availability group Cluster Resource on RHEL

SLES 上で可用性グループのクラスター リソースを追加するAdd availability group Cluster Resource on SLES

Ubuntu 上で可用性グループのクラスター リソースを追加するAdd availability group Cluster Resource on Ubuntu

クロスプラットフォームの可用性グループを構成するConfigure a cross-platform availability group