Always On 分散型可用性グループの構成

[アーティクル]
03/18/2023

適用対象:SQL Server

分散型可用性グループを作成するには、それぞれに独自のリスナーを持つ可用性グループをそれぞれ 2 つ作成する必要があります。次に、これらの可用性グループを分散型可用性グループに結合します。次の手順は、Transact-SQL の基本的な例です。この例では、可用性グループとリスナーを作成するすべての手順を取り上げていません。主な要件を強調することに重点を置いています。

分散型可用性グループの技術の概要については、「Distributed availability groups」 (分散可用性グループ) を参照してください。

前提条件

分散ネットワーク名 (DNN) を使って Azure VM 上の SQL Server に可用性グループ用のリスナーを構成した場合、可用性グループの上に分散可用性グループを構成することはサポートされていません。詳しくは、Azure VM 上の SQL Server での AG と DNN リスナーとの機能の相互運用性に関する記事をご覧ください。

エンドポイントリスナーがすべての IP アドレスをリッスンするよう設定する

分散型可用性グループで、エンドポイントが別の可用性グループとも通信できることを確認します。エンドポイント上で 1 つの可用性グループが特定のネットワークに設定されている場合、分散型可用性グループは正しく機能しません。分散型可用性グループ内のレプリカをホストする各サーバーで、リスナーがすべての IP アドレス (LISTENER_IP = ALL) をリッスンするように構成します。

すべての IP アドレスをリッスンするためのエンドポイントを作成する

たとえば、次のスクリプトで、TCP ポート 5022 上ですべての IP アドレスをリッスンするリスナーエンドポイントを作成します。

CREATE ENDPOINT [aodns-hadr] 
    STATE=STARTED
    AS TCP (LISTENER_PORT = 5022, LISTENER_IP = ALL)
FOR DATA_MIRRORING (
   ROLE = ALL, 
   AUTHENTICATION = WINDOWS NEGOTIATE,
   ENCRYPTION = REQUIRED ALGORITHM AES
)
GO

すべての IP アドレスをリッスンするためのエンドポイントを変更する

たとえば、次のスクリプトで、すべての IP アドレスをリッスンするようリスナーエンドポイントを変更します。

ALTER ENDPOINT [aodns-hadr] 
    AS TCP (LISTENER_IP = ALL)
GO

最初の可用性グループを作成する

最初のクラスターにプライマリ可用性グループを作成する

最初の Windows Server フェールオーバークラスター (WSFC) に可用性グループを作成します。この例では、データベース ag1 の db1という可用性グループです。プライマリ可用性グループのプライマリレプリカは、分散型可用性グループではグローバルプライマリと呼ばれます。この例の server1 はグローバルプライマリです。

CREATE AVAILABILITY GROUP [ag1]   
FOR DATABASE db1   
REPLICA ON N'server1' WITH (ENDPOINT_URL = N'TCP://server1.contoso.com:5022',  
    FAILOVER_MODE = AUTOMATIC,  
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,   
    BACKUP_PRIORITY = 50,   
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),   
    SEEDING_MODE = AUTOMATIC),   
N'server2' WITH (ENDPOINT_URL = N'TCP://server2.contoso.com:5022',   
    FAILOVER_MODE = AUTOMATIC,   
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,   
    BACKUP_PRIORITY = 50,   
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),   
    SEEDING_MODE = AUTOMATIC);   
GO

注意

上記の例では、自動シード処理を使用しています。レプリカと分散型可用性グループの両方について、SEEDING_MODE は AUTOMATIC に設定されます。この構成では、確立後に、セカンダリレプリカとセカンダリ可用性グループは自動的に設定されます。プライマリデータベースの手動バックアップと復元を実行する必要はありません。

セカンダリレプリカをプライマリ可用性グループに追加する

ALTER AVAILABILITY GROUP に JOIN オプションを指定して、すべてのセカンダリレプリカを可用性グループに追加する必要があります。この例では自動シード処理を使用しているため、ALTER AVAILABILITY GROUP に GRANT CREATE ANY DATABASE オプションを指定して呼び出す必要もあります。この設定では、可用性グループでデータベースを作成し、プライマリレプリカから自動的にシード処理を開始できるようになります。

