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

適用対象:SQL Server

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

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

前提条件

分散型可用性グループを構成するには、次の前提条件を満たしている必要があります。

• サポートされているバージョンの SQL Server。

Note

分散ネットワーク名 (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 DATABASE_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

Note

上記の例では、自動シード処理を使用しています。レプリカと分散型可用性グループの両方について、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

Note

可用性グループがセカンダリ レプリカにデータベースを作成すると、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

Note

セカンダリ可用性グループは、同じデータベース ミラーリング エンドポイント (この例ではポート 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

Note

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 に進みます。

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

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

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

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

分散型可用性グループのフェールオーバー操作

SQL Server 2022 (16.x) では REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT 設定に対する分散型可用性グループのサポートが導入されているため、SQL Server 2022 以降のバージョンでは、分散型可用性をフェールオーバーする手順は SQL Server 2019 以前のバージョンとは異なります。

分散型可用性グループの場合、サポートされているフェールオーバーの種類はユーザーが手動で開始する FORCE_FAILOVER_ALLOW_DATA_LOSS のみです。 したがって、データの損失を防ぐには、フェールオーバーを開始する前に、2 つのレプリカ間でデータが確実に同期されるように、追加の手順 (このセクションで詳しく説明されている) を実行する必要があります。

データ損失が許容される緊急事態が発生した場合、次の内容を実行してデータ同期を確保せずにフェールオーバーを開始できます。

ALTER AVAILABILITY GROUP distributedAG FORCE_FAILOVER_ALLOW_DATA_LOSS;

同じコマンドを使用してフォワーダーにフェールオーバーするだけではなく、グローバル プライマリにフェールバックすることもできます。

SQL Server 2022 以降

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

Note

REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT を 1 に設定すると、プライマリ レプリカは、プライマリ レプリカでコミットされる前にセカンダリ レプリカでトランザクションがコミットされるのを待機するため、パフォーマンスが低下する可能性があります。 分散可用性グループが SQL Server 2022 (16.x) で同期するためには、グローバル プライマリのトランザクションを制限または停止する必要はありませんが、これを行うと、REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT が 1 に設定されたユーザー トランザクションと分散型可用性グループの同期の両方のパフォーマンスが向上する可能性があります。

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

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

1. フェールオーバーを準備するには、グローバル プライマリ とグローバル フォワーダーSYNCHRONOUS_COMMIT モードであることを確認します。 そうでない場合は、ALTER AVAILABILITY GROUP を使用して、それらを SYNCHRONOUS_COMMIT に設定します。
2. グローバル プライマリとフォワーダーの "両方" で、分散型可用性グループを同期コミットに設定します。
3. 分散型可用性グループが同期されるまで待ちます。
4. グローバル プライマリで、ALTER AVAILABILITY GROUP を使用して、分散型可用性グループの 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);
   

   Note

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

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

   -- Run this query on the Global Primary and the forwarder
   
   -- 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);
   

SQL Server 2019 以前

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

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

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

1. グローバル プライマリ可用性グループ データベースで実行されているすべてのトランザクションを停止します。
2. グローバル プライマリフォワーダーとグローバル フォワーダーが SYNCHRONOUS_COMMIT モードであることを確認します。 そうでない場合は、ALTER AVAILABILITY GROUP を使用して、それらを 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;
   

   Note

   分散型可用性グループでは、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);
   

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

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

次の 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 も含まれています。

次の 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)