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

適用対象:Linux 上の SQL Server

この記事では、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 以降では、2 つの同期レプリカと構成のみのレプリカに対して、CLUSTER_TYPE = EXTERNAL を使用する可用性グループの高可用性が有効になります。 構成のみのレプリカは、SQL Server 2017 (14.x) CU 1 以降のバージョン (SQL Server Express エディションを含む) の任意のエディションでホストできます。 構成専用レプリカには、master データベース内の可用性グループに関する構成情報が保持されますが、可用性グループ内のユーザー データベースは含まれません。

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

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

プライマリ レプリカがデータを 2 つのセカンダリ レプリカに同期している可用性グループの図。

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

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

1 既定値

2 つの同期レプリカ

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

プライマリ レプリカがデータを 1 つのセカンダリ レプリカに同期している可用性グループの図。

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

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

1 既定値

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

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

データとメタデータをセカンダリ レプリカと構成専用レプリカに同期するプライマリ レプリカを含む可用性グループの図。

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

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

Note

構成のみのレプリカを持つ可用性グループは、SQL Server 2017 (14.x) CU 1 の新機能です。 可用性グループ内のSQL Serverのすべてのインスタンスは、2017 (14.x) CU 1 以降のバージョンSQL Serverする必要があります。

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

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

1 既定値

Note

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

必要条件

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

考慮事項

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

SQL Server 用の Pacemaker リソースエージェントを理解する

SQL Server 2017 (14.x) では、sequence_number が sys.availability_groups に導入され、SYNCHRONOUS_COMMIT としてマークされたレプリカが最新の状態であるかどうかを示しています。 sequence_number は単調に増加する bigint であり、可用性グループ内のその他のレプリカに対するローカル可用性グループ レプリカの同期状態を表します。

この数は、フェールオーバーの実行、レプリカの追加または削除、その他の可用性グループ操作を実行すると更新されます。

プライマリ レプリカが番号を更新し、それをセカンダリ レプリカにプッシュします。 最新のセカンダリ レプリカはプライマリと同じ sequence_number を持っています。

Pacemaker は、レプリカをプライマリに昇格することを決定すると、最初にすべてのレプリカに通知を送信してシーケンス番号を抽出して格納します。 この通知は、事前昇格通知と呼ばれます。 次に、Pacemaker がレプリカをプライマリに昇格しようとすると、そのシーケンス番号がすべてのレプリカのすべてのシーケンス番号の中で最も高い場合にのみ、レプリカ自体が昇格されます。 それ以外の場合は、昇格操作が拒否されます。 このプロセスを使用すると、シーケンス番号が最も高いレプリカのみをプライマリに昇格でき、データが失われるのを確実にしません。

昇格は、昇格に使用できる少なくとも 1 つのレプリカが、前のプライマリと同じシーケンス番号を持っている限り機能します。 既定の動作では、Pacemaker リソース エージェントが REQUIRED_COPIES_TO_COMMIT を自動的に設定して、少なくとも 1 つの同期コミット セカンダリ レプリカが最新の状態になり、自動フェールオーバーのターゲットとして使用できるようになります。 各監視アクションで、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 自動的に設定されないように可用性グループ リソースを構成できます。

Important

REQUIRED_COPIES_TO_COMMITが0されると、データ損失のリスクが発生します。 プライマリの障害が発生した場合、リソース エージェントはフェールオーバーを自動的にトリガーしません。 プライマリが復旧するまで待機するか、手動でフェールオーバーするかを選択する必要があります。

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

sudo pcs resource update <ag_cluster> required_copies_to_commit=0

(SUSE Linux Enterprise Server 上の) 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の新しい値はレプリカの再起動後にのみ設定されるため、pcs コマンドを実行してもすぐには設定されません。

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

前述の既定の動作は、2 つの同期レプリカ (プライマリとセカンダリ) の場合にも適用されます。 Pacemaker は REQUIRED_COPIES_TO_COMMIT を 1 に設定して、データ保護を最大限に行うためにセカンダリ レプリカが常に最新の状態に保たれるようにします。

Warning

この設定では、セカンダリで計画的または計画外の停止が発生したため、プライマリ レプリカが使用できなくなるリスクが高くなります。 リソース エージェントの既定の動作を変更し、 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を手動で発行する必要があります。

データが失われる可能性があります。

新しいプライマリは読み取り/書き込みです。		 プライマリはR/Wモードで動作しており、データ損失のリスクにさらされています。
REQUIRED_COPIES_TO_COMMIT = 1 1 クラスターが自動的にFAILOVERを発行します。

データの損失はありません。

前のプライマリが復旧してセカンダリとして可用性グループに参加するまで、新しいプライマリはすべての接続を拒否します。		 セカンダリが復旧するまで、プライマリはすべての接続を拒否します。

SQL Server リソース エージェント1の Pacemaker に対する既定の動作。

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

コンフィギュレーション プライマリ停止 1 つのセカンダリ レプリカ停止
REQUIRED_COPIES_TO_COMMIT = 0 FAILOVERを手動で発行する必要があります。

データが失われる可能性があります。

新しいプライマリは読み取り/書き込みです。		 プライマリは読み取り/書き込みです。
REQUIRED_COPIES_TO_COMMIT = 1 1 クラスターは自動的に FAILOVER を発行します。

データの損失はありません。

新しいプライマリは読み取り/書き込みです。		 プライマリは読み取り/書き込みです。

SQL Server リソース エージェント1の Pacemaker に対する既定の動作。

関連するコンテンツ

  • Last updated on