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

自動シード処理を使用して分散型可用性グループを作成するには、次の 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

自動シード処理を使用して分散型可用性グループに参加するには、次の 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];

SQL Server 2022 (16.x) 以降では、分散型可用性グループの REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 設定を構成できます。分散型可用性グループのフェールオーバー時にデータ損失が保証されるように設計されています。 この設定が構成されている場合、このセクションの手順に従って分散型可用性グループをフェールオーバーします。 REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 設定を使用しない場合、手順に従って SQL Server 2019 以前の分散型可用性グループをフェールオーバーします。

データ損失がないことを確認する手順

データ損失が発生しないようにするには、まず、次の手順に従って、データ損失をサポートしないように分散型可用性グループを構成する必要があります。

1. フェールオーバーを準備するには、グローバル プライマリ と フォワーダーが SYNCHRONOUS_COMMIT モードであることを確認します。 そうでない場合は、SYNCHRONOUS_COMMIT を使用して、それらを に設定します。
2. グローバル プライマリとフォワーダーの "両方" で、分散型可用性グループを同期コミットに設定します。
3. 分散型可用性グループが同期されるまで待ちます。
4. グローバル プライマリで、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を使用して、分散型可用性グループの 設定を 1 に設定します。
5. ローカル AG と分散型可用性グループ内のすべてのレプリカが正常であり、分散型可用性グループが SYNCHRONIZEDされていることを確認します。
6. グローバル プライマリ レプリカで分散型可用性グループのロールを SECONDARY に設定すると、分散型可用性グループが利用できなくなります。
7. フォワーダー (目的の新しいプライマリ) で、ALTER AVAILABILITY GROUP と FORCE_FAILOVER_ALLOW_DATA_LOSSを使用して、分散型可用性グループをフェールオーバーします。
8. 新しいセカンダリ (以前のグローバル プライマリ レプリカ) で、分散型可用性グループの REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を 0 に設定します。
9. 省略可能: 可用性グループが待機時間の原因となる地理的な距離を越える場合は、可用性モードを ASYNCHRONOUS_COMMITに変更します。 これにより、必要に応じて最初の手順からの変更が元に戻されます。

T-SQL の例

このセクションでは、Transact-SQL を使用して distributedAG という名前の分散型可用性グループをフェールオーバーする詳細な例の手順について説明します。 この例の環境では、分散可用性グループに対して合計 4 つのノードがあります。 グローバル プライマリ N1 および N2 ホスト可用性グループ ag1 、フォワーダー N3 および N4 ホスト可用性グループ ag2。 分散型可用性グループ distributedAG は、変更を ag1 から ag2にプッシュします。

1. 分散可用性グループを形成するローカル可用性グループのプライマリで SYNCHRONOUS_COMMIT を確認するクエリ。 フォワーダー と グローバル プライマリで次の T-SQL を直接実行します。

   SELECT DISTINCT ag.name AS [Availability Group],
                   ar.replica_server_name AS [Replica],
                   ar.availability_mode_desc AS [Availability Mode]
   FROM sys.availability_replicas AS ar
        INNER JOIN
        sys.availability_groups AS ag
        ON ar.group_id = ag.group_id
        INNER JOIN
        sys.dm_hadr_database_replica_states AS rs
        ON ar.group_id = rs.group_id
           AND ar.replica_id = rs.replica_id
   WHERE ag.name IN ('ag1', 'ag2')
         AND rs.is_primary_replica = 1
   ORDER BY [Availability Group];
   --if needed, to set a given replica to SYNCHRONOUS for node N1, default instance. If named, change from N1 to something like N1\SQL22
   
   ALTER AVAILABILITY GROUP [testag] MODIFY REPLICA ON N'N1\SQL22' WITH (AVAILABILITY_MODE = SYNCHRONOUS_COMMIT);
   

2. グローバル プライマリとフォワーダーの両方 で次のコードを実行して、分散型可用性グループを同期コミットに設定します。

    -- 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);
   

   注

   分散型可用性グループでは、2 つの可用性グループが同期された状態であるかどうかは、両方のレプリカの可用性モードに依存します。 同期コミット モードでは、現在のプライマリ可用性グループと現在のセカンダリ可用性グループの両方が SYNCHRONOUS_COMMIT 可用性モードを持つ必要があります。 このため、グローバル プライマリ レプリカとフォワーダーの両方でこのスクリプトを実行する必要があります。

3. 分散型可用性グループの状態が SYNCHRONIZEDに変わるまで待ちます。 グローバル プライマリで次のクエリを実行します。

   -- Run this query on the Global Primary
   
   -- Check the results to see if synchronization_state_desc is SYNCHRONIZED
   SELECT ag.name,
          drs.database_id AS [Availability Group],
          db_name(drs.database_id) AS database_name,
          drs.synchronization_state_desc,
          drs.last_hardened_lsn
   FROM sys.dm_hadr_database_replica_states AS drs
        INNER JOIN
        sys.availability_groups AS ag
        ON drs.group_id = ag.group_id
   WHERE ag.name = 'distributedAG'
   ORDER BY [Availability Group];
   

   可用性グループ synchronization_state_desc が SYNCHRONIZED になったら先に進みます。

