可用性グループの構成の高可用性とデータの保護High availability and data protection for availability group configurations

適用対象: XSQL Server on Windows○SQL Server on LinuxXAzure SQL DatabaseXAzure SQL Data WarehouseXParallel Data Warehouse THIS TOPIC APPLIES TO: noSQL Server on WindowsyesSQL Server on LinuxnoAzure SQL DatabasenoAzure SQL Data WarehousenoParallel Data Warehouse

この記事では、Linux サーバー上の SQL Server Always On 可用性グループのサポートされる展開構成を表示します。This article presents supported deployment configurations for SQL Server Always On availability groups on Linux servers. 可用性グループには、高可用性とデータ保護がサポートしています。An availability group supports high availability and data protection. 障害の自動検出、自動フェールオーバー、およびフェールオーバー後に透過的な再接続は、高可用性を実現します。Automatic failure detection, automatic failover, and transparent reconnection after failover provide high availability. 同期されたレプリカは、データ保護を提供します。Synchronized replicas provide data protection.

注意

高可用性とデータ保護、だけでなく、可用性グループことができますも災害復旧を実現、クロス プラットフォームの移行、およびスケール アウトを読み取る。主に、高可用性とデータ保護の実装について説明します。In addition to high availability and data protection, an availability group can also provide disaster recovery, cross platform migration, and read scale-out. This article primarily discusses implementations for high availability and data protection.

Windows Server フェールオーバー クラスタ リングで、一般的な構成の高可用性を使用する 2 つのレプリカを同期し、ファイル共有監視です。With Windows Server failover clustering, a common configuration for high availability uses two synchronous replicas and a file-share witness. ファイル共有監視は、たとえば、可用性グループの構成で、同期の状態と、レプリカのロールを検証します。The file-share witness validates the availability group configuration - status of synchronization, and the role of the replica, for example. この構成により、セカンダリ レプリカのフェールオーバー ターゲットがある最新のデータと可用性グループ構成の変更として選択します。This configuration ensures that the secondary replica chosen as the failover target has the latest data and availability group configuration changes.

Linux 用の現在の高可用性ソリューションを Windows Server フェールオーバー クラスターでファイル共有監視のような外部にミラーリング監視サーバーに対応していません。The current high availability solutions for Linux do not accommodate an external witness like the file share witness in a Windows Server failover cluster. Windows Server フェールオーバー クラスターがない場合は、可用性グループの構成が参加している SQL Server インスタンスの master データベースに格納されます。When there is no Windows Server failover cluster, the availability group configuration is stored in the master database on participating SQL Server instances. したがって、可用性グループでは、高可用性とデータ保護のためには、少なくとも 3 つの同期レプリカが必要です。Therefore, the availability group requires at least three synchronous replicas for high availability and data protection. Linux サーバーの可用性グループを作成した後は、クラスター リソースを作成します。After you create an availability group on Linux servers, create a cluster resource. クラスター リソースの設定は、高可用性の構成を決定します。The cluster resource settings determine the configuration for high availability.

スケール アウトを読み取ったりする高可用性、データ保護に関する特定のビジネス要件に対応する可用性グループの設計を選択します。Choose an availability group design to meet specific business requirements for high availability, data protection, and read scale-out.

重要

次の構成は、可用性グループのデザイン パターンと、各パターンの機能について説明します。The following configurations describe the availability group design patterns and the capabilities of each pattern. これらの設計パターンを持つ可用性グループに適用CLUSTER_TYPE = EXTERNAL高可用性ソリューションにします。These design patterns apply to availability groups with CLUSTER_TYPE = EXTERNAL for high availability solutions.

デザイン パターンは、次の 2 つの可用性グループの構成です。The design patters are two availability group configurations. 構成は次のとおりです。The configurations include:

  • 次の 3 つの同期レプリカThree synchronous replicas

  • 2 つの同期レプリカTwo synchronous replicas

既定のリソース設定の構成の影響How the configuration affects default resource settings

