次の方法で共有

包含可用性グループとは

適用対象:SQL Server 2022 (16.x)

包含可用性グループは、以下をサポートする Always On 可用性グループ (AG) です。

  • インスタンス レベルに加え、AG レベルでのメタデータ オブジェクト (ユーザー、ログイン、アクセス許可、SQL Agent ジョブなど) を管理する

  • AG内の特殊なコンテインドシステムデータベース。

この記事では、包含 AG の類似点、相違点、および機能について詳しく説明します。

概要

AG は、一般に、調整されたグループとして動作することを目的とした 1 つ以上のユーザー データベースで構成され、クラスター内の一部のノード上にレプリケートされます。 ノードで障害が発生したとき、またはプライマリ コピーをホストするノード上の SQL Server の正常性に問題があった場合、データベースのグループがユニットとして AG 内の別のレプリカ ノードに移動されます。 すべてのユーザー データベースは、同期モードでも非同期モードでも、AG のすべてのレプリカ間で同期された状態が保たれます。

これは、このような一連のユーザー データベースのみを処理するアプリケーションには適していますが、システム データベース (master または msdb) に格納されているオブジェクト (ユーザー、ログイン、アクセス許可、エージェント ジョブなど) もアプリケーションが利用する場合には課題があります。 アプリケーションがスムーズかつ予測どおりに機能するために、管理者は、これらのオブジェクトに対する変更が AG 内のすべてのレプリカ インスタンス間で複製されていることを手動で確認する必要があります。 新しいインスタンスが AG に取り込まれると、自動または手動の簡単なプロセスでデータベースのシード処理を行うことができますが、システム データベースのすべてのカスタマイズは、新しいインスタンスで再構成して他のレプリカと一致するようにする必要があります。

包含 AG とは、master および msdb データベースの関連部分を含むように、レプリケートされるデータベースのグループの概念を拡張したものです。 これは、包含 AG を使用するアプリケーションの実行コンテキストと考えてください。 この考え方は、包含 AG 環境に含まれる設定が、それに依存するアプリケーションに影響を与えるというものです。 そのため、包含 AG 環境は、アプリケーションがやり取りするすべてのデータベース、アプリケーションが使用する認証 (ログイン、ユーザー、アクセス許可)、実行する予定のスケジュール済みジョブ、およびアプリケーションに影響を与えるその他の構成設定に関係します。

これは、ユーザー アカウントに別のメカニズムを使用してデータベース自体にユーザー情報を格納する、包含データベースとは異なります。 包含データベースはログインとユーザーのみをレプリケートし、レプリケートされるログインとユーザーの範囲はその単一データベース (およびそのレプリカ) に限定されます。

対照的に、包含 AG では、ユーザー、ログイン、アクセス許可などを AG レベルで作成でき、それらは、AG のレプリカ間でも、その AG 内のデータベース間でも自動的に一貫性が保たれます。 このため、管理者はこれらの変更を手動で行う必要がなくなります。

SQL Server 2025 の変更

SQL Server 2025 (17.x) プレビューでは、包含可用性グループに対する 分散型可用性グループ のサポートが導入されています。

相違点

包含 AG を使用する際は、いくつかの実用的な違いを考慮する必要があります。たとえば、包含システム データベースの作成や、インスタンス レベルではなく包含 AG レベルでの接続が強制されることなどです。

包含システム データベース

包含 AG それぞれには、可用性グループの名前から名付けられた、独自のシステム データベース master および msdb があります。 たとえば、AG MyContainedAG には、MyContainedAG_master と MyContainedAG_msdb という名前のデータベースがあります。 これらのシステム データベースは新しいレプリカに自動的にシード処理され、可用性グループ内の他のデータベースと同様に、これらのデータベースにも更新がレプリケートされます。 つまり、包含 AG に接続しているときに、ログインやエージェント ジョブなどのオブジェクトを追加したときに、包含 AG が別のインスタンスにフェールオーバーしても、包含 AG に接続しているため、エージェント ジョブは引き続き表示され、包含 AG に作成されたログインを使用して認証することができます。

重要

包含 AG は、可用性グループのレプリカ間で実行環境の構成の一貫性を維持するためのメカニズムです。 セキュリティ境界を表すものではありません。 たとえば、包含 AG への接続に対して AG の外部にあるデータベースへのアクセスを妨げる境界はありません。

新しく作成された包含 AG のシステム データベースは、CREATE AVAILABILITY GROUP コマンドを実行したインスタンスのコピーではありません。 これらは、最初はデータのない空のテンプレートです。 作成直後に、包含 AG を作成するインスタンスの管理者アカウントが包含 AG master にコピーされます。 この方法で、管理者が包含 AG にログインし、残りの構成を設定できます。

