分散型可用性グループ

適用対象:SQL Server

分散型可用性グループ (AG) は、2 つの異なる可用性グループにまたがる、特殊な種類の可用性グループです。 分散型可用性グループは、SQL Server 2016 以降で使用できます。

この記事では、分散型可用性グループの機能について説明します。 分散型可用性グループの構成方法については、「分散型可用性グループを構成する」をご覧ください。

概要

分散型可用性グループは、2 つの異なる可用性グループにまたがるもので、特殊な種類の可用性グループです。 分散型可用性グループに参加する可用性グループは、同じ場所に存在している必要はありません。 物理、仮想、オンプレミス、パブリック クラウド、または可用性グループの配置をサポートする任意の場所のいずれでもかまいません。 これには、Linux と Windows でホストされている可用性グループの間などの、クロス ドメインおよびクロス プラットフォームが含まれます。 2 つの可用性グループが通信できる限り、それらで分散型可用性グループを構成できます。

従来の可用性グループの場合は、Windows Server フェールオーバー クラスター (WSFC)、または Pacemaker (Linux の場合) 内にリソースが構成されます。 分散型可用性グループの場合は、基になるクラスター (WSFC または Pacemaker) 内に何も構成されません。 分散型可用性グループに関するすべてのものは、SQL Server 内に保持されます。 分散型可用性グループの情報を表示する方法については、「Viewing distributed availability group information」(分散可用性グループの情報を表示する) を参照してください。

分散型可用性グループでは、基になる可用性グループにリスナーが存在する必要があります。 従来の可用性グループではスタンドアロン インスタンスに対して基になるサーバー名を指定しましたが (または、SQL Server フェールオーバー クラスター インスタンス (FCI) の場合は、ネットワーク名リソースに関連付けられた値)、分散型可用性グループでは、可用性グループを作成するときに ENDPOINT_URL パラメーターで分散型可用性グループに構成されているリスナーを指定します。 分散型可用性グループの基になる各可用性グループにはリスナーがありますが、分散型可用性グループにはリスナーはありません。

次の図では、それぞれが専用の WSFC に構成されている 2 つの可用性グループ (AG 1 および AG 2) にまたがる分散型可用性グループの概略を示します。 分散型可用性グループには、可用性グループごとに 2 つずつ、合計で 4 つのレプリカがあります。 可用性グループごとにレプリカの最大数までサポートできるため、分散型の可用性グループではレプリカを最大合計 18 個まで所有することができます。

Diagram showing a high-level view of a distributed availability group.

分散型可用性グループでのデータ移動は、同期または非同期として構成できます。 ただし、分散型可用性グループでのデータの移動は、従来の可用性グループと若干異なります。 各可用性グループにはプライマリ レプリカがありますが、挿入、更新、削除を受け付けることができるのは、分散型可用性グループに参加しているデータベースの 1 つのコピーだけです。 次の図に示すように、AG 1 はプライマリ可用性グループです。 AG 1 のプライマリ レプリカは、AG 1 のセカンダリ レプリカと AG 2 のプライマリ レプリカの両方にトランザクションを送信します。 AG 2 のプライマリ レプリカは、フォワーダーとも呼ばれます。 フォワーダーは、分散型可用性グループのセカンダリ可用性グループのプライマリ レプリカです。 フォワーダーは、プライマリ可用性グループ内のプライマリ レプリカからトランザクションを受信し、それを独自の可用性グループ内のセカンダリ レプリカに転送します。 そしてフォワーダーが、更新された AG 2 のセカンダリ レプリカを保持します。

Diagram showing a distributed availability group and its data movement.

AG 2 のプライマリ レプリカが挿入、更新、削除を受け付けるようにする唯一の方法は、AG 1 から分散型可用性グループを手動でフェールオーバーすることです。 上の図で、AG 1 にはデータベースの書き込み可能なコピーが含まれるため、フェールオーバーを発行すると、AG 2 は挿入、更新、削除を処理できる可用性グループになります。 1 つの分散型可用性グループを別の分散型可用性グループにフェールオーバーする方法については、「セカンダリ可用性グループにフェールオーバーする」を参照してください。

注意

SQL Server 2016 の分散型可用性グループは、FORCE_FAILOVER_ALLOW_DATA_LOSS オプションを使った可用性グループ間のフェールオーバーのみをサポートします。

Note