クラスター リソース設定required_synchronized_secondaries_to_commit各トランザクションでは、プライマリ レプリカ上でトランザクションをコミットする前にセカンダリ レプリカのログの最小数を書き込むことが保証されます。The cluster resource setting required_synchronized_secondaries_to_commit guarantees that each transaction is written to a minimum number of secondary replica logs before committing the transaction on the primary replica. この設定は、高可用性と構成に応じて、データ保護の両方に影響します。This setting can affect both high availability and data protection, depending on the configuration. エージェント インストールすると、SQL Server リソースのmssql-server-ha-可用性グループのクラスター リソースを作成、クラスター マネージャーの可用性の検出し構成と設定をグループ化required_synchronized_secondaries_to_commitそれに応じて。When you install the SQL Server resource agent - mssql-server-ha - and create a cluster resource for the availability group, the cluster manager detects the availability group configuration and sets required_synchronized_secondaries_to_commit accordingly.

リソースのエージェント パラメーターの構成でサポートされている場合required_synchronized_secondaries_to_commitが高可用性とデータ保護を提供する値に設定します。If supported by the configuration, the resource agent parameter required_synchronized_secondaries_to_commit is set to the value that provides high availability and data protection. 詳細については、次を参照してください。ペースの SQL Server の理解リソース エージェントです。For more information, see Understand SQL Server resource agent for pacemaker.

次のセクションでは、クラスター リソースの既定の動作を説明します。The following sections explain the default behavior for the cluster resource.

次の 3 つの同期レプリカThree synchronous replicas

この構成は、次の 3 つの同期レプリカで構成されます。This configuration consists of three synchronous replicas. 既定では、高可用性とデータ保護を提供します。By default, it provides high availability and data protection. 読み取りのスケール アウトが提供することもできます。It can also provide read scale-out.

3 つのレプリカ

次の表には、3 つの同期レプリカがある可用性グループの設定に基づく高の可用性とデータ保護の動作がについて説明します。The following table describes the high availability and data protection behavior based on the settings for an availability group with three synchronous replicas:

required_synchronized_secondaries_to_commit 00 1 *1 * 22
プライマリ レプリカの停止後に自動フェールオーバーAutomatic failover after primary replica outage
プライマリ レプリカの 1 つのセカンダリ レプリカの停止後に使用できます。Primary replica available after one secondary replica outage
2 つのセカンダリ レプリカの停止後に利用可能なプライマリ レプリカPrimary replica available after two secondary replica outages
プライマリ レプリカの停止 - データの損失後に手動フェールオーバーManual failover after primary replica outage - possible data loss

*既定の設定、クラスター内のリソースとして可用性グループが追加されるとき。* Default setting when availability group is added as a resource in a cluster.

2 つの同期レプリカTwo synchronous replicas

この構成は、データの保護を実現します。This configuration enables data protection. その他の可用性グループ構成のように読み取りのスケール アウトを有効にできます。2 つの同期レプリカの構成は、自動の高可用性を提供しません。Like the other availability group configurations, it can enable read scale-out. The two synchronous replicas configuration does not provide automatic high availability.

2 つの同期レプリカ

この構成では、2 つのサーバーが必要です。This configuration requires two servers. これらのサーバーでは、プライマリ レプリカとセカンダリ レプリカのロールを入力します。These servers fill the role of primary replica and secondary replica.

データの最適な 2 つの同期レプリカ構成の保護とデータベースの読み取りワークロードを分散します。The two synchronous replicas configuration is optimized for data protection and distributing the read workload for databases. 既定では、データの保護に関するリソースが構成されます。By default, the resource is configured for data protection. この構成は、SQL Server のいずれかのインスタンスが失敗した場合、データベースが完全に使用可能かデータ損失のリスクがあるために、高可用性を提供しません。This configuration does not provide high availability because if either instance of SQL Server fails, either the database is not fully available or there is risk of data loss.

次の表では、2 つの同期レプリカがある可用性グループの有効な値に従ってデータ保護の動作について説明します。The following table describes the data protection behavior according to the possible values for an availability group with two synchronous replicas:

required_synchronized_secondaries_to_commit 0 *0 * 11
プライマリ レプリカの停止後に自動フェールオーバーAutomatic failover after primary replica outage ✔ **✔ **
プライマリ レプリカのセカンダリ レプリカの停止後に使用できます。Primary replica available after secondary replica outage