インスタンスにローカル ユーザーまたは構成を作成した場合、包含システム データベースを作成しても自動的に表示されず、包含 AG に接続しても表示されません。 ユーザー データベースが包含 AG に参加すると、すぐにこれらのユーザーにアクセスできなくなります。 データベースに直接接続するか、リスナーエンドポイントを使用することで、包含 AG のコンテキスト内で、包含データベース内のシステムデータベースにこれらを手動で再作成する必要があります。 例外は、親インスタンスの sysadmin ロールのすべてのログインが、包含 AG の作成時に新しい AG 固有の master データベースにコピーされる点です。

注

master データベースは包含可用性グループごとに独立しているため、包含 AG のコンテキストで実行されるサーバースコープ アクティビティは、包含システム データベースにのみ保持されます。 これには監査が含まれます。 SQL Server 監査を使用してサーバー レベルのアクティビティを監査する場合は、各包含 AG 内に同じサーバー監査を作成する必要があります。

初期データ同期

包含システム データベースでは、初期データ同期方法としての自動シード処理のみがサポートされます。

SQL Server 2022 (16.x) 以前のバージョンでは、包含可用性グループは作成時に自動シード処理を使用する必要があります。 SQL Server Management Studio で CREATE AVAILABILITY GROUP ステートメントまたは新しい可用性グループ ウィザードを使用する場合は、自動シード処理をサポートするユーザー データベースのみを含めます。 手動シード処理 (JOIN ONLY) を使用して大規模なデータベースを追加するには、含まれている AG が作成されるまで待ちます。

SQL Server 2025 (17.x) プレビューでは、 CREATE AVAILABILITY GROUP ステートメントで手動シード処理が指定されている場合でも、包含システム データベースでは常に自動シード処理が使用されます。 シード処理モードを手動に設定して包含 AG を作成し、後で自動シード処理以外の同期方法を使用してユーザー データベースを追加できます。

包含システム データベースの復元

包含システム データベースのバックアップを復元するには、次の手順に従います。

  1. 包含 AG を削除します。

  2. 含まれている AG の元のプライマリ レプリカ上に、含まれている master および msdb データベースを復元します。

  3. 含まれている master と msdb データベースをセカンダリ レプリカから削除します。

  4. プライマリ レプリカで、元の名前とノードを使用して、 WITH (CONTAINED, REUSE_SYSTEM_DATABASES) と SEEDING_MODE = AUTOMATIC 構文を使用して、含まれている AG を再作成します。

包含可用性グループを再作成するときは、 CREATE AVAILABILITY GROUP ステートメントに包含システム データベースを含めないでください。 REUSE_SYSTEM_DATABASESが指定されると、SQL Server によって自動的に検出されます。 SQL Server 2022 (16.x) 以前のバージョンでは、自動シード処理をサポートする小規模なユーザー データベースのみが含まれます。 JOIN ONLYを使用して、包含 AG の作成後に大規模なデータベースを個別に追加します。

包含可用性グループのジョブ

包含可用性グループに属するジョブは、プライマリ レプリカでのみ実行されます。 セカンダリ レプリカでは実行されません。

接続する (包含環境)

インスタンスへの接続と包含 AG への接続の違いを区別することが重要です。 包含 AG の環境にアクセスする方法は、包含 AG リスナーに接続するか、包含 AG 内のデータベースに接続するかのみです。

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=MyContainedDatabase;
Server=MyServer;"

ここで MyContainedDatabase は、操作する対象の包含 AG 内のデータベースです。

つまり、包含 AG を効果的に使用するには、包含 AG のリスナーを作成する必要があります。 包含 AG にリスナーを介して直接接続するのではなく、包含 AG をホストするインスタンスの 1 つに接続すると、包含 AG ではなくインスタンスの環境にアクセスします。

たとえば、可用性グループ MyContainedAG がサーバー SERVER\MSSQLSERVER 上でホストされている場合に、リスナー MyContainedAG_Listener に接続するのではなく、SERVER\MSSQLSERVER を使用してインスタンスに接続すると、MyContainedAG の環境ではなくインスタンスの環境にアクセスします。 つまり、インスタンスのシステム データベースにある内容 (ユーザー、アクセス許可、ジョブなど) が適用されます。 包含 AG の包含システム データベースにある内容にアクセスするには、代わりに包含 AG のリスナー (MyContainedAG_Listener など) に接続します。 包含 AG リスナーを介してインスタンスに接続すると、master とやり取りする際に、実際には包含 master データベース (MyContainedAG_master など) にリダイレクトされます。

読み取り専用ルーティングと包含可用性グループ