4. SQL Server 2022 (16.x) 以降のグローバル プライマリでは、次の T-SQL を使用して REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を 1 に設定します。

   ALTER AVAILABILITY GROUP distributedAG SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
   

5. グローバルプライマリ とフォワーダー にクエリを実行することで、すべてのレプリカで可用性グループが正常であることを確認します。

   SELECT ag.name AS [AG Name],
          db_name(drs.database_id) AS database_name,
          ar.replica_server_name AS [replica],
          drs.synchronization_state_desc,
          drs.last_hardened_lsn
   FROM sys.dm_hadr_database_replica_states AS drs
        INNER JOIN
        sys.availability_groups AS ag
        ON drs.group_id = ag.group_id
        INNER JOIN
        sys.availability_replicas AS ar
        ON drs.replica_id = ar.replica_id
           AND drs.replica_id = ar.replica_id
   WHERE ag.name IN ('ag1', 'ag2', 'distributedAG');
   

6. グローバル プライマリで、分散型可用性グループのロールを SECONDARY に設定します。 この時点で、分散型可用性グループは使用できません。 この手順が完了したら、残りの手順が実行されるまでフェールバックすることはできません。

   ALTER AVAILABILITY GROUP distributedAG SET (ROLE = SECONDARY);
   

7. フォワーダーで次のクエリを実行してグローバル プライマリからフェールオーバーし、可用性グループを移行し、分散型可用性グループをオンラインに戻します。

   -- 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;
   

   この手順の後:

   • グローバルプライマリは、N1 から N3に遷移します。
   • フォワーダーは、 N3 から N1に移行します。
   • 分散型可用性グループを使用できます。

8. 新しいフォワーダー (以前のグローバル プライマリ、N1) で、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 分散型可用性グループのプロパティを 0 に設定してクリアします。

   ALTER AVAILABILITY GROUP distributedAG SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);
   

9. "省略可能": 可用性グループ間の地理的な距離が原因で待機時間が発生する場合は、グローバル プライマリとフォワーダーの "両方" で、可用性モードを に戻すことを検討します。ASYNCHRONOUS_COMMIT これにより、必要に応じて、最初の手順で行われた変更が元に戻されます。

    -- If applicable: sets the distributed availability group to asynchronous commit:
    ALTER AVAILABILITY GROUP distributedAG MODIFY AVAILABILITY GROUP ON
    'ag1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT),
    'ag2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);
   

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

データ損失がないことを確認する手順

データ損失が発生しないようにするには、次の手順に従います。

1. グローバル プライマリ可用性グループ データベースで実行されているすべてのトランザクションを停止します。
2. グローバル プライマリとフォワーダーが SYNCHRONOUS_COMMIT モードであることを確認します。 そうでない場合は、SYNCHRONOUS_COMMIT を使用して、それらを に設定します。
3. グローバル プライマリとフォワーダーで、分散型可用性グループを同期コミットに設定します。
4. 分散型可用性グループが同期され、データベースごとに同じ last_hardened_lsn になるまで待ちます。 データベースごとの last_hardened_lsn がレプリカ間で一致するまで待ちます。
5. グローバル プライマリ レプリカで分散型可用性グループのロールを SECONDARY に設定すると、分散型可用性グループが利用できなくなります。
6. グローバル プライマリとフォワーダーで last_hardened_lsn 値が同じであることを確認して、フェールオーバーの準備をテストします。 一致しない場合は、グローバル プライマリにフェールバックし、最初の手順からプロセスを開始します。
7. と一緒に FORCE_FAILOVER_ALLOW_DATA_LOSS を使用し、プライマリ可用性グループをフェールオーバーします。
8. 省略可能: 可用性グループが待機時間の原因となる地理的距離を越える場合は、可用性モードを ASYNCHRONOUS_COMMITに戻します。

T-SQL の例

このセクションでは、Transact-SQL を使用して distributedAG という名前の分散型可用性グループをフェールオーバーする詳細な例の手順について説明します。 この例の環境では、分散可用性グループに対して合計 4 つのノードがあります。 グローバル プライマリ N1 および N2 ホスト可用性グループ ag1 、フォワーダー N3 および N4 ホスト可用性グループ ag2。 分散型可用性グループ distributedAG は、変更を ag1 から ag2にプッシュします。

1. データが決して失われないようにするには、グローバル プライマリ データベース (つまり、プライマリ可用性グループのデータベース) でのすべてのトランザクションを停止します。