*既定の設定、クラスター内のリソースとして可用性グループが追加されるとき。* Default setting when availability group is added as a resource in a cluster.

**この構成は、自動の可用性グループをプライマリ レプリカの停止が発生した後は、経由で失敗します。** In this configuration, after the primary replica outage occurs the availability group automatic fails over. アプリケーションは、プライマリ レプリカは、行に戻るようになりました、セカンダリ レプリカとしてまで、可用性グループに接続できません。Applications cannot connect to the availability group until the primary replica is back on line - now as a secondary replica.

2 つの同期レプリカの構成は、2 台のサーバーで SQL Server の 2 つのインスタンスのみが必要なために、最も経済的なことがあります。The two synchronous replicas configuration may be the most economical because it only requires two instances of SQL Server on two servers.

ペースに対する SQL Server エージェントのリソースを理解します。Understand SQL Server resource agent for pacemaker

SQL Server 2017 CTP 1.4 追加sequence_numbersys.availability_groupsレプリカがプライマリ レプリカとが最新であるかのセカンダリを識別するペースを許可します。SQL Server 2017 CTP 1.4 added sequence_number to sys.availability_groups to allow Pacemaker to identify how up-to-date secondary replicas are with the primary replica. sequence_number最新であるか、ローカルの可用性グループのレプリカを表す単調に増加する bigint 型の値です。sequence_number is a monotonically increasing BIGINT that represents how up-to-date the local availability group replica is. ペースの更新プログラム、sequence_number可用性グループの構成変更のたびにします。Pacemaker updates the sequence_number with each availability group configuration change. 構成の変更には、フェールオーバー、レプリカの追加または削除などがあります。Examples of configuration changes include failover, replica addition, or removal. 数が、プライマリ上で更新し、セカンダリ レプリカにレプリケートします。The number is updated on the primary, then replicated to secondary replicas. このため、最新の状態の構成を持つセカンダリ レプリカは、プライマリと同じシーケンス番号です。Thus a secondary replica that has up-to-date configuration has the same sequence number as the primary.

最初は送信をプライマリ レプリカを昇格するペースが決定したら、事前昇格すべてのレプリカに通知します。When Pacemaker decides to promote a replica to primary, it first sends a pre-promote notification to all replicas. レプリカは、シーケンス番号を返します。The replicas return the sequence number. 次に、ペースが実際には、レプリカはプライマリに昇格しようとするとき、レプリカのみ昇格自体のシーケンス番号が、すべてのシーケンス番号の最も高い場合。Next, when Pacemaker actually tries to promote a replica to primary, the replica only promotes itself if its sequence number is the highest of all the sequence numbers. 独自のシーケンス番号が一番大きいシーケンス番号が一致しない場合、レプリカは、昇格操作を拒否します。If its own sequence number does not match the highest sequence number, the replica rejects the promote operation. この方法により、最大のシーケンス番号を持つレプリカだけがプライマリに昇格できるようになるため、データの損失が回避されます。In this way only the replica with the highest sequence number can be promoted to primary, ensuring no data loss.

このプロセスでは、以前のプライマリと同じシーケンス番号を持つプロモーションの利用可能な少なくとも 1 つのレプリカが必要です。This process requires at least one replica available for promotion with the same sequence number as the previous primary. ペース リソース エージェント セットを使用すると、required_synchronized_secondaries_to_commitになるようには、少なくとも 1 つの同期セカンダリ レプリカは最新であり、既定では、自動フェールオーバーのターゲットに使用できます。The Pacemaker resource agent sets required_synchronized_secondaries_to_commit such that at least one synchronous secondary replica is up-to-date and available to be the target of an automatic failover by default. 各監視のアクションの値にrequired_synchronized_secondaries_to_commit計算 (および必要に応じて更新) します。With each monitoring action, the value of required_synchronized_secondaries_to_commit is computed (and updated if necessary). required_synchronized_secondaries_to_commit値は 2 で 'の同期レプリカの数' 割った値します。The required_synchronized_secondaries_to_commit value is 'number of synchronous replicas' divided by 2. フェールオーバー時に、リソースのエージェントが必要です (total number of replicas - required_synchronized_secondaries_to_commitレプリカ) に応答する、事前の通知を昇格します。At failover time, the resource agent requires (total number of replicas - required_synchronized_secondaries_to_commit replicas) to respond to the pre-promote notification. 最高の値を持つレプリカsequence_numberがプライマリに昇格します。The replica with the highest sequence_number is promoted to primary.

