Always On Linux で可用性グループAlways On Availability Groups on Linux

適用対象: はいSQL サーバー (Linux のみ)ありませんAzure SQL DatabaseありませんAzure SQL Data Warehouseありません並列データ ウェアハウス APPLIES TO: yesSQL Server (Linux only) noAzure SQL Database noAzure SQL Data Warehouse noParallel Data Warehouse

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

可用性グループの高レベルの観点から SQL ServerSQL Serveron Linux と同じ 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:

  • Microsoft 分散トランザクション コーディネーター (DTC) は linux でサポートされていませんSQL Server 2017 (14.x)SQL Server 2017 (14.x)します。Microsoft Distributed Transaction Coordinator (DTC) is not supported under Linux in SQL Server 2017 (14.x)SQL Server 2017 (14.x). アプリケーションが分散トランザクションの使用を求めたり、AG 必要がある場合は、デプロイ SQL ServerSQL ServerWindows にします。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 use Pacemaker instead of a WSFC.
  • Pacemaker には、ワークグループ クラスター シナリオを除く Windows での Ag のほとんどの構成とは異なり、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

AG SQL Server StandardSQL Server Standard合計 2 つのレプリカを持つことができます。 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. AG SQL Server EnterpriseSQL Server Enterprise最大 9 つのレプリカを持つことができます。 同期は、プライマリと最大 8 つのセカンダリ、最大 3 つ (プライマリを含む) を 1 つ。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. 場合、基になるクラスターを使用することがあります合計 16 ノードの最大 Corosync が含まれている場合。If using an underlying cluster, there can be a maximum of 16 nodes total when Corosync is involved. 可用性グループが span と 16 のノードの最大 9 SQL Server EnterpriseSQL Server Enterpriseとに 2 つの SQL Server StandardSQL Server Standardします。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. つまり、あるクォーラムと STONITH 必要が適切に実装する Pacemaker の観点から、他にも、 SQL ServerSQL Server構成専用レプリカなどの要件。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. 外部のクラスターの種類は、可用性グループの下に Pacemaker を使用することを意味します。A cluster type of External means that Pacemaker will be used underneath the AG. 外部を使用してクラスターの種類は、フェールオーバー モードが外部にも設定する必要があります (新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)). 自動フェールオーバーがサポートされていますが、Pacemaker を使用する場合は、フェールオーバー モードを自動ではありません、外部に設定するよう、WSFC とは異なり。Automatic failover is supported, but unlike a WSFC, failover mode is set to External, not automatic, when Pacemaker is used. WSFC の場合とは異なり、可用性グループを構成した後、可用性グループの Pacemaker 部分が作成されます。Unlike a WSFC, the Pacemaker portion of the AG is created after the AG is configured.

None のクラスターの種類は、要件がないことは、可用性グループを使用して、Pacemaker を意味します。A cluster type of None means that there is no requirement for, nor will the AG use, Pacemaker. Pacemaker が構成されているサーバー上であっても、可用性グループがある場合、None のクラスターの種類で構成されている 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. なしで作成した 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_groups、列のcluster_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.

必要な_同期_セカンダリ_に_コミットrequired_synchronized_secondaries_to_commit