読み取り目的の接続をセカンダリ レプリカにリダイレクトする読み取り専用ルーティングを構成 (「Always On 可用性グループの読み取り専用ルーティングの構成」を参照) する際に、包含 AG で作成されたログインのみを使用して接続しようとする場合は、その他の考慮事項があります。

  • 包含 AG の一部であるデータベースを接続文字列に指定する必要があります
  • 接続文字列に指定されたユーザーには、包含 AG 内のデータベースにアクセスするためのアクセス許可が必要です。

たとえば、次の接続文字列では、AdventureWorks は MyContainedListener を持つ包含 AG 内のデータベースです。一方、MyUser は包含 AG で定義されたユーザーであり、どの参加インスタンスにも該当しません。

"Persist Security Info=False;
User ID=MyUser;Password=*****;
Initial Catalog=AdventureWorks;
Server=MyContainedListener;
ApplicationIntent=ReadOnly"

この接続文字列を使用すると、ReadOnly ルーティング構成に含まれる読み取り可能なセカンダリに接続され、包含 AG のコンテキストにアクセスします。

インスタンスへの接続と包含可用性グループへの接続の違い

  • 包含 AG に接続すると、ユーザーには、包含 AG 内のデータベースと tempdb のみが表示されます。
  • インスタンス レベルでは、包含 AG の master と msdb の名前は、[contained AG]_master と [contained AG]_msdb です。 包含 AG 内では、名前は master と msdb です。
  • 包含 AG master のデータベース ID は包含 AG 内では 1 ですが、インスタンスに接続すると他のものになります。
  • ユーザーが包含 AG 接続に接続しているときは、sys.databases では包含 AG 外部のデータベースは表示されませんが、それらのデータベースには、3 部構成の名前または、USE コマンドを使うとアクセスできます。
  • sp_configure を介したサーバー構成は、包含 AG 接続から読み取ることができますが、書き込みができるのはインスタンス レベルからのみです。
  • sysadmin は、包含 AG 接続から、インスタンス レベルの操作 (SQL Server のシャットダウンなど) を実行できます。
  • ほとんどのデータベースレベル、エンドポイント レベル、または AG レベルの操作は、包含 AG 接続ではなく、インスタンス接続からのみ実行できます。

他の機能の操作

特定の機能を包含 AG で使用する場合は、さらに考慮事項があります。現在サポートされていない機能がいくつかあります。

バックアップ

包含 AG 内のデータベースをバックアップする手順は、ユーザー データベースのバックアップ手順と同じです。 これは、包含 AG ユーザー データベースと包含 AG システム データベースの両方に当てはまります。

バックアップの場所がローカルの場合、バックアップ ファイルはバックアップ ジョブを実行するサーバーに配置されます。 これは、バックアップ ファイルが別の場所にある可能性があることを意味します。

バックアップの場所がネットワーク リソース上にある場合は、レプリカをホストするすべてのサーバーがそのリソースにアクセスする必要があります。

分散型可用性グループ

分散型可用性グループは、2 つの基になる可用性グループにまたがる特殊な種類の可用性グループです。 分散型可用性グループを構成すると、グローバル プライマリ (最初の AG のプライマリ レプリカ) に加えられた変更が、フォワーダーと呼ばれる 2 番目の AG のプライマリ レプリカにレプリケートされます。

SQL Server 2025 (17.x) プレビュー以降では、2 つの包含 AG 間で分散型可用性グループを構成できます。 包含 AG は包含 master および msdb システム データベースに依存するため、分散型可用性グループを作成するには、2 番目の AG (フォワーダー) にグローバル プライマリと同じ包含 AG システム データベースが必要です。

分散型可用性グループのフォワーダーとして包含 AG を使用する場合は、AUTOSEEDING_SYSTEM_DATABASES ステートメントの WITH | CONTAINED オプションに句を使用して、包含 AG を作成する必要があります。 AUTOSEEDING_SYSTEM_DATABASES句は、SQL Server に対して、独自の包含 AG システム データベースの作成をスキップし、代わりにグローバル プライマリから包含 AG システム データベースをシードするように指示します。

リソース ガバナー

累積的な更新プログラム 18 より前の SQL Server 2022 (16.x) および以前のバージョンの SQL Server では、包含可用性グループ接続でのリソース ガバナーの構成または使用はサポートされていません。

SQL Server 2022 (16.x) 累積的な更新プログラム 18 以降では、インスタンス接続でリソース ガバナーを構成すると、インスタンス接続または包含可用性グループ接続のリソース消費量が想定どおりに管理されます。 含まれている可用性グループ接続でリソース ガバナーを構成しようとすると、エラーが発生します。

リソース ガバナーは、データベース エンジン インスタンス レベルで動作します。 インスタンス レベルでのリソース ガバナーの構成は、可用性レプリカに反映されません。 可用性レプリカをホストする各インスタンスでリソース ガバナーを構成する必要があります。

