分散型可用性グループ

[アーティクル]
01/29/2024

適用対象 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 個まで所有することができます。

分散型可用性グループの概要を示す図。

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

分散型可用性グループとそのデータ移動を示す図。

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 または累積更新プログラムをインストールプロセスは、従来の可用性グループと少し異なります。

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

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

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

Windows Server のバージョンが異なる WSFC を含む分散型可用性グループを示す図。

個々の 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 つの主な使用シナリオがあります。

ディザスターリカバリーと簡単なマルチサイト構成
新しいハードウェアまたは構成への移行 (新しいハードウェアの使用、または基になるオペレーティングシステムの変更が含まれる場合があります)
複数の可用性グループを使うことによる、1 つの可用性グループの 8 個を超えた読み取り可能レプリカの数の拡張

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

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

従来のマルチサイト可用性グループを示す図。

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

分散型可用性グループは疎結合されていますが、この場合それは、分散型可用性グループは単一の 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 のプライマリレプリカでもあります。

分散型可用性グループを使用した読み取りのスケールアウトを示す図。

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

分散型可用性グループを使用した読み取りのスケールアウトのもう 1 つの例を示す図。

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

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

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

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

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

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

分散型可用性グループに第 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 が表示されます。

分散型可用性グループの最初の WSFC 上のプライマリレプリカが表示された SQL Server Management Studio のビューのスクリーンショット。

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

操作できるオプションがないことを示すスクリーンショット。

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

SQL Server Management Studio のセカンダリレプリカのスクリーンショット。

すべての可用性レプリカ名を一覧表示する 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) の名前が表示されます。

前のクエリの出力例を示すスクリーンショット。

分散型 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

分散型可用性グループの状態を示すスクリーンショット。

基になるパフォーマンスを表示する 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

分散型可用性グループのパフォーマンス情報を示すスクリーンショット。

分散型 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%'

DAG の OS パフォーマンスカウンターが表示されている DMVのスクリーンショット。

注意

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

AG と分散型 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

分散型 AG のメタデータ DMV のスクリーンショット。

シード処理の現在の状態を表示する 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

シード処理の現在の状態を示すスクリーンショット。

次の方法で共有

分散型可用性グループ

概要

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

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

使用シナリオ

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

移行

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

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

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

正常性の監視

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

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

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

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

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

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

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

フィードバック

その他のリソース

次の方法で共有

分散型可用性グループ

概要

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

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

使用シナリオ

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

移行

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

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

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

正常性の監視

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

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

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

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

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

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

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

関連するコンテンツ

フィードバック

その他のリソース

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

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

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