Always On Linux 上の可用性グループAlways On Availability Groups 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

Always On 可用性グループ (Ag) の下にある Linux ベースの特性を説明 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 および、WSFC を除く Linux で作業と同じにします。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:

  • Linux の Microsoft 分散トランザクション コーディネーター (DTC) はサポートされていません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 Server windows です。If your applications require the use of distributed transactions and need an AG, deploy SQL ServerSQL Server on Windows.
  • Linux ベースの展開は、WSFC ではなくペースを使用します。Linux-based deployments use Pacemaker instead of a WSFC.
  • ペースには、ワークグループのクラスターのシナリオを除く Windows 上の Ag のほとんどの構成とは異なり、Active Directory ドメイン サービス (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 上のペースを使用して 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. 可用性グループが最大で 9 個と 16 個のノードにまたがることができます 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.

ペースを使用する場合にする必要があります適切に構成するため、立ち上がっており実行中になります。If Pacemaker is used, it must be properly configured so it remains up and running. つまり、あるクォーラムと STONITH 実装する必要が正しくペースのパースペクティブから、他にも、 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 つの有効な値: 外部、none で調整します。For Linux, there are two valid values: External and None. 外部のクラスターの種類は、可用性グループの下にあるペースが使用されることを意味します。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)). 自動フェールオーバーがサポートされているが、WSFC とは異なりフェールオーバー モードに設定されている外部、自動ではありません、ペースを使用する場合。Automatic failover is supported, but unlike a WSFC, failover mode is set to External, not automatic, when Pacemaker is used. WSFC とは異なり、可用性グループを構成した後、可用性グループのペース部分が作成されます。Unlike a WSFC, the Pacemaker portion of the AG is created after the AG is configured.

None のクラスターの種類は、こと、要件はありません。 また、AG、ペースを意味します。A cluster type of None means that there is no requirement for, nor will the AG use, 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. リスナーのストーリーはペースせずより複雑なもあります。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. これは、可用性グループに、プライマリと lockstep にする必要があるセカンダリ レプリカの数を示しています。This tells the AG the number of secondary replicas that must be in lockstep with the primary. これにより、自動フェールオーバー (ペースの外部のクラスターのタイプと統合) の場合のみなどを有効にされ、セカンダリ レプリカの数が、オンラインまたはオフラインの場合は、プライマリの可用性などの動作を制御します。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値が既定の設定し、ペースで保持されている/ 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) ペースを通知し、 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 、可用性グループ用に構成されたリソースの名前を指定し、は 0、1、または 2 です。where AGResourceName is the name of the resource configured for the AG, and Value is 0, 1, or 2. パラメーターを管理するペースの既定値に戻すには、それを設定するには、値のない同じのステートメントを実行します。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. 自動フェールオーバーのなしのクラスターのタイプはできません。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. ペースは異なるため、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 のペースで提供されるクォーラム メカニズムもかまいません、クラスターの層のすべての 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 StandardAG に参加している 2 つのレプリカにしか持てないため、します。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.

AG 構成の種類をクラスター None または外部を使用するかどうか、手動フェールオーバーが発生することができます。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 Server可用性グループのユーザー トランザクション トラフィック受信していないため、します。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

ペース クラスターまたは一連のサーバーあたり 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 のように、可用性グループに参加しているユーザー データベースのドライブおよびフォルダー構造が同等でなければなりません。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サーバー A で同じフォルダーにはサーバー 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. 可用性グループ リソース自体と組み合わせて、その抽象化を提供します。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. ペース、内のネットワーク名リソースの概念がないもがオブジェクトを AD DS; の作成だけに 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.

ペースが使用され、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ペースで作成されたリソースの 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

クロス プラットフォームそのレプリカ、AG の外部または WSFC クラスターの型を持つことはできません。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. つまり基になるクラスターで従来 AG の構成で、1 つのレプリカは、WSFC と別のペースの 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.

クラスター型なしの可用性グループには、OS 境界を越えることがあるため 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.

ハイブリッドなし

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

Linux 上の SQL Server の可用性グループを構成します。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