ヒント

可用性レプリカをホストするすべてのデータベース エンジン インスタンスに対して同じリソース ガバナー構成を使用して、可用性グループのフェールオーバーが発生したときに一貫した動作を確保することをお勧めします。

詳細については、 リソース ガバナーとリソース ガバナー の 構成例とベスト プラクティスを参照してください。

変更データ キャプチャ

変更データ キャプチャ (CDC) は SQL Agent ジョブとして実装されるため、SQL Agent が、包含 AG 内のレプリカを持つすべてのインスタンスで実行されている必要があります。

包含 AG で変更データ キャプチャを使用するには、CDC を構成する際に AG リスナーに接続します。こうすることで、CDC メタデータが包含システム データベースを使用して構成されます。

ログ配布

ログ配布を構成できるのは、ソース データベースが包含 AG 内にある場合です。 ただし、包含 AG 内ではログ配布のターゲットはサポートされていません。 さらに、CDC の構成後にログ配布ジョブを変更する追加の手順があります。

包含 AG でログ配布を構成するには、次の手順に従います。

  1. 包含 AG リスナーに接続します。
  2. 通常どおりログ配布を構成します。
  3. ログ配布ジョブが構成されたら、バックアップを作成する前に、包含 AG リスナーに接続するようにジョブを変更します。

透過的なデータ暗号化 (TDE)

包含 AG 内のデータベースで Transparent Data Encryption (TDE) を使用するには、包含 AG 内の包含 master データベースにデータベース マスター キー (DMK) を手動でインストールします。

TDE を使用するデータベースは、master データベース内の証明書を使用して、データベース暗号化キー (DEK) の暗号化を解除します。 その証明書がない場合、SQL Server は TDE で暗号化されたデータベースの暗号化を解除したり、オンラインにしたりすることはできません。 包含 AG では、SQL Server はデータベースの暗号化を解除するために、両方の DMK の master データベース、インスタンスの master データベース、包含 AG 内の包含 master データベースをチェックします。 どの場所にも証明書がない場合、SQL Server はデータベースをオンラインにすることができません。

インスタンスの master データベースから包含 master データベースに DMK を移すには、「別の SQL Server への TDE で保護されたデータベースの移動」で、古いサーバーから新しいサーバーに DMK を移す箇所を特に参照してください。

注

SQL Server インスタンス上の任意のデータベースを暗号化すると、tempdbシステム データベースも暗号化されます。

SSIS パッケージとメンテナンス計画

メンテナンス計画を含む SSIS パッケージの使用は、包含可用性グループではサポートされていません。

サポートされていません

現在、SQL Server の次の機能は、包含 AG ではサポートされていません。

  • すべての種類 (トランザクション、マージ、スナップショットなど) の SQL Server レプリケーション。
  • ターゲット データベースが包含 AG 内にある場合のログ配布。 ソース データベースが包含 AG にあるログ配布はサポートされています。

DDL の変更

DDL の変更は、CREATE AVAILABILITY GROUP ワークフロー内にのみあります。 WITH句には、次の 2 つのオプションがあります。

<with_option_spec> ::=
CONTAINED [REUSE_SYSTEM_DATABASES | AUTOSEEDING_SYSTEM_DATABASES ]

CONTAINED

これは、作成する AG が包含 AG である必要があることを指定します。

システムデータベースの再利用

REUSE_SYSTEM_DATABASES オプションは、包含 AG に対してのみ有効であり、新しく作成された AG で、同じ名前の以前の包含 AG の既存の包含システム データベースを再利用することを指定します。 たとえば、名前が MyContainedAG という包含 AG があり、これを削除して再作成する場合に、このオプションを使用すると、元の包含システム データベースの内容を再利用できます。 このオプションを使用する場合は、システム データベース名を指定しないでください。 SQL Server によって自動的に検出されます。

AUTOSEEDING_SYSTEM_DATABASES

適用対象: SQL Server 2025 (17.x) プレビュー以降

含まれている AG を分散型可用性グループのフォワーダーとして使用する場合は、含まれている AG をAUTOSEEDING_SYSTEM_DATABASESするときに オプションを使用する必要があります。 このオプションは、SQL Server に対して、独自の包含 AG システム データベースの作成をスキップし、代わりにグローバル プライマリから包含 AG システム データベースをシードするように指示します。

DMV の変更

包含 AG に関連する DMV には、次の 2 つが追加されています。

  • DMV sys.dm_exec_sessions には、列 contained_availability_group_id が追加されています。
  • sys.availability_groups カタログ ビューに、列 is_contained が追加されています。

関連するコンテンツ