この例では、セカンダリレプリカ server2で次のコマンドが実行され、 ag1 可用性グループに追加されます。この可用性グループは、セカンダリ上にデータベースを作成できるようになります。

ALTER AVAILABILITY GROUP [ag1] JOIN   
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE  
GO

注意

可用性グループがセカンダリレプリカにデータベースを作成すると、ALTER AVAILABILITY GROUP ステートメントを実行したアカウントとしてデータベース所有者が設定され、任意のデータベースを作成するアクセス許可が付与されます。詳細については、「セカンダリレプリカの CREATE DATABASE アクセス許可を可用性グループに付与する」を参照してください。

プライマリ可用性グループのリスナーを作成する

次に、プライマリ可用性グループのリスナーを最初の WSFC に追加します。この例では、 ag1-listenerというリスナーです。リスナーの詳細な作成手順については、「可用性グループリスナーの作成または構成 (SQL Server)」を参照してください。

ALTER AVAILABILITY GROUP [ag1]    
    ADD LISTENER 'ag1-listener' ( 
        WITH IP ( ('2001:db88:f0:f00f::cf3c'),('2001:4898:e0:f213::4ce2') ) , 
        PORT = 60173);    
GO

2 つ目の可用性グループを作成する

2 つ目の WSFC に 2 つ目の可用性グループ ag2を作成します。この場合、データベースはプライマリ可用性グループから自動的にシード処理されるため、データベースを指定しません。セカンダリ可用性グループのプライマリレプリカは、分散型可用性グループではフォワーダーと呼ばれます。この例の server3 はフォワーダーです。

CREATE AVAILABILITY GROUP [ag2]   
FOR   
REPLICA ON N'server3' WITH (ENDPOINT_URL = N'TCP://server3.contoso.com:5022',   
    FAILOVER_MODE = MANUAL,   
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,   
    BACKUP_PRIORITY = 50,   
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),   
    SEEDING_MODE = AUTOMATIC),   
N'server4' WITH (ENDPOINT_URL = N'TCP://server4.contoso.com:5022',   
    FAILOVER_MODE = MANUAL,   
    AVAILABILITY_MODE = SYNCHRONOUS_COMMIT,   
    BACKUP_PRIORITY = 50,   
    SECONDARY_ROLE(ALLOW_CONNECTIONS = NO),   
    SEEDING_MODE = AUTOMATIC);   
GO

注意

セカンダリ可用性グループは、同じデータベースミラーリングエンドポイント (この例ではポート 5022) を使用する必要があります。そうしないと、ローカルのフェールオーバー後にレプリケーションは停止します。

セカンダリレプリカをセカンダリ可用性グループに追加する

この例では、セカンダリレプリカ server4で次のコマンドが実行され、 ag2 可用性グループに追加されます。この可用性グループは、自動シード処理をサポートするデータベースをセカンダリ上に作成できるようになります。

ALTER AVAILABILITY GROUP [ag2] JOIN   
ALTER AVAILABILITY GROUP [ag2] GRANT CREATE ANY DATABASE  
GO

セカンダリ可用性グループのリスナーを作成する

次に、セカンダリ可用性グループのリスナーを 2 つ目の WSFC に追加します。この例では、 ag2-listenerというリスナーです。リスナーの詳細な作成手順については、「可用性グループリスナーの作成または構成 (SQL Server)」を参照してください。

ALTER AVAILABILITY GROUP [ag2]    
    ADD LISTENER 'ag2-listener' ( WITH IP ( ('2001:db88:f0:f00f::cf3c'),('2001:4898:e0:f213::4ce2') ) , PORT = 60173);    
GO

最初のクラスターに分散型可用性グループを作成する

最初の WSFC に分散型可用性グループ (この例では distributedag ) を作成します。 CREATE AVAILABILITY GROUP コマンドに DISTRIBUTED オプションを指定して実行します。 AVAILABILITY GROUP ON パラメーターに、メンバー可用性グループの ag1 と ag2 を指定します。