分散型可用性グループでトランザクション レプリケーションを使う場合、フォワーダー レプリカをパブリッシャーとして構成することはできません。

バージョンとエディションの要件

SQL Server 2017 以降の分散型可用性グループでは、SQL Server の複数のメジャー バージョンを、同じ分散型可用性グループ内に混在させることができます。 読み取り/書き込みプライマリを含む AG は、同じバージョンでも、分散型 AG に参加している他の AR より低くてもかまいません。 他の AG は、同じバージョンか、それより高くてもかまいません。 このシナリオは、アップグレードおよび移行のシナリオを対象としたものです。 たとえば、読み取り/書き込みプライマリ レプリカを含む SQL Server 2016 の AG を、SQL Server 2017 以降にアップグレードまたは移行したい場合、分散型 AG に参加している他の AG を SQL Server 2017 で構成できます。

SQL Server 2012 または 2014 には分散型可用性グループ機能が存在しなかったため、これらのバージョンで作成された可用性グループは、分散型可用性グループに参加できません。

Note

SQL Server のバージョンによっては、Azure サービス (Managed Instance リンクなど) に接続する場合、Standard エディションを使用して分散型可用性グループを構成することも、Standard エディションと Enterprise エディションを組み合わせて構成することもできます。 詳細については、KB5016729 を確認してください。

2 つの異なる可用性グループが存在するため、分散型可用性グループに参加しているレプリカに Service Pack または累積更新プログラムをインストール プロセスは、従来の可用性グループと少し異なります。

  1. 最初に、分散型可用性グループの第 2 の可用性グループのレプリカを更新します。

  2. 分散型可用性グループのプライマリ可用性グループのレプリカに修正プログラムを適用します。

  3. 標準的な可用性グループと同様に、プライマリ可用性グループを (第 2 の可用性グループのプライマリではなく) それ自体のレプリカの 1 つにフェールオーバーして、修正プログラムを適用します。 プライマリ以外のレプリカがない場合は、第 2 の可用性グループに手動でフェールオーバーする必要があります。

Windows Server のバージョンと分散型可用性グループ

分散型可用性グループには複数の可用性グループが含まれ、それぞれに独自の基になる WSFC があります。分散型可用性グループは SQL Server 専用の構成です。 つまり、個々の可用性グループを含む WSFC は、Windows Server のメジャー バージョンが異なっていてもかまいません。 前のセクションで説明したように、SQL Server のメジャー バージョンは同じである必要があります。 次の図では AG 1 と AG 2 が分散型可用性グループに参加しており、最初の図とほとんど同じですが、各 WSFC の Windows Server のバージョンは異なっています。

Diagram showing a distributed availability groups with WSFCs having different versions of Windows Server.

個々の WSFC とそれに対応する可用性グループは、従来の規則に従います。 つまり、ドメインに参加してもしなくてもかまいません (Windows Server 2016 以降)。 2 つの異なる可用性グループを 1 つの分散型可用性グループに結合するときは、4 つのシナリオがあります。

  • 両方の WSFC が同じドメインに参加している。
  • 各 WSFC が異なるドメインに参加している。
  • 1 つの WSFC はドメインに参加していて、もう 1 つの WSFC はドメインに参加していない。
  • どちらの WSFC もドメインに参加していない。

両方の WSFC が同じドメイン (信頼されていないドメイン) に参加している場合、分散型可用性グループを作成するときに特別なことを行う必要ありません。 可用性グループと WSFC が同じドメインに参加していない場合は、ドメインに依存しない可用性グループを作成する場合と同じように、証明書を使って分散型可用性グループを動作させる必要があります。 分散型可用性グループ用に証明書を構成する方法については、「Create a domain-independent availability group」(ドメインに依存しない可用性グループを作成する) のステップ 3 ~ 13 に従ってください。

分散型可用性グループでは、基になる各可用性グループのプライマリ レプリカが相互の証明書を持っている必要があります。 証明書を使わないエンドポイントが既にある場合は、ALTER ENDPOINT を使って証明書を使うようにエンドポイントを再構成します。

使用シナリオ

分散型可用性グループには、次の 3 つの主な使用シナリオがあります。

ディザスター リカバリーとマルチサイトのシナリオ