初めて使用する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. これは、可用性グループに、現在プライマリである必要がありますセカンダリ レプリカの数を指示します。This tells the AG the number of secondary replicas that must be in lockstep with the primary. これにより、自動フェールオーバー (外部のクラスターの種類で 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.

に対して設定できる 3 つの値があるrequired_synchronized_secondaries_to_commit: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 - No automatic failover is possible since no secondary replica is required to be synchronized. プライマリ データベースは、常に使用できます。The primary database is available at all times.
  • 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 用に構成されたリソースの名前を指定し、は 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.
  • クラスターの種類は、外部に設定されます。The cluster type is set to External. 自動フェールオーバーが None のクラスターの種類ではできません。Automatic failover is not possible with a cluster type of None.
  • sequence_numberになるセカンダリ レプリカのプライマリには最大のシーケンス番号 - つまり、セカンダリ レプリカのsequence_number元のプライマリ レプリカから 1 つに一致します。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. 同期レプリカの動作 (存在できる 3 つの合計: 1 つのプライマリ レプリカと 2 つのセカンダリ レプリカ) でさらに制御できる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. これには動作しません SQL Server StandardSQL Server Standard、2 つのレプリカを AG に参加していることがあるできますのみであるためです。This would not work for SQL Server StandardSQL Server Standard, since it can only have two replicas participating in an AG. 構成のみのレプリカは、AG 構成の他のレプリカと同じで、master データベースで AG 構成を格納します。The configuration-only replica stores the AG configuration in the master database, same as the other replicas in the AG configuration. 構成のみのレプリカの可用性グループに参加しているユーザー データベースではありません。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.

クォーラムを維持し、外部のクラスターの種類で自動フェールオーバーを有効にする可用性グループは、そのいずれかの必要があります。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.

外部を使用しているかどうか、手動フェールオーバーが発生することができます、または None のクラスターの AG 構成の種類。Manual failovers can happen whether using External or None cluster types for AG configurations. 持つクラスターの種類が None の可用性グループの構成専用レプリカを構成することができます、しないで、展開が複雑になるためです。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. これらの構成を手動で変更required_synchronized_secondaries_to_commitを少なくとも 1 つの同期レプリカがあるように、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. これは、ライセンス コストを最小限に抑えられるし、Ag の連携により、 SQL Server StandardSQL Server Standardします。This will minimize licensing costs and ensures it works with AGs in SQL Server StandardSQL Server Standard. これは、3 つ目のサーバーだけの最小限の仕様を満たす必要がありますに必要なことは意味 SQL ServerSQL ServerAG のユーザー トランザクションのトラフィックを受け取っていないためです。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_commit0 は、プライマリ レプリカのトランザクションを受け付けるが (手動または自動) のデータもフェールオーバー可能な保護がない場合、プライマリは、この時点で失敗すると、セカンダリ レプリカは使用できません。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 が既知のバグを使用して生成される corosync.log ファイルでログ記録mssql-server-haします。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. 十分なレプリカが online に安全に、ローカル レプリカを昇格します。"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. 十分なレプリカが online に安全に、ローカル レプリカを昇格します。"Not enough replicas are online to safely promote the local replica."

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

Pacemaker クラスターまたは一連のサーバーあたり 1 つ以上の可用性グループを作成できます。More than one AG can be created per Pacemaker cluster or set of servers. 唯一の制限は、システム リソースです。The only limitation is system resources. 可用性グループの所有権は、マスターで表示されます。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. たとえば、ユーザーのデータベースが/var/opt/mssql/userdataサーバー B でサーバー A、その同じフォルダーが存在する必要があります唯一の例外は、セクションで記した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、これは、ネットワーク名リソースと (必要な) 場合、AD DS に登録された後、IP リソースの組み合わせを 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. 可用性グループ リソース自体と組み合わせて、その抽象化を提供します。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 アドレス リソースが作成された場合があります短時間停止して、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. この抽象化、1 つの名前と 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:

  • 外部のクラスターの種類を含む AG での IP アドレスに関連付けられているで作成した「リスナー」 SQL ServerSQL Server 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 のクラスターの種類で作成された可用性グループ、プライマリ レプリカに関連付けられている 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 である 1 つのクラスターの種類を持つ可用性グループには、クロス プラットフォームのレプリカを含めることはできません。An AG that has a cluster type of External or one that is WSFC cannot have its replicas cross platforms. これは true かどうか、可用性グループが SQL Server StandardSQL Server Standardまたは SQL Server EnterpriseSQL Server Enterpriseします。This is true whether the AG is SQL Server StandardSQL Server Standard or SQL Server EnterpriseSQL Server Enterprise. つまり基になるクラスターで従来の可用性グループ構成で、1 つのレプリカは、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.

AG が NONE のクラスターの種類では、そのレプリカのため、同じ AG で Linux および Windows ベースの両方のレプリカが存在でしたする OS の境界を越えることができます。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.

ハイブリッドなし

分散型 AG では、OS の境界を越えることができますも。A distributed AG can also cross OS boundaries. これらの構成方法など、外部の中で構成されているいずれかの規則によって基になる可用性がバインドされた Linux でのみが、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:

ハイブリッド Dist 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