[自動シード処理]
手動シード処理

自動シード処理を使用して分散型可用性グループを作成するには、次の Transact-SQL コードを使用します。

CREATE AVAILABILITY GROUP [distributedag]  
   WITH (DISTRIBUTED)   
   AVAILABILITY GROUP ON  
      'ag1' WITH    
      (   
         LISTENER_URL = 'tcp://ag1-listener.contoso.com:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      ),   
      'ag2' WITH    
      (   
         LISTENER_URL = 'tcp://ag2-listener.contoso.com:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      );    
GO

手動シード処理を使用して分散型可用性グループを作成するには、次の Transact-SQL コードを使用します。

CREATE AVAILABILITY GROUP [distributedag]  
   WITH (DISTRIBUTED)   
   AVAILABILITY GROUP ON  
      'ag1' WITH    
      (   
         LISTENER_URL = 'tcp://ag1-listener.contoso.com:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = MANUAL   
      ),   
      'ag2' WITH    
      (   
         LISTENER_URL = 'tcp://ag2-listener.contoso.com:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = MANUAL   
      );    
GO

注意

LISTENER_URL で、各可用性グループのリスナーと、可用性グループのデータベースミラーリングエンドポイントを指定します。この例では、ポート 5022 です (リスナーの作成に使用したポート 60173 ではありません)。 Azure でインスタンスにロードバランサーを使用している場合、分散型可用性グループのポートの負荷分散の規則を追加します。 SQL Server インスタンスのポートだけでなく、リスナーポートの規則を追加します。

フォワーダーへの自動シード処理を取り消す

何らかの理由で、2 つの可用性グループを同期する前にフォワーダーの初期化を取り消すことが必要になる場合、フォワーダーの SEEDING_MODE パラメーターを MANUAL に設定することで分散型可用性グループを変更し、すぐにシード処理を取り消します。グローバルプライマリでコマンドを実行します。

-- Cancel automatic seeding.  Connect to global primary but specify DAG AG2
ALTER AVAILABILITY GROUP [distributedag]   
   MODIFY  
   AVAILABILITY GROUP ON  
   'ag2' WITH  
   (  SEEDING_MODE = MANUAL  );

2 つ目のクラスターの分散型可用性グループに参加する

次に、2 つ目の WSFC の分散型可用性グループに参加します。

[自動シード処理]
手動シード処理

自動シード処理を使用して分散型可用性グループに参加するには、次の Transact-SQL コードを使用します。

ALTER AVAILABILITY GROUP [distributedag]   
   JOIN   
   AVAILABILITY GROUP ON  
      'ag1' WITH    
      (   
         LISTENER_URL = 'tcp://ag1-listener.contoso.com:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      ),   
      'ag2' WITH    
      (   
         LISTENER_URL = 'tcp://ag2-listener.contoso.com:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC   
      );    
GO

手動シード処理を使用して分散型可用性グループに参加するには、次の Transact-SQL コードを使用します。

ALTER AVAILABILITY GROUP [distributedag]   
   JOIN   
   AVAILABILITY GROUP ON  
      'ag1' WITH    
      (   
         LISTENER_URL = 'tcp://ag1-listener.contoso.com:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = MANUAL   
      ),   
      'ag2' WITH    
      (   
         LISTENER_URL = 'tcp://ag2-listener.contoso.com:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = MANUAL  
      );    
GO

手動シード処理を使用してフォワーダーにデータベースを作成する場合は、グローバルプライマリから完全バックアップとトランザクションログバックアップを実行し、それらを NORECOVERY オプションを指定してフォワーダーに復元します。例:

グローバルプライマリでバックアップするには、次のようにします。

BACKUP DATABASE [db1] 
TO DISK = '<full backup location>' WITH FORMAT
BACKUP LOG [db1] 
TO DISK = '<log backup location>' WITH FORMAT

フォワーダーに復元するには、次のようにします。

RESTORE DATABASE [db1] 
FROM DISK = '<full backup location>' WITH NORECOVERY
RESTORE LOG [db1] FROM DISK = '<log backup location>' WITH NORECOVERY

その後、フォワーダーで次のように実行します。

ALTER DATABASE [db1] SET HADR AVAILABILITY GROUP = [distributedag]

2 つ目の可用性グループのセカンダリ上のデータベースを結合する

2 つ目の可用性グループが自動シーディングを使うように設定されている場合は、手順 2 に進みます。

2 つ目の可用性グループが手動シーディングを使っている場合は、グローバルプライマリで作成したバックアップを 2 つ目の可用性グループのセカンダリに復元します。

RESTORE DATABASE [db1] 
FROM DISK = '<full backup location>' WITH NORECOVERY
RESTORE LOG [db1] FROM DISK = '<log backup location>' WITH NORECOVERY

2 つ目の可用性グループのセカンダリレプリカ上のデータベースが復元状態になったら、それを可用性グループに手動で結合する必要があります。

ALTER DATABASE [db1] SET HADR AVAILABILITY GROUP = [ag2];

セカンダリ可用性グループにフェールオーバーする

セカンダリ可用性グループにフェールオーバーするには、2 つの異なる手順があります。お使いのバージョンと構成に適した手順を使ってください。

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT が設定されている場合、次の手順は SQL Server 2022 (16.x) 以降に適用されます。

他の構成については、「セカンダリにフェールオーバーする (SQL Server 2022 より前)」を参照してください。

次の手順は、分散型可用性グループに対して REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT が設定されていない場合に適用されます。これには SQL Server 2022 (16.x) より前のバージョンが含まれます。なぜなら、この設定は分散型可用性グループではサポートされていないからです。

SQL Server 2022 (16.x) 以降では、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を設定できます。この設定を構成した場合は、「セカンダリ可用性グループにフェールオーバーする (SQL Server 2022 以降)」の手順に従ってください。

セカンダリにフェールオーバーする (SQL Server 2022 より前)

現在のところ、手動フェールオーバーのみがサポートされています。分散型可用性グループを手動でフェールオーバーするには:

データが決して失われないようにするには、グローバルプライマリデータベース (つまり、プライマリ可用性グループのデータベース) でのすべてのトランザクションを停止してから、分散型可用性グループを同期コミットに設定します。
分散型可用性グループが同期され、データベースごとの last_hardened_lsn が同じになるまで待機します。
グローバルプライマリレプリカで、分散型可用性グループのロールを SECONDARY に設定します。
フェールオーバーの準備ができたかテストします。
プライマリ可用性グループにフェールオーバーします。

次の Transact-SQL の例では、distributedag という名前の分散可用性グループをフェールオーバーする詳細な手順を示しています。

データが決して失われないようにするには、グローバルプライマリデータベース (つまり、プライマリ可用性グループのデータベース) でのすべてのトランザクションを停止します。次に、グローバルプライマリとフォワーダーの "両方" で次のコードを実行して、分散型可用性グループを同期コミットに設定します。
```
-- sets the distributed availability group to synchronous commit 
 ALTER AVAILABILITY GROUP [distributedag] 
 MODIFY 
 AVAILABILITY GROUP ON
 'ag1' WITH 
  ( 
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
  ), 
  'ag2' WITH  
  ( 
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
  );

 -- verifies the commit state of the distributed availability group
 select ag.name, ag.is_distributed, ar.replica_server_name, ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc, 
 ars.operational_state_desc, ars.synchronization_health_desc from sys.availability_groups ag  
 join sys.availability_replicas ar on ag.group_id=ar.group_id
 left join sys.dm_hadr_availability_replica_states ars
 on ars.replica_id=ar.replica_id
 where ag.is_distributed=1
 GO
```
注意

分散型可用性グループでは、2 つの可用性グループが同期された状態であるかどうかは、両方のレプリカの可用性モードに依存します。同期コミットモードでは、現在のプライマリ可用性グループと現在のセカンダリ可用性グループの両方が、SYNCHRONOUS_COMMIT 可用性モードである必要があります。このため、グローバルのプライマリレプリカと、フォワーダーの両方で上記のスクリプトを実行する必要があります。
分散型可用性グループの状態が SYNCHRONIZED に変化し、すべてのレプリカの (データベースごとの) last_hardened_lsn が同じになるまで待機します。プライマリ可用性グループのプライマリレプリカであるグローバルプライマリと、フォワーダーの両方に対して次のクエリを実行することで、synchronization_state_desc と last_hardened_lsn を確認します。
```
-- Run this query on the Global Primary and the forwarder
-- Check the results to see if synchronization_state_desc is SYNCHRONIZED, and the last_hardened_lsn is the same per database on both the global primary and       forwarder 
-- If not rerun the query on both side every 5 seconds until it is the case
--
SELECT ag.name
       , drs.database_id
       , db_name(drs.database_id) as database_name
       , drs.group_id
       , drs.replica_id
       , drs.synchronization_state_desc
       , drs.last_hardened_lsn  
FROM sys.dm_hadr_database_replica_states drs 
INNER JOIN sys.availability_groups ag on drs.group_id = ag.group_id;
```
可用性グループ synchronization_state_desc が SYNCHRONIZED になり、さらにグローバルプライマリとフォワーダーの両方でデータベースごとの last_hardened_lsn が同じになったら、先に進みます。 synchronization_state_desc が SYNCHRONIZED ではない場合、または last_hardened_lsn が同じではない場合は、その状態に変化するまで 5 秒間隔でコマンドを実行します。 synchronization_state_desc = SYNCHRONIZED となり、かつデータベースごとの last_hardened_lsn が同じになるまで、先に進まないでください。
グローバルプライマリで、分散型可用性グループのロールを SECONDARY に設定します。
```
ALTER AVAILABILITY GROUP distributedag SET (ROLE = SECONDARY); 
```
この時点で、分散型可用性グループは使用できません。

フェールオーバーの準備をテストします。グローバルプライマリとフォワーダーの両方に対して次のクエリを実行します。

 -- Run this query on the Global Primary and the forwarder
 -- Check the results to see if the last_hardened_lsn is the same per database on both the global primary and forwarder 
 -- The availability group is ready to fail over when the last_hardened_lsn is the same for both availability groups per database
 --
 SELECT ag.name, 
     drs.database_id, 
     db_name(drs.database_id) as database_name,
     drs.group_id, 
     drs.replica_id,
     drs.last_hardened_lsn
 FROM sys.dm_hadr_database_replica_states drs
 INNER JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;

可用性グループは、両方の可用性グループにおいてデータベースごとの last_hardened_lsn が同じである場合に、フェールオーバーできる状態となります。一定の時間が経過しても last_hardened_lsn が同じにならない場合は、データの損失を避けるために、グローバルプライマリ上で次のコマンドを実行することでグローバルプライマリにフェールバックして、2 番目の手順からやり直します。

-- If the last_hardened_lsn is not the same after a period of time, to avoid data loss, 
-- we need to fail back to the global primary by running this command on the global primary 
-- and then start over from the second step:

ALTER AVAILABILITY GROUP distributedag FORCE_FAILOVER_ALLOW_DATA_LOSS;

プライマリ可用性グループからセカンダリ可用性グループにフェールオーバーします。セカンダリ可用性グループのプライマリレプリカをホストする SQL Server であるフォワーダーに対して、次のコマンドを実行します。
```
-- Once the last_hardened_lsn is the same per database on both sides
-- We can Fail over from the primary availability group to the secondary availability group. 
-- Run the following command on the forwarder, the SQL Server instance that hosts the primary replica of the secondary availability group.

ALTER AVAILABILITY GROUP distributedag FORCE_FAILOVER_ALLOW_DATA_LOSS; 
```
この手順の後で、分散型可用性グループが使用できるようになります。

上記の手順が完了すると、データ損失なしで、分散型可用性グループのフェールオーバーが行われます。可用性グループ間の地理的な距離が遅延を引き起こす距離にある場合、可用性モードを ASYNCHRONOUS_COMMIT に変更してください。

セカンダリ可用性グループにフェールオーバーする (SQL Server 2022 以降)

このセクションの手順は、分散型可用性グループがフェールオーバーするときにデータ損失が発生しないことを保証するように設計されています。この手順には、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT の設定が含まれます。分散型可用性グループに対するこの設定は、SQL Server 2022 (16.x) からサポートされています。

現在のところ、手動フェールオーバーのみがサポートされています。分散型可用性グループを手動でフェールオーバーするには:

データが決して失われないようにするには、グローバルプライマリデータベース (つまり、プライマリ可用性グループのデータベース) でのすべてのトランザクションを停止してから、分散型可用性グループを同期コミットに設定します。
分散型可用性グループが同期され、データベースごとの last_hardened_lsn が同じになるまで待機します。
グローバルプライマリレプリカで、分散型可用性グループのロールを SECONDARY に設定します。

重要

この時点で、分散型可用性グループは使用できません。

分散型可用性グループ REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を 1 に設定します。
フェールオーバーの準備ができたかテストします。
プライマリ可用性グループにフェールオーバーします。
分散型可用性グループ REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を 0 に設定します。

次の Transact-SQL の例では、distributedag という名前の分散可用性グループをフェールオーバーする詳細な手順を示しています。

データが決して失われないようにするには、グローバルプライマリデータベース (つまり、プライマリ可用性グループのデータベース) でのすべてのトランザクションを停止します。次に、グローバルプライマリとフォワーダーの "両方" で次のコードを実行して、分散型可用性グループを同期コミットに設定します。
```
-- sets the distributed availability group to synchronous commit 
 ALTER AVAILABILITY GROUP [distributedag] 
 MODIFY 
 AVAILABILITY GROUP ON
 'ag1' WITH 
  ( 
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
  ), 
  'ag2' WITH  
  ( 
  AVAILABILITY_MODE = SYNCHRONOUS_COMMIT 
  );

 -- verifies the commit state of the distributed availability group
 select ag.name, ag.is_distributed, ar.replica_server_name, ar.availability_mode_desc, ars.connected_state_desc, ars.role_desc, 
 ars.operational_state_desc, ars.synchronization_health_desc from sys.availability_groups ag  
 join sys.availability_replicas ar on ag.group_id=ar.group_id
 left join sys.dm_hadr_availability_replica_states ars
 on ars.replica_id=ar.replica_id
 where ag.is_distributed=1
 GO
```
注意

分散型可用性グループでは、2 つの可用性グループが同期された状態であるかどうかは、両方のレプリカの可用性モードに依存します。同期コミットモードでは、現在のプライマリ可用性グループと現在のセカンダリ可用性グループの両方が、SYNCHRONOUS_COMMIT 可用性モードである必要があります。このため、グローバルのプライマリレプリカと、フォワーダーの両方で上記のスクリプトを実行する必要があります。
分散型可用性グループの状態が SYNCHRONIZED に変化し、すべてのレプリカの (データベースごとの) last_hardened_lsn が同じになるまで待機します。プライマリ可用性グループのプライマリレプリカであるグローバルプライマリと、フォワーダーの両方に対して次のクエリを実行することで、synchronization_state_desc と last_hardened_lsn を確認します。
```
-- Run this query on the Global Primary and the forwarder
-- Check the results to see if synchronization_state_desc is SYNCHRONIZED, and the last_hardened_lsn is the same per database on both the global primary and       forwarder 
-- If not rerun the query on both side every 5 seconds until it is the case
--
SELECT ag.name
       , drs.database_id
       , db_name(drs.database_id) as database_name
       , drs.group_id
       , drs.replica_id
       , drs.synchronization_state_desc
       , drs.last_hardened_lsn  
FROM sys.dm_hadr_database_replica_states drs 
INNER JOIN sys.availability_groups ag on drs.group_id = ag.group_id;
```
可用性グループ synchronization_state_desc が SYNCHRONIZED になり、さらにグローバルプライマリとフォワーダーの両方でデータベースごとの last_hardened_lsn が同じになったら、先に進みます。 synchronization_state_desc が SYNCHRONIZED ではない場合、または last_hardened_lsn が同じではない場合は、その状態に変化するまで 5 秒間隔でコマンドを実行します。 synchronization_state_desc = SYNCHRONIZED となり、かつデータベースごとの last_hardened_lsn が同じになるまで、先に進まないでください。
グローバルプライマリで、分散型可用性グループのロールを SECONDARY に設定します。
```
ALTER AVAILABILITY GROUP distributedag SET (ROLE = SECONDARY); 
```
この時点で、分散型可用性グループは使用できません。
SQL Server 2022 (16.x) 以降の場合は、グローバルプライマリで REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を設定します。
```
ALTER AVAILABILITY GROUP distributedag 
  SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
```

フェールオーバーの準備をテストします。グローバルプライマリとフォワーダーの両方に対して次のクエリを実行します。

 -- Run this query on the Global Primary and the forwarder
 -- Check the results to see if the last_hardened_lsn is the same per database on both the global primary and forwarder 
 -- The availability group is ready to fail over when the last_hardened_lsn is the same for both availability groups per database
 --
 SELECT ag.name, 
     drs.database_id, 
     db_name(drs.database_id) as database_name,
     drs.group_id, 
     drs.replica_id,
     drs.last_hardened_lsn
 FROM sys.dm_hadr_database_replica_states drs
 INNER JOIN sys.availability_groups ag ON drs.group_id = ag.group_id;

-- If the last_hardened_lsn is not the same after a period of time, to avoid data loss, 
-- we need to fail back to the global primary by running this command on the global primary 
-- and then start over from the second step:

ALTER AVAILABILITY GROUP distributedag FORCE_FAILOVER_ALLOW_DATA_LOSS;

プライマリ可用性グループからセカンダリ可用性グループにフェールオーバーします。セカンダリ可用性グループのプライマリレプリカをホストする SQL Server であるフォワーダーに対して、次のコマンドを実行します。
```
-- Once the last_hardened_lsn is the same per database on both sides
-- We can Fail over from the primary availability group to the secondary availability group. 
-- Run the following command on the forwarder, the SQL Server instance that hosts the primary replica of the secondary availability group.

ALTER AVAILABILITY GROUP distributedag FORCE_FAILOVER_ALLOW_DATA_LOSS; 
```
この手順の後で、分散型可用性グループが使用できるようになります。
SQL Server 2022 (16.x) 以降の場合は、分散型可用性グループ REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT をクリアします。
```
ALTER AVAILABILITY GROUP distributedag 
  SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);
```

分散型可用性グループを削除する

次の Transact-SQL ステートメントは、 distributedagという分散型可用性グループを削除します。

DROP AVAILABILITY GROUP [distributedag]

フェールオーバークラスターインスタンスに分散可用性グループを作成する

フェールオーバークラスターインスタンス (FCI) で可用性グループを使用して、分散可用性グループを作成することができます。この場合、可用性グループリスナーは必要ありません。 FCI インスタンスのプライマリレプリカに対して仮想ネットワーク名 (VNN) を使用します。次の例は、SQLFCIDAG と呼ばれる分散型可用性グループを示しています。 1 つの可用性グループは SQLFCIAG です。 SQLFCIAG には、2 つの FCI レプリカがあります。プライマリ FCI レプリカの VNN は SQLFCIAG-1 であり、セカンダリ FCI レプリカの VNN は SQLFCIAG 2 です。分散型可用性グループには、ディザスターリカバリーのための SQLAG DR も含まれています。

分散型の AlwaysOn 可用性グループ

次の DDL では、この分散可用性グループが作成されます。

CREATE AVAILABILITY GROUP [SQLFCIDAG]  
   WITH (DISTRIBUTED)   
   AVAILABILITY GROUP ON  
  'SQLFCIAG' WITH    
    (   
        LISTENER_URL = 'tcp://SQLFCIAG-1.contoso.com:5022',    
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC
      ),   
  'SQLAG-DR' WITH    
       (   
         LISTENER_URL = 'tcp://SQLAG-DR.contoso.com:5022',   
         AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,   
         FAILOVER_MODE = MANUAL,   
         SEEDING_MODE = AUTOMATIC
      );

リスナーの URL は、プライマリ FCI インスタンスの VNN です。

分散型可用性グループで FCI を手動でフェールオーバーする

FCI 可用性グループを手動でフェールオーバーするには、分散型可用性グループを更新してリスナー URL の変更を反映します。たとえば、分散型 AG のグローバルプライマリと、SQLFCIDAG の分散型 AG のフォワーダーの両方で、次の DDL を実行します。

ALTER AVAILABILITY GROUP [SQLFCIDAG]  
   MODIFY AVAILABILITY GROUP ON  
 'SQLFCIAG' WITH    
    (   
        LISTENER_URL = 'tcp://SQLFCIAG-2.contoso.com:5022'
    )

次のステップ

CREATE AVAILABILITY GROUP (Transact-SQL)
ALTER AVAILABILITY GROUP (Transact-SQL)

Always On 分散型可用性グループの構成

前提条件

エンドポイントリスナーがすべての IP アドレスをリッスンするよう設定する

すべての IP アドレスをリッスンするためのエンドポイントを作成する

すべての IP アドレスをリッスンするためのエンドポイントを変更する

最初の可用性グループを作成する

最初のクラスターにプライマリ可用性グループを作成する

セカンダリレプリカをプライマリ可用性グループに追加する

プライマリ可用性グループのリスナーを作成する

2 つ目の可用性グループを作成する

セカンダリレプリカをセカンダリ可用性グループに追加する

セカンダリ可用性グループのリスナーを作成する

最初のクラスターに分散型可用性グループを作成する

フォワーダーへの自動シード処理を取り消す

2 つ目のクラスターの分散型可用性グループに参加する

2 つ目の可用性グループのセカンダリ上のデータベースを結合する

セカンダリ可用性グループにフェールオーバーする

セカンダリにフェールオーバーする (SQL Server 2022 より前)

セカンダリ可用性グループにフェールオーバーする (SQL Server 2022 以降)

分散型可用性グループを削除する

フェールオーバークラスターインスタンスに分散可用性グループを作成する

分散型可用性グループで FCI を手動でフェールオーバーする

次のステップ

フィードバック

フィードバック

その他のリソース

Always On 分散型可用性グループの構成

前提条件

エンドポイント リスナーがすべての IP アドレスをリッスンするよう設定する

すべての IP アドレスをリッスンするためのエンドポイントを作成する

すべての IP アドレスをリッスンするためのエンドポイントを変更する

最初の可用性グループを作成する

最初のクラスターにプライマリ可用性グループを作成する

セカンダリ レプリカをプライマリ可用性グループに追加する

プライマリ可用性グループのリスナーを作成する

2 つ目の可用性グループを作成する

セカンダリ レプリカをセカンダリ可用性グループに追加する

セカンダリ可用性グループのリスナーを作成する

最初のクラスターに分散型可用性グループを作成する

フォワーダーへの自動シード処理を取り消す

2 つ目のクラスターの分散型可用性グループに参加する

2 つ目の可用性グループのセカンダリ上のデータベースを結合する

セカンダリ可用性グループにフェールオーバーする

セカンダリにフェールオーバーする (SQL Server 2022 より前)

セカンダリ可用性グループにフェールオーバーする (SQL Server 2022 以降)

分散型可用性グループを削除する

フェールオーバー クラスター インスタンスに分散可用性グループを作成する

分散型可用性グループで FCI を手動でフェールオーバーする

次のステップ

フィードバック

フィードバック

その他のリソース

エンドポイントリスナーがすべての IP アドレスをリッスンするよう設定する

セカンダリレプリカをプライマリ可用性グループに追加する

セカンダリレプリカをセカンダリ可用性グループに追加する

フェールオーバークラスターインスタンスに分散可用性グループを作成する