2. 分散可用性グループを構成するローカル可用性グループのプライマリで SYNCHRONOUS_COMMIT を確認するクエリ。 フォワーダーとグローバル プライマリで直接実行します。

   SELECT ag.name AS [Availability Group],
          ar.replica_server_name AS [Replica],
          ar.availability_mode_desc AS [Availability Mode]
   FROM sys.availability_replicas AS ar
        INNER JOIN
        sys.availability_groups AS ag
        ON ar.group_id = ag.group_id
        INNER JOIN
        sys.dm_hadr_database_replica_states AS rs
        ON ar.group_id = rs.group_id
           AND ar.replica_id = rs.replica_id
   WHERE ag.name IN ('ag1', 'ag2')
         AND rs.is_primary_replica = 1
   ORDER BY [Availability Group];
   

3. グローバル プライマリとフォワーダーの両方 で次のコードを実行して、分散型可用性グループを同期コミットに設定します。

    -- 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);
   
    -- query to verify the commit state of the distributed availability group
    SELECT
     ag.name,
     ag.is_distributed,
     ar.replica_server_name [Local AG Names],
     ar.availability_mode_desc,
     ars.connected_state_desc,
     ars.role_desc,
     ars.operational_state_desc,
     ars.synchronization_health_desc
    FROM sys.availability_groups ag
    INNER 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 and ag.group_id = ars.group_id
    WHERE ag.is_distributed=1;
   

   注

   分散型可用性グループでは、2 つの可用性グループが同期された状態であるかどうかは、両方のレプリカの可用性モードに依存します。 同期コミット モードでは、現在のプライマリ可用性グループと現在のセカンダリ可用性グループの両方が、SYNCHRONOUS_COMMIT 可用性モードである必要があります。 このため、グローバル プライマリ レプリカとフォワーダーの両方 でこのスクリプトを実行する必要があります。

4. 分散型可用性グループの状態が 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 AS [AG Name],
          ar.replica_server_name AS [replica],
          db_name(drs.database_id) AS database_name,
          drs.synchronization_state_desc,
          drs.last_hardened_lsn
   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_database_replica_states AS drs
        ON drs.replica_id = ar.replica_id
           AND ag.group_id = drs.group_id
   WHERE ag.name IN ('ag1', 'ag2');
   

   可用性グループ synchronization_state_desc が SYNCHRONIZED になり、グローバル プライマリとフォワーダーの "両方" で、last_hardened_lsn がデータベースごとに同じになったら、先に進みます。 synchronization_state_desc が SYNCHRONIZED されていない場合、または last_hardened_lsn が同じでない場合は、変更されるまで 5 秒ごとにコマンドを実行します。 データ損失を防ぐために、synchronization_state_desc = SYNCHRONIZED と last_hardened_lsn がデータベースごとに同じになるまで続行しないでください。

5. グローバル プライマリで、分散型可用性グループロールを SECONDARYに設定します。

   ALTER AVAILABILITY GROUP distributedAG SET (ROLE = SECONDARY);
   

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

6. フェールオーバーの準備をテストします。 SELECT クエリをもう一度実行して、グローバル プライマリとフォワーダーの両方でデータベースごとの last_hardened_lsn を確認します。 グローバル プライマリとフォワーダーの間のすべてのデータベースでlast_hardened_lsnが一致するかどうかを確認します。

7. 前の手順の結果に応じて、次の手順は異なります。

   • SELECT クエリの last_hardened_lsns が一致する場合は、プライマリ可用性グループからセカンダリ可用性グループにフェールオーバーします。 セカンダリ可用性グループのプライマリ レプリカをホストする SQL Server フォワーダーで、ALTER AVAILABILITY GROUP コマンドを実行します。

   • SELECT クエリからしばらくしてもlast_hardened_lsnsが一致しない場合は、グローバルプライマリにフェールオーバーコマンドを実行して、分散AGを元のフォワーダー(N1)に戻します。 次に、最初の手順からプロセスをもう一度開始します。

   -- If the last_hardened_lsns match, you can run the failover query below against the forwarder
   
   -- If the last_hardened_lsns do not match after some time, you can run the failover query against the original global primary
   ALTER AVAILABILITY GROUP distributedAG FORCE_FAILOVER_ALLOW_DATA_LOSS;
   

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

8. 省略可能な: フェールオーバーが成功した後、可用性グループが待機時間が発生する地理的な距離を越えている場合は、可用性モードを ASYNCHRONOUS_COMMIT に戻して、前に行った変更を元に戻す方法を検討してください。

    -- If applicable: sets the distributed availability group to asynchronous commit:
    ALTER AVAILABILITY GROUP distributedAG MODIFY AVAILABILITY GROUP ON
    'ag1' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT),
    'ag2' WITH (AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT);
   

上記の手順が完了したら、データを損失せずに分散型可用性グループのフェールオーバーが行われます。