次の方法で共有

可用性グループ構成の高可用性とデータ保護

  • [アーティクル]

適用対象: SQL Server - Linux

この記事では、Linux サーバー上の SQL Server Always On 可用性グループに対してサポートされているデプロイ構成について説明します。 可用性グループでは、高可用性とデータ保護がサポートされています。 フェールオーバー後の自動障害検出、自動フェールオーバー、および透過的再接続により、高可用性が提供されます。 同期されるレプリカにより、データ保護が提供されます。

Windows Server フェールオーバー クラスター (WSFC) では、高可用性のための一般的な構成で、2 つの同期レプリカと 3 番目のサーバーまたはファイル共有を使用して、クォーラムが提供されます。 ファイル共有監視では、可用性グループの構成 (たとえば、同期の状態や、レプリカのロール) が検証されます。 この構成によって、フェールオーバー ターゲットとして選択されたセカンダリ レプリカに、最新のデータと可用性グループの構成変更が反映されます。

WSFC では、可用性グループ レプリカとファイル共有監視との間のフェールオーバーを判別するために、構成メタデータが同期されます。 可用性グループが WSFC 上にない場合、SQL Server インスタンスにより、構成メタデータが master データベースに格納されます。

たとえば、Linux クラスター上の可用性グループで CLUSTER_TYPE = EXTERNAL が指定されているとします。 フェールオーバーを判別するための WSFC はありません。 その場合、構成メタデータは SQL Server インスタンスによって管理および保守されます。 このクラスターにはミラーリング監視サーバーがないため、構成状態のメタデータを格納するには 3 つ目の SQL Server インスタンスが必要です。 3 つの SQL Server インスタンスがすべて揃うことで、クラスターの分散メタデータ ストレージが提供されます。

クラスター マネージャーは、可用性グループ内の SQL Server インスタンスに対してクエリを実行し、高可用性を維持するためにフェールオーバーを調整できます。 Linux クラスターでは、Pacemaker がクラスター マネージャーとなります。

SQL Server 2017 (14.x) CU 1 では、CLUSTER_TYPE = EXTERNAL が指定された可用性グループに対して、2 つの同期レプリカと 1 つの構成専用レプリカに対応した高可用性が提供されます。 構成専用レプリカは、SQL Server 2017 (14.x) CU 1 以降のバージョンの任意のエディション (SQL Server Express エディションを含む) でホストできます。 構成専用レプリカには、master データベース内の可用性グループに関する構成情報が保持されますが、可用性グループ内のユーザー データベースは含まれません。

構成が既定のリソース設定に与える影響

SQL Server 2017 (14.x) では、クラスター リソース設定 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT が導入されました。 この設定により、プライマリ レプリカで各トランザクションがコミットされる前に、指定された数のセカンダリ レプリカでトランザクション データがログに書き込まれるようになります。 外部クラスター マネージャーを使用する場合、この設定は高可用性とデータ保護の両方に影響を及ぼします。 この設定の既定値は、クラスター リソースが作成された時点のアーキテクチャによって決まります。 SQL Server リソース エージェント (mssql-server-ha) をインストールし、可用性グループのクラスター リソースを作成すると、クラスター マネージャーによって可用性グループの構成が検出され、それに応じて REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT が設定されます。

構成でサポートされている場合、リソース エージェント パラメーター REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT は高可用性とデータ保護を提供する値に設定されます。 詳細については、「Pacemaker 用の SQL Server リソース エージェントについて理解する」を参照してください。

以下のセクションでは、クラスター リソースの既定の動作について説明します。

高可用性、データ保護、および読み取りスケールの特定のビジネス要件を満たすように、可用性グループの設計を選択してください。

次の各構成を見ながら、可用性グループの設計パターンと、各パターンの機能について説明していきます。 これらの設計パターンは、高可用性ソリューション用に CLUSTER_TYPE = EXTERNAL が指定された可用性グループに対して適用されます。

  • 3 つの同期レプリカ
  • 2 つの同期レプリカ
  • 2 つの同期レプリカと 1 つの構成専用レプリカ

3 つの同期レプリカ

この構成は、3 つの同期レプリカで構成されます。 既定では、高可用性とデータ保護が提供されます。 また、読み取りスケールを提供することもできます。

3 つの同期レプリカを示す図。

3 つの同期レプリカを持つ可用性グループでは、読み取りスケール、高可用性、およびデータ保護を提供できます。 次の表は、可用性の動作について説明したものです。