従来の可用性グループではすべてのサーバーが同じ WSFC の一部である必要があり、複数のデータ センターを使用するのが困難な場合があります。 次の図は、従来のマルチサイト可用性グループのアーキテクチャとデータ フローを示したものです。 1 つのプライマリ レプリカが、すべてのセカンダリ レプリカにトランザクションを送信しています。 この構成は、いくつかの点で分散型可用性グループよりも劣ります。 たとえば、Active Directory (該当する場合) や、WSFC 内のクォーラムに対するミラーリング監視サーバーといったものを、実装する必要があります。 また、ノードの投票の変更など、WSFC の他の側面の考慮も必要になることがあります。

Diagram showing a traditional multi-site availability group.

分散型可用性グループでは、複数のデータ センターにまたがる可用性グループに対して、より柔軟な配置シナリオが提供されます。 ログ配布のような機能が、ディザスター リカバリーなどのシナリオで過去に使われていた場合でも、分散型可用性グループを使うことができます。 ただし、ログ配布とは異なり、分散型可用性グループではトランザクションの適用を遅らせることはできません。 つまり、データが正しく更新または削除されないヒューマン エラーが発生した場合、可用性グループまたは分散型可用性グループでは役に立ちません。

分散型可用性グループは疎結合されていますが、この場合それは、分散型可用性グループは単一の WSFC を必要とせず、SQL Server によって保持されることを意味します。 WSFC は個別に保持され、同期は主に 2 つの可用性グループの間で非同期に行われるため、別のサイトにディザスター リカバリーを構成するのが簡単になります。 各可用性グループのプライマリ レプリカは、独自のセカンダリ レプリカを同期します。

  • 分散型可用性グループに対しては、手動フェールオーバーのみがサポートされています。 データ センターを切り替えるディザスター リカバリーの場合、(まれなケースを除き) 自動フェールオーバーを構成することはできません。
  • 多くの場合は、マルチサイトまたはサブネットの WSFC では従来の項目またはパラメーター (CrossSubnetThreshold など) の一部を設定する必要はありませんが、データ転送の異なるレイヤーでのネットワーク待機時間に注意する必要があります。 違いは、各 WSFC で独自の可用性が維持されていて、クラスターは 4 ノードから成る 1 つの大きなエンティティではないということです。 前の図で示したように、2 つの独立した 2 ノード WSFC で構成されます。
  • ディザスター リカバリーを目的とするアプローチである非同期データ移動を使うことをお勧めします。
  • プライマリ レプリカと第 2 の可用性グループの少なくとも 1 つのセカンダリ レプリカの間に同期データ移動を構成し、分散型可用性グループに同期移動を構成した場合、分散型可用性グループはすべての同期コピーでデータの存在が確認されるまで待機します。 複数の分散型可用性グループがデイジー チェーン (AG1 -> AG2 -> AG3) になっていて、それらが同期するように設定されている場合、分散型可用性グループは、最後の可用性グループの最後のレプリカが更新されるまで待機します。

移行

分散型可用性グループは 2 つのまったく異なる可用性グループの構成をサポートするため、ディザスター リカバリーとマルチサイトのシナリオだけでなく、移行のシナリオも容易になります。 移行先が新しいハードウェアか仮想マシン (オンプレミスまたはパブリック クラウドの IaaS) かに関係なく、分散型可用性グループを構成すると、以前はバックアップ、コピー、復元、またはログ配布を使っていたような状況で、移行を行うことができます。

移行の機能は、SQL Server を同じバージョンにしたまま基になる OS を変更またはアップグレードするシナリオで特に便利です。 Windows Server 2016 では、同じハードウェア上で Windows Server 2012 R2 からローリング アップグレードできますが、ほとんどのユーザーは新しいハードウェアまたは仮想マシンの配置を選びます。

新しい構成への移行を完了するには、プロセスの最後に、元の可用性グループへのすべてのデータ トラフィックを停止し、分散型可用性グループを同期データ移動に変更します。 これにより、第 2 の可用性グループのプライマリ レプリカが完全に同期され、データが失われないことが保証されます。 同期を確認した後、セカンダリ可用性グループに分散型可用性グループをフェールオーバーします。 詳細については、「セカンダリ可用性グループにフェールオーバーする」を参照してください。

移行後には、第 2 の可用性グループが新しいプライマリ可用性グループになり、次のいずれかの手順を行うことが必要な場合があります。

  • セカンダリ可用性グループのリスナーの名前を変更するか (および、場合によっては、元のプライマリ可用性グループの古いリスナーを削除または名前変更します)、または元のプライマリ可用性グループ のリスナーで再作成して、アプリケーションとユーザーが新しい構成にアクセスできるようにします。
  • 名前の変更または再作成が不可能な場合は、アプリケーションおよびユーザーが第 2 の可用性グループのリスナーを参照するようにします。