たとえば、次の 3 つの同期レプリカの 1 つのプライマリ レプリカと 2 つの同期セカンダリ レプリカを可用性グループです。For example, An availability group with three synchronous replicas - one primary replica and two synchronous secondary replicas.

  • required_synchronized_secondaries_to_commit1 になります。(3 -> 1 の 2/)。required_synchronized_secondaries_to_commit is 1; (3 / 2 -> 1).

  • 事前昇格アクションに応答するレプリカの必要な数は 2 です。(3-1 = 2)。The required number of replicas to respond to pre-promote action is 2; (3 - 1 = 2).

このシナリオでは、2 つのレプリカは、フェールオーバーをトリガーする応答する必要です。In this scenario, two replicas have to respond for the failover to be triggered. 最新の状態にして、応答、プライマリ レプリカの停止後に自動フェールオーバーを正常に実行、両方のセカンダリ レプリカが必要な事前の通知を昇格します。For successful automatic failover after a primary replica outage, both secondary replicas need to be up-to-date and respond to the pre-promote notification. Online と同期する場合は、同じシーケンス番号があります。If they are online and synchronous, they have the same sequence number. 可用性グループを使用して、それらの 1 つ昇格させます。The availability group promotes one of them. 応答するセカンダリ レプリカの 1 つだけの場合、事前昇格アクション、リソース エージェントは、応答したセカンダリが最高の sequence_number され、フェールオーバーがトリガーされないことを保証ことはできません。If only one of the secondary replicas responds to the pre-promote action, the resource agent cannot guarantee that the secondary that responded has the highest sequence_number, and a failover is not triggered.

重要

required_synchronized_secondaries_to_commit が 0 の場合、データ損失のリスクがあります。When required_synchronized_secondaries_to_commit is 0 there is risk of data loss. プライマリ レプリカの停止中に、リソースのエージェントに自動的にフェールオーバーは発生しません、します。During a primary replica outage, the resource agent does not automatically trigger a failover. プライマリへの回復を待つか、手動フェールオーバーを使用することができますFORCE_FAILOVER_ALLOW_DATA_LOSSです。You can either wait for primary to recover, or manually fail over using FORCE_FAILOVER_ALLOW_DATA_LOSS.

既定の動作をオーバーライドして、可用性グループ リソースも設定することもできますrequired_synchronized_secondaries_to_commit自動的にします。You can choose to override the default behavior, and prevent the availability group resource from setting required_synchronized_secondaries_to_commit automatically.

次のスクリプト セットrequired_synchronized_secondaries_to_commitという名前の可用性グループに対して、0 に<**ag1**>です。The following script sets required_synchronized_secondaries_to_commit to 0 on an availability group named <**ag1**>. 置換を実行する前に<**ag1**>可用性グループの名前に置き換えます。Before you run replace <**ag1**> with the name of your availability group.

sudo pcs resource update <**ag1**> required_synchronized_secondaries_to_commit=0

可用性グループ構成の実行に基づいて、既定値に戻すには。To revert to default value, based on the availability group configuration run:

sudo pcs resource update <**ag1**> required_synchronized_secondaries_to_commit=

注意

上記のコマンドを実行すると、プライマリが一時的に降格セカンダリ、し、もう一度昇格されます。When you run the preceding commands, the primary is temporarily demoted to secondary, then promoted again. リソースの更新では、すべてのレプリカを停止し、再起動が発生します。The resource update causes all replicas to stop and restart. 新しい値required_synchronized_secondaries_to_commit、瞬時にないレプリカが再起動したら、のみ設定します。The new value forrequired_synchronized_secondaries_to_commit is only set once replicas are restarted, not instantaneously.