可用性の動作 読み取りスケール 高可用性と
データの保護		 データ保護
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1 2
プライマリ停止 自動フェールオーバー。 データが失われる可能性があります。 新しいプライマリは読み取り/書き込みです。 自動フェールオーバー。 新しいプライマリは読み取り/書き込みです。 自動フェールオーバー。 前のプライマリが復旧してセカンダリとして可用性グループに参加するまで、新しいプライマリはユーザー更新トランザクション用に使用できません。
1 つのセカンダリ レプリカ停止 プライマリは読み取り/書き込みです。 プライマリは読み取り/書き込みです。 失敗したセカンダリが復旧して可用性グループに参加するまで、プライマリはユーザー更新トランザクション用に使用できません。

1 既定値

2 つの同期レプリカ

この構成では、データ保護が提供できます。 他の可用性グループ構成と同じく、読み取りスケールを有効にすることもできます。 2 つの同期レプリカの構成では、自動高可用性は提供されません。 2 つのレプリカの構成は SQL Server 2017 (14.x) RTM にのみ適用され、SQL Server 2017 (14.x) の上位バージョン (CU1 以降) ではサポートされなくなりました。

2 つの同期レプリカを示す図。

2 つの同期レプリカを持つ可用性グループでは、読み取りスケールとデータ保護が提供されます。 次の表は、可用性の動作について説明したものです。

可用性の動作 読み取りスケール データ保護
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
プライマリ停止 自動フェールオーバー。 データが失われる可能性があります。 新しいプライマリは読み取り/書き込みです。 自動フェールオーバー。 前のプライマリが復旧してセカンダリとして可用性グループに参加するまで、新しいプライマリはユーザー更新トランザクション用に使用できません。
1 つのセカンダリ レプリカ停止 プライマリは読み取り/書き込みであり、データが失われる可能性があります。 プライマリは、セカンダリが復旧するまではユーザー更新トランザクション用に使用できません。

1 既定値

2 つの同期レプリカと 1 つの構成専用レプリカ

2 つ (以上) の同期レプリカと構成専用レプリカを持つ可用性グループでは、データ保護が提供され、高可用性を提供することもできます。 次の図は、このアーキテクチャを表したものです。

構成専用可用性グループを示す図。

  1. セカンダリ レプリカへのユーザー データの同期レプリケーションです。 これには、可用性グループの構成メタデータも含まれます。
  2. 可用性グループの構成メタデータの同期レプリケーションです。 これには、ユーザー データは含まれません。

可用性グループの図では、プライマリ レプリカが、セカンダリ レプリカと構成専用レプリカの両方に構成データをプッシュしています。 また、セカンダリ レプリカはユーザー データも受け取ります。 構成専用レプリカは、ユーザー データを受信しません。 セカンダリ レプリカは同期可用性モードになります。 構成専用レプリカには、可用性グループ内のデータベースは含まれません (可用性グループに関するメタデータのみ)。 構成専用レプリカ上の構成データは同期的にコミットされます。

Note

構成専用レプリカを使う可用性グループは、SQL Server 2017 (14.x) CU 1 向けに新しく追加されたものです。 可用性グループ内のすべての SQL Server インスタンスは、SQL Server 2017 (14.x) CU 1 以降のバージョンである必要があります。

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT の既定値は 0 です。 次の表は、可用性の動作について説明したものです。

可用性の動作 高可用性と
データの保護		 データ保護
REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT= 0 1 1
プライマリ停止 自動フェールオーバー。 新しいプライマリは読み取り/書き込みです。 データが失われる可能性があります。 自動フェールオーバー。 新しいプライマリはユーザー更新トランザクション用に使用できません。
セカンダリ レプリカ停止 プライマリは読み取り/書き込みで、データが失われる可能性があります (プライマリで障害が発生し、復旧できない場合)。 プライマリにも障害が発生した場合、自動フェールオーバーは行われません。 プライマリはユーザー更新トランザクション用に使用できません。 プライマリでも障害が発生した場合、フェールオーバー先となるレプリカはありません。
構成専用レプリカ停止 プライマリは読み取り/書き込みです。 プライマリにも障害が発生した場合、自動フェールオーバーは行われません。 プライマリは読み取り/書き込みです。 プライマリにも障害が発生した場合、自動フェールオーバーは行われません。
同期セカンダリ + 構成専用レプリカ停止 プライマリはユーザー更新トランザクション用に使用できません。 自動フェールオーバーは行われません。 プライマリはユーザー更新トランザクション用に使用できません。 プライマリでも障害が発生した場合、フェールオーバー先となるレプリカはありません。