SQL Server の上位バージョンへの移行

移行シナリオの進行中には、分散型 AG を構成して、ソースよりも新しいバージョンの SQL Server ターゲットにデータベースを移行することはできますが、いくつかの制限事項があります。

ソースよりも新しいバージョンの SQL Server 移行ターゲットを使用して分散型 AG を構成した場合、自動シード処理はサポートされないため、シード処理モードを MANUAL に設定する必要があります。 AUTO-SEEDING を無効にしない場合、移行は失敗し、エラー 946 「データベース 'DistributionAG' バージョン xxx を開けません」が表示されます。 データベースを最新のバージョンにアップグレードしてください" がエラー ログに記録されます。 シード処理モードを MANUAL に設定し、プライマリ AG からのソース データベースの完全バックアップとトランザクション ログ バックアップを手動で実行する必要があります。 次に、トランザクション ログと共にそれを手動でセカンダリ AG に復元します。 詳細については、分散型 AG を構成するための手動シード処理の手順を参照してください。また、プライマリ AG からセカンダリ AG にデータベースをバックアップし、それを復元するためのスクリプトも参照してください。

セカンダリ AG (AG2) が移行ターゲットであり、プライマリ AG (AG1) よりも新しいバージョンである場合は、次の制限事項を考慮してください。

  • プライマリ AG が古いバージョンである限り、セカンダリ AG 上のすべてのレプリカ データベースに対する読み取りアクセス権はありません。
  • この間、更新は引き続きプライマリ AG (AG1) からセカンダリ AG (AG2) に送信されますが、セカンダリ AG の状態は部分的に正常と表示されます。また、セカンダリ AG (AG2) のセカンダ リレプリカ上のデータベースは (AG が同期コミットの場合でも) 同期中または復旧中として表示されます。
  • 分散型 AG が上位バージョン (AG2) にフェールオーバーされると、AG2 は正常になるはずです。
  • この間、AG1 にフェールバックすることはできません。これはバージョンが古いためです。
  • AG1 は古いバージョンであるため、AG2 にフェールオーバーした後の AG2 からの更新は、AG1 にはレプリケートされません。
  • ここから、元の AG (プライマリ) の使用を停止するか、AG1 をアップグレードして分散型 AG を維持するかを選択します。
    • AG1 の使用停止を選択した場合は、元のプライマリ AG を分散型 AG から削除すると、プロセスが完了します。
    • 分散型 AG を維持することを選択した場合は、AG1 の SQL Server バージョンを、AG2 に合わせてアップグレードしてください。 AG1 がアップグレードされると、AG1 が正常になり、分散型 AG が正常になって、レプリカが同期され、フェールバックが可能になります。

読み取り可能なレプリカをスケール アウトする

必要に応じて、1 個の分散型可用性グループで最大 16 個のセカンダリ レプリカを持つことができます。 したがって、別の可用性グループの 2 個のプライマリ レプリカを含めて、最大 18 個のコピーを読み取りに使うことができます。 つまり、このアプローチでは、複数のサイトがレポートのためにさまざまなアプリケーションにほぼリアルタイムでアクセスできます。

分散型可用性グループは、読み取り専用ファームを複数の可用性グループにスケールアウトするのに役立ちます。 分散型可用性グループでは、2 つの方法で読み取り可能レプリカをスケールアウトできます。

  • 分散型可用性グループの第 2 の可用性グループのプライマリ レプリカを使って、別の分散型可用性グループを作成できます (データベースが RECOVERY ではない場合でも)。
  • また、1 番目の可用性グループのプライマリ レプリカを使って、別の分散型可用性グループを作成することもできます。

つまり、1 つのプライマリ レプリカが、異なる分散型可用性グループに参加できます。 次の図では、AG 1 と AG 2 はどちらも分散型 AG 1 に参加しており、AG 2 と AG 3 は分散型 AG 2 に参加しています。 AG 2 のプライマリ レプリカ (フォワーダー) は、分散型 AG 1 のセカンダリ レプリカであると同時に、分散型 AG 2 のプライマリ レプリカでもあります。

Diagram showing scaling out reads with distributed availability groups.

