Настройка распределенной группы доступности 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

Если для создания базы данных на сервере переадресации используется заполнение вручную, выполните полное резервное копирование и создайте резервную копию журнала транзакций на глобальном первичном сервере, а затем выполните восстановление на сервере переадресации с параметром NONRECOVERY. Например:

Чтобы создать резервную копию на глобальном основном сервере:

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_COMMITALTER AVAILABILITY GROUP.
2. Задайте распределенной группе доступности синхронный режим фиксации как на , так и на глобальном первичном и агенте-пересылателе.
3. Дождитесь синхронизации распределенной группы доступности.
4. В глобальной первичной группе доступности задайте для параметра распределенной группы REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT доступности значение 1 с помощью ALTER AVAILABILITY GROUP.
5. Убедитесь, что все реплики в локальных группах доступности и распределённой группе доступности находятся в рабочем состоянии, а распределённая группа доступности СИНХРОНИЗИРОВАНА.
6. На глобальной первичной реплике установите для роли распределенной группы доступности значение SECONDARY, что сделает распределенную группу доступности недоступной.
7. На сервере forwarder (предполагаемом новом первичном сервере) выполните отработку отказа распределенной группы доступности с помощью ALTER AVAILABILITY GROUP и FORCE_FAILOVER_ALLOW_DATA_LOSS.
8. В новой вторичной (предыдущей глобальной первичной реплике) задайте для распределенной группы доступности REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT значение 0.
9. Необязательно. Если группы доступности находятся на географическом расстоянии, что приводит к задержке, измените режим доступности на ASYNCHRONOUS_COMMIT. При необходимости это отменяет изменения, внесенные на первом шаге.

Пример T-SQL

В этом разделе приводятся шаги в подробном примере для переключения распределенной группы доступности с именем distributedAG с помощью Transact-SQL. В примере среды имеется всего 4 узла для распределенной группы доступности. Глобальная первичная группа доступности узлов N1 и N2, а также группа доступности узлов пересылки ag1 и N4. Распределенная группа доступности 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);
   

   Примечание.

   В распределенной группе доступности состояние синхронизации между двумя группами доступности зависит от режима доступности обеих реплик. Для режима синхронной фиксации текущая основная группа доступности и текущая вторичная группа доступности должны быть настроены с режимом доступности 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];
   

   Продолжайте после того, как группы доступности будет .

4. Для SQL Server 2022 (16.x) и более поздних версий в глобальной основной среде задайте для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT значение 1 с помощью следующего T-SQL:

   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_COMMITALTER AVAILABILITY GROUP.
3. Задайте распределенную группу доступности синхронную фиксацию на глобальном первичном сервере и сервере пересылки.
4. Подождите, пока распределенная группа доступности не будет синхронизирована и имеет одинаковые last_hardened_lsn для каждой базы данных. Подождите, пока last_hardened_lsn для базы данных совпадет между репликами.
5. На глобальной первичной реплике установите для роли распределенной группы доступности значение SECONDARY, что сделает распределенную группу доступности недоступной.
6. Проверьте готовность к отказоустойчивости, убедившись, что значения last_hardened_lsn одинаковы на основном сервере и сервере пересылки. Если они не соответствуют, вернитесь к глобальному первичному и начните процесс заново с первого шага.
7. Выполните отработку отказа основной группы доступности с помощью ALTER AVAILABILITY GROUP и FORCE_FAILOVER_ALLOW_DATA_LOSS.
8. Необязательно. Если группы доступности находятся на географическом расстоянии, что приводит к задержке, измените режим доступности обратно на ASYNCHRONOUS_COMMIT.

Пример T-SQL

В этом разделе приводятся шаги в подробном примере для переключения распределенной группы доступности с именем distributedAG с помощью Transact-SQL. В примере среды имеется всего 4 узла для распределенной группы доступности. Глобальная первичная группа доступности узлов N1 и N2, а также группа доступности узлов пересылки ag1 и N4. Распределенная группа доступности 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;
   

   Примечание.

   В распределенной группе доступности состояние синхронизации между двумя группами доступности зависит от режима доступности обеих реплик. Для режима синхронной фиксации текущая первичная группа доступности и текущая вторичная группа доступности должны иметь режим доступности 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 не совпадает, выполняйте команду каждые пять секунд, пока одно из них не изменится. Чтобы предотвратить потерю данных, не продолжайте работу до тех пор, пока 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. В зависимости от результата предыдущего шага следующий шаг будет отличаться.

   • Если last_hardened_lsns совпадают в результате выполнения запроса SELECT, переключитесь с основной группы доступности на вторичную группу доступности. Выполните команду ALTER AVAILABILITY GROUP на сервере-перенаправителе — экземпляре SQL Server, на котором размещена первичная реплика вторичной группы доступности.

   • Если через некоторое время last_hardened_lsnsне совпадают с результатами запроса SELECT, выполните переключение распределенной группы доступности обратно на исходный сервер пересылки (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);
   

После выполнения этих действий распределенная группа доступности выполняет отработку отказа без потери данных.