1 既定値

注意

構成専用レプリカをホストする SQL Server インスタンスでは、他のデータベースをホストすることもできます。 また、複数の可用性グループの構成専用データベースとして参加することもできます。

要件

  • 構成専用レプリカを持つ可用性グループ内のすべてのレプリカは、SQL Server 2017 (14.x) CU 1 以降のバージョンである必要があります。
  • 構成専用レプリカは、SQL Server の任意のエディション (SQL Server Express を含む) でホストできます。
  • 可用性グループには、プライマリ レプリカに加えて、少なくとも 1 つのセカンダリ レプリカが必要です。
  • 構成専用レプリカは、SQL Server インスタンスごとのレプリカの最大数にはカウントされません。 SQL Server Standard Edition では最大 3 個のレプリカを使用でき、SQL Server Enterprise Edition では最大 9 個を使用できます。

考慮事項

  • 構成専用レプリカは可用性グループごとに 1 つずつしか使用できません。
  • 構成専用レプリカをプライマリ レプリカにすることはできません。
  • 構成専用レプリカの可用性モードを変更することはできません。 構成専用レプリカを同期または非同期のセカンダリ レプリカに変更するには、構成専用レプリカを削除し、必要な可用性モードのセカンダリ レプリカを追加します。
  • 構成専用レプリカは、可用性グループのメタデータと同期されます。 ユーザー データはありません。
  • 1 つのプライマリ レプリカと 1 つの構成専用レプリカがあり、セカンダリ レプリカがない可用性グループは有効ではありません。
  • SQL Server Express Edition のインスタンスに可用性グループを作成することはできません。

Pacemaker 用の SQL Server リソース エージェントについて理解する

SQL Server 2017 (14.x) で、SYNCHRONOUS_COMMIT としてマークされたレプリカが最新の状態であるかどうかを示すために、sequence_number が sys.availability_groups に導入されました。 sequence_number は、ローカルの可用性グループ レプリカが可用性グループの残りのレプリカに対してどの程度最新であるかを表す、単調増加 BIGINT です。 この数値は、フェールオーバー、レプリカの追加または削除、およびその他の可用性グループ操作を実行すると更新されます。 この数はプライマリ上で更新され、セカンダリ レプリカにプッシュされます。 そのため、最新のセカンダリ レプリカでは、プライマリと同じ sequence_number になります。

Pacemaker は、レプリカをプライマリに昇格することを決定したら、まずすべてのレプリカに通知を送り、シーケンス番号を抽出して、それを格納します (この通知は昇格前通知と呼ばれます)。 次に、Pacemaker がレプリカをプライマリに昇格しようとする際、レプリカは、そのシーケンス番号がすべてのレプリカのすべてのシーケンス番号の最大値である場合にのみ自身を昇格させ、それ以外の場合は昇格操作を拒否します。 この方法により、最大のシーケンス番号を持つレプリカだけがプライマリに昇格できるようになるため、データの損失が回避されます。

昇格は、昇格の対象となるレプリカのうち少なくとも 1 つが、以前のプライマリと同じシーケンス番号を持っている場合にのみ保証されます。 Pacemaker リソース エージェントのデフォルトのビヘイビアーでは、少なくとも 1 つの同期コミット セカンダリ レプリカが最新の状態であり、自動フェールオーバーのターゲットとして使用できるように、REQUIRED_COPIES_TO_COMMIT が自動的に設定されます。 各監視アクションで、REQUIRED_COPIES_TO_COMMIT の値が ('同期コミット レプリカの数' / 2) として計算 (および、必要に応じて更新) されます。 その後、フェールオーバー時、リソース エージェントは (total number of replicas - required_copies_to_commit 個のレプリカ) に昇格前通知への応答を要求し、そのうちの 1 つをプライマリに昇格できるようにします。 sequence_number が最大であるレプリカがプライマリに昇格されます。