次の図の AG 1 は、2 つの異なる分散型可用性グループ (分散型 AG 1 (AG 1 と AG2 で構成) および分散型 AG 2 (AG 1 と AG 3 で構成)) のプライマリ レプリカになっています。

Diagram showing another example of scaling out of reads using distributed availability groups.

上のどちらの例でも、3 つの可用性グループ全体で最大 27 個のレプリカを持つことができ、そのすべてを読み取り専用クエリに使うことができます。

読み取り専用ルーティングは、分散型可用性グループでは正しく動作しません。 具体的には次のとおりです。

  1. 読み取り専用ルーティングを構成することができ、分散型可用性グループのプライマリ可用性グループに対して動作します。
  2. 読み取り専用ルーティングを構成できますが、分散型可用性グループのセカンダリ可用性グループには動作しません。 すべてのクエリがリスナーを使ってセカンダリ可用性グループに接続する場合は、セカンダリ可用性グループのプライマリ レプリカに移動します。 それ以外の場合は、各レプリカがすべての接続をセカンダリ レプリカとして許可し、それらに直接アクセスするように、構成する必要があります。 ただし、フェールオーバー後に、セカンダリ可用性グループがプライマリになっている場合は、読み取り専用ルーティングは動作します。 この動作は、SQL Server 2016 の更新プログラムまたは SQL Server の将来のバージョンで、変更される可能性があります。

セカンダリ可用性グループの初期化

分散型可用性グループは、第 2 の可用性グループのプライマリ レプリカを初期化するための主要な方法として自動シード処理を使うように設計されています。 第 2 の可用性グループのプライマリ レプリカでの完全なデータベース復元は、次のようにすることで可能です。

  1. WITH NORECOVERY を指定してデータベース バックアップを復元します。
  2. 必要な場合は、適切なトランザクション ログ バックアップを WITH NORECOVERY で復元します。
  3. データベース名を指定せず、SEEDING_MODE を AUTOMATIC に設定して、第 2 の可用性グループを作成します。
  4. 自動シード処理を使って、分散型可用性グループを作成します。

分散型可用性グループに第 2 の可用性グループのプライマリ レプリカを追加すると、レプリカは第 1 の可用性グループのプライマリ データベースと照合され、自動シード処理はソースに合わせてデータベースを更新します。 いくつかの注意事項があります。

  • 第 2 の可用性グループのプライマリ レプリカの sys.dm_hadr_automatic_seeding で示される出力では、current_state が FAILED、理由が "Seeding Check Message Timeout" と表示されます。

  • 第 2 の可用性グループのプライマリ レプリカの現在の SQL Server エラー ログでは、自動シード処理が行われて、LSN が同期されたと表示されます。

  • 第 1 の可用性グループのプライマリ レプリカの sys.dm_hadr_automatic_seeding で示される出力では、current_state が COMPLETED と表示されます。

  • 分散型可用性グループでは自動シード処理の動作も異なります。 第 2 のレプリカで自動シード処理が開始するためには、レプリカで ALTER AVAILABILITY GROUP [AGName] GRANT CREATE ANY DATABASE コマンドを実行する必要があります。 この条件は基になる可用性グループに参加しているすべてのセカンダリ レプリカにやはり当てはまりますが、第 2 の可用性グループのプライマリ レプリカは、分散型可用性グループに追加された後で自動シード処理が開始するために必要な適切なアクセス許可を既に持っています。

正常性の監視

分散型可用性グループは SQL Server のみの構成であり、基になる WSFC では認識されません。 次のコード サンプルの 2 つの異なる WSFC (CLUSTER_A と CLUSTER_B) は、それぞれが独自の可用性グループを持っています。 ここでは、CLUSTER_A の AG1 と CLUSTER_B の AG2 についてのみ説明します。

PS C:\> Get-ClusterGroup -Cluster CLUSTER_A

Name                            OwnerNode             State
----                            ---------             -----
AG1                             DENNIS                Online
Available Storage               GLEN                  Offline
Cluster Group                   JY                    Online
New_RoR                         DENNIS                Online
Old_RoR                         DENNIS                Online
SeedingAG                       DENNIS                Online

PS C:\> Get-ClusterGroup -Cluster CLUSTER_B

Name                            OwnerNode             State
----                            ---------             -----
AG2                             TOMMY                 Online
Available Storage               JC                    Offline
Cluster Group                   JC                    Online

分散型可用性グループの詳細情報は、SQL Server の特に可用性グループの動的管理ビューに表示されます。 現在のところ、分散型可用性グループについて SQL Server Management Studio に表示される情報は、可用性グループのプライマリ レプリカについてのみです。 以下の図のように、SQL Server Management Studio の [可用性グループ] フォルダーに分散型可用性グループが表示されます。 この図では、分散型可用性グループではなく、そのインスタンスでローカルの各可用性グループのプライマリ レプリカとして AG1 が表示されます。

Screenshot from SQL Server Management Studio of the primary replica on the first WSFC of a distributed availability group.

ただし、分散型可用性グループを右クリックしても使用できるオプションが表示されません (次の図を参照)。また、[可用性データベース]、[可用性グループ リスナー]、[可用性レプリカ] の各フォルダーを展開してもすべて空です。 SQL Server Management Studio 16 ではこの結果が表示されますが、今後のバージョンの SQL Server Management Studio では変更される可能性があります。

Screenshot showing no options available for action.

次の図のように、セカンダリ レプリカの場合、分散型可用性グループに関連する情報が SQL Server Management Studio に表示されません。 これらの可用性グループ名は、前に示した図 CLUSTER_A WSFC に表示されるロールにマップされます。

Screenshot from SQL Server Management Studio of a secondary replica.

すべての可用性レプリカ名を一覧表示する DMV

動的管理ビューを使用する場合にも同じ概念が適用されます。 次のクエリを使用すると、すべての可用性グループ (通常と分散型) とそれに参加しているノードが表示されます。 この結果は、分散型可用性グループに参加しているいずれかの WSFC 内のプライマリ レプリカに対してクエリを実行した場合にのみ表示されます。 動的管理ビュー sys.availability_groups には、is_distributed という新しい列があります。可用性グループが分散型可用性グループの場合、これは 1 です。 この列を表示するには:

-- shows replicas associated with availability groups
SELECT
   ag.[name] AS [AG Name],
   ag.Is_Distributed,
   ar.replica_server_name AS [Replica Name]
FROM sys.availability_groups AS ag
INNER JOIN sys.availability_replicas AS ar
   ON ag.group_id = ar.group_id;
GO

次の図は、分散型可用性グループに参加している 2 つ目の WSFC の出力例です。 SPAG1 は、DENNIS と JY という 2 つのレプリカで構成されています。 一方、SPDistAG という分散型可用性グループには、従来の可用性グループのようにインスタンス名ではなく、2 つの参加している可用性グループ (SPAG1 と SPAG2) の名前が表示されます。

Screenshot showing the example output of the preceding query.

分散型 AG の正常性を一覧表示する DMV

SQL Server Management Studio で、ダッシュボードや他の領域に表示される状態は、その可用性グループ内のローカル同期についてのみです。 分散型可用性グループの正常性を表示するには、動的管理ビューに対してクエリを実行します。 次のクエリ例では、前のクエリを拡張して改善しています。

-- shows sync status of distributed AG
SELECT
   ag.[name] AS [AG Name],
   ag.is_distributed,
   ar.replica_server_name AS [Underlying AG],
   ars.role_desc AS [Role],
   ars.synchronization_health_desc AS [Sync Status]
FROM  sys.availability_groups AS ag
INNER JOIN sys.availability_replicas AS ar
   ON  ag.group_id = ar.group_id
INNER JOIN sys.dm_hadr_availability_replica_states AS ars
   ON  ar.replica_id = ars.replica_id
WHERE ag.is_distributed = 1;
GO

Screenshot showing a distributed availability group status.

基になるパフォーマンスを表示する DMV

前のクエリをさらに拡張するために、sys.dm_hadr_database_replicas_states に追加して、動的管理ビューで基となるパフォーマンスを表示することもできます。 現在、動的管理ビューはセカンダリ可用性グループの情報のみを保存しています。 次のクエリ例は、プライマリ可用性グループ上で実行し、以下の出力例を生成します。

-- shows underlying performance of distributed AG
SELECT
   ag.[name] AS [Distributed AG Name],
   ar.replica_server_name AS [Underlying AG],
   dbs.[name] AS [Database],
   ars.role_desc AS [Role],
   drs.synchronization_health_desc AS [Sync Status],
   drs.log_send_queue_size,
   drs.log_send_rate,
   drs.redo_queue_size,
   drs.redo_rate
FROM sys.databases AS dbs
INNER JOIN sys.dm_hadr_database_replica_states AS drs
   ON dbs.database_id = drs.database_id