たとえば、3 つの同期レプリカ (1 つのプライマリ レプリカと 2 つの同期コミット セカンダリ レプリカ) を含む可用性グループの場合について考えます。

  • REQUIRED_COPIES_TO_COMMIT は 3 / 2 = 1 です

  • 昇格前アクションに応答しなければならないレプリカの数は、3 - 1 = 2 です。 したがって、フェールオーバーがトリガーされるためには、2 個のレプリカが稼働している必要があります。 プライマリの停止時に、セカンダリ レプリカの 1 つが応答せず、1 つのセカンダリのみが昇格前操作に応答する場合、リソース エージェントは、応答したセカンダリが最高の sequence_number を持つという保証が得られず、フェールオーバーはトリガーされません。

ユーザーは、デフォルトのビヘイビアーをオーバーライドし、可用性グループ リソースが上記のように REQUIRED_COPIES_TO_COMMIT を自動的に設定しないように構成できます。

重要

REQUIRED_COPIES_TO_COMMIT が 0 の場合、データ損失のリスクがあります。 プライマリが停止した場合、リソース エージェントは自動的にフェールオーバーをトリガーしません。 ユーザーは、プライマリが復旧するまで待つか、または手動でフェールオーバーするかを、決定する必要があります。

REQUIRED_COPIES_TO_COMMIT を 0 に設定するには、次のコマンドを実行します。

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

(SLES での) crm の使用と同等のコマンドを、次に示します。

sudo crm resource param <ag_cluster> set required_synchronized_secondaries_to_commit 0

既定の計算値に戻すには、次のコマンドを実行します。

sudo pcs resource update <ag_cluster> required_copies_to_commit=

Note

リソースのプロパティを更新すると、すべてのレプリカが停止して再起動します。 つまり、プライマリは一時的にセカンダリに降格された後で再び昇格されるので、一時的に書き込みができなくなります。 REQUIRED_COPIES_TO_COMMIT の新しいVALUEはレプリカが再開した後でのみ設定されるので、pcs コマンドの実行に伴いすぐには設定されません。

高可用性とデータ保護のバランス

上のデフォルトのビヘイビアーは、2 つの同期レプリカ (プライマリとセカンダリ) の場合にも適用されます。 Pacemaker はデフォルトで REQUIRED_COPIES_TO_COMMIT = 1 を設定し、最大限にデータ保護されるようにセカンダリ レプリカを常に最新の状態にします。

警告

このようにすると、セカンダリの計画的または非計画的な停止のために、プライマリ レプリカが使用できなくなるリスクが高くなります。 ユーザーは、リソース エージェントのデフォルトのビヘイビアーを変更し、REQUIRED_COPIES_TO_COMMIT を 0 にオーバーライドできます。

sudo pcs resource update <ag1> required_copies_to_commit=0

オーバーライドすると、リソース エージェントは REQUIRED_COPIES_TO_COMMIT の新しい設定を使用し、計算を停止します。 ユーザーは手動で更新する必要があります (たとえば、レプリカの数を増やす場合)。

次の表では、異なる可用性グループ リソース構成でのプライマリまたはセカンダリ レプリカの停止によって生じる結果について説明します。

可用性グループ - 2 つの同期レプリカ

構成 プライマリ停止 1 つのセカンダリ レプリカ停止
REQUIRED_COPIES_TO_COMMIT = 0 ユーザーが手動で FAILOVER を発効する必要があります。
データが失われる可能性があります。
新しいプライマリは読み取り/書き込みです		 プライマリは読み取り/書き込みであり、データが失われる可能性があります。
REQUIRED_COPIES_TO_COMMIT = 1 1 クラスターの自動的に FAILOVER を発行する
データの損失はありません。
前のプライマリが復旧してセカンダリとして可用性グループに参加するまで、新しいプライマリはすべての接続を拒否します。		 セカンダリが復旧するまで、プライマリはすべての接続を拒否します。

1 Pacemaker 用 SQL Server リソース エージェントの既定の動作。

可用性グループ - 3 つの同期レプリカ

構成 プライマリ停止 1 つのセカンダリ レプリカ停止
REQUIRED_COPIES_TO_COMMIT = 0 ユーザーが手動で FAILOVER を発効する必要があります。
データが失われる可能性があります。
新しいプライマリは読み取り/書き込みです		 プライマリは読み取り/書き込みです
REQUIRED_COPIES_TO_COMMIT = 1 1 クラスターは自動的に FAILOVER を発行します。
データの損失はありません。
新しいプライマリは読み取り/書き込みです		 プライマリは読み取り/書き込みです

1 Pacemaker 用 SQL Server リソース エージェントの既定の動作。

関連するコンテンツ