INNER JOIN sys.availability_groups AS ag
   ON drs.group_id = ag.group_id
INNER JOIN sys.dm_hadr_availability_replica_states AS ars
   ON ars.replica_id = drs.replica_id
INNER JOIN sys.availability_replicas AS ar
   ON ar.replica_id = ars.replica_id
WHERE ag.is_distributed = 1;
GO

Screenshot showing performance information for a distributed availability group.

分散型 AG のパフォーマンス カウンターを表示する DMV

次のクエリでは、特定の分散型可用性グループに関連付けられているパフォーマンス カウンターが表示されます。

-- displays OS performance counters related to the distributed ag named 'distributedag'
SELECT * FROM sys.dm_os_performance_counters WHERE instance_name LIKE '%distributed%'

Screenshot of a DMV displaying OS performance counters for DAG.

Note

LIKE フィルターに分散型可用性グループの名前を指定する必要があります。 この例で、分散型可用性グループの名前は 'distributedag' です。 分散型可用性グループの名前を反映するように LIKE 修飾子を変更します。

AG と分散型 AG の両方の正常性を表示する DMV

次のクエリでは、可用性グループと分散型可用性グループ両方の正常性に関するさまざまな情報が表示されます。 (Tracy Boggiano からの許可を得て再現されています。)

-- displays sync status, send rate, and redo rate of availability groups,
-- including distributed AG
SELECT ag.name AS [AG Name],
    ag.is_distributed,
    ar.replica_server_name AS [AG],
    dbs.name AS [Database],
    ars.role_desc,
    drs.synchronization_health_desc,
    drs.log_send_queue_size,
    drs.log_send_rate,
    drs.redo_queue_size,
    drs.redo_rate,
    drs.suspend_reason_desc,
    drs.last_sent_time,
    drs.last_received_time,
    drs.last_hardened_time,
    drs.last_redone_time,
    drs.last_commit_time,
    drs.secondary_lag_seconds
FROM sys.databases dbs
INNER JOIN sys.dm_hadr_database_replica_states drs
    ON dbs.database_id = drs.database_id
INNER JOIN sys.availability_groups ag
    ON drs.group_id = ag.group_id
INNER JOIN sys.dm_hadr_availability_replica_states ars
    ON ars.replica_id = drs.replica_id
INNER JOIN sys.availability_replicas ar
    ON ar.replica_id = ars.replica_id
--WHERE ag.is_distributed = 1
GO

Screenshot showing the health of an AG and distributed AG.

分散型 AG のメタデータを表示する DMV

次のクエリでは、分散型可用性グループを含め、可用性グループが使用しているエンドポイント URL に関する情報が表示されます。 (David Barbarin からの許可を得て再現されています。)

-- shows endpoint url and sync state for ag, and dag
SELECT
   ag.name AS group_name,
   ag.is_distributed,
   ar.replica_server_name AS replica_name,
   ar.endpoint_url,
   ar.availability_mode_desc,
   ar.failover_mode_desc,
   ar.primary_role_allow_connections_desc AS allow_connections_primary,
   ar.secondary_role_allow_connections_desc AS allow_connections_secondary,
   ar.seeding_mode_desc AS seeding_mode
FROM sys.availability_replicas AS ar
JOIN sys.availability_groups AS ag
   ON ar.group_id = ag.group_id;
GO

Screenshot of the metadata DMV for distributed AG.

シード処理の現在の状態を表示する DMV

次のクエリでは、シード処理の現在の状態に関する情報が表示されます。 このクエリは、レプリカ間の同期エラーを解決するために役立ちます。 (David Barbarin からの許可を得て再現されています。)

-- shows current_state of seeding
SELECT ag.name AS aag_name,
    ar.replica_server_name,
    d.name AS database_name,
    has.current_state,
    has.failure_state_desc AS failure_state,
    has.error_code,
    has.performed_seeding,
    has.start_time,
    has.completion_time,
    has.number_of_attempts
FROM sys.dm_hadr_automatic_seeding AS has
INNER JOIN sys.availability_groups AS ag
    ON ag.group_id = has.ag_id
INNER JOIN sys.availability_replicas AS ar
    ON ar.replica_id = has.ag_remote_replica_id
INNER JOIN sys.databases AS d
    ON d.group_database_id = has.ag_db_id;
GO

Screenshot showing the current state of seeding.