Настройка распределенной группы доступности Always On

Область применения:SQL Server

Для создания распределенной группы доступности необходимо создать две группы доступности, каждая из которых имеет собственный прослушиватель. После этого можно объединить эти группы доступности в распределенную группу доступности. Ниже представлен простой пример c Transact-SQL. В этом примере представлены не все детали создания групп доступности и прослушивателей; основное внимание уделяется ключевым требованиям.

Технические сведения о распределенных группах доступности см. в статье Распределенные группы доступности.

Необходимые компоненты

Чтобы настроить распределенную группу доступности, необходимо иметь следующее:

• Поддерживаемая версия SQL Server.

Примечание.

Если вы настроили прослушиватель для группы доступности на виртуальной машине Azure с помощью распределенного сетевого имени (DNN), настройка распределенной группы доступности на вершине группы доступности не поддерживается. Дополнительные сведения см. в статье Взаимодействие функций SQL Server на виртуальной машине Azure с группами доступности и прослушивателем DNN.

Настройка прослушивателей конечных точек на прослушивание всех IP-адресов

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

Примечание.

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

Создание прослушивателя для первичной группы доступности

После этого добавьте прослушиватель для первичной группы доступности в первый кластер 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

Создание второй группы доступности

Создайте вторую группу доступности, ag2, во втором кластере WSFC. В этом случае база данных не указана, так как она автоматически заполняется из первичной группы доступности. Первичная реплика вторичной группы доступности называется сервером пересылки в распределенной группе доступности. 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

Создание прослушивателя для вторичной группы доступности

После этого добавьте прослушиватель для вторичной группы доступности во второй кластер 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.

Отменить автоматическое заполнение для сервера пересылки

Если по какой-либо причине необходимо отменить инициализацию сервера пересылки перед синхронизацией двух групп доступности, измените (ALTER) распределенную группу доступности, задав для параметра SEEDING_MODE сервера пересылки значение вручную и немедленно отменив заполнение. Выполните команду в глобальной первичной группе:

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

Присоединение распределенной группы доступности во втором кластере

Присоедините распределенную группу доступности во втором кластере 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

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

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

Если вторая группа доступности была настроена для использования автоматического заполнения, перейдите к шагу 2.

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

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

Отработка отказа распределенной группы доступности

Так как в SQL Server 2022 (16.x) появилась поддержка распределенной группы доступности для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT параметра, инструкции по отработки отказа распределенной доступности отличаются для SQL Server 2022 и более поздних версий, чем для SQL Server 2019 и более ранних версий.

Для распределенной группы доступности единственный поддерживаемый тип отработки отказа является инициированным FORCE_FAILOVER_ALLOW_DATA_LOSSпользователем вручную. Таким образом, чтобы предотвратить потерю данных, необходимо выполнить дополнительные действия (подробно описанные в этом разделе), чтобы убедиться, что данные синхронизированы между двумя репликами перед началом отработки отказа.

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

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 и более ранних версиях.

Примечание.

Установка REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT на значение 1 означает, что главная реплика ждет фиксации транзакций на вторичной реплике, пока не будут зафиксированы на главной реплике, что может снизить производительность. Хотя для синхронизации распределенной группы доступности в SQL Server 2022 (16.x) не требуется ограничение или остановка транзакций в глобальной первичной среде, это может повысить производительность как для транзакций пользователей, так и для синхронизации распределенной группы доступности с REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT задано значение 1.

Действия по обеспечению отсутствия потери данных

Чтобы обеспечить отсутствие потери данных, сначала необходимо настроить распределенную группу доступности, чтобы не потерять данные, выполнив следующие действия.

1. Чтобы подготовиться к отработке отказа, убедитесь, что глобальный основной узел и глобальный сервер пересылки находятся в режиме SYNCHRONOUS_COMMIT. Если нет, установите их в диапазоне от SYNCHRONOUS_COMMIT до ALTER AVAILABILITY GROUP.
2. Задайте распределенной группе доступности синхронный режим фиксации как на , так и на глобальном первичном и агенте-пересылателе.
3. Дождитесь синхронизации распределенной группы доступности.
4. На глобальном основном сервере установите для REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT значение 1, используя команду ALTER AVAILABILITY GROUP.
5. Убедитесь, что все реплики в локальных группах доступности и распределённой группе доступности находятся в рабочем состоянии, а распределённая группа доступности СИНХРОНИЗИРОВАНА.
6. На глобальной первичной реплике задайте для распределенной роли SECONDARYгруппы доступности значение , что делает распределенную группу доступности недоступной.
7. На узле пересылки (предполагаемом новом первичном), выполните переключение распределенной группы доступности с помощью 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 и N2ag1, а также глобальная пересылочная группа доступности узлов N3 и N4ag2. Распределенная группа доступности 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 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];
   

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

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

SQL Server 2019 и более ранних версий

Инструкции в этом разделе применяются, если REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT не задано для распределенной группы доступности, например версий до SQL Server 2022 (16.x), так как они не поддерживают ее для распределенных групп доступности.

Действия по обеспечению отсутствия потери данных

Чтобы убедиться, что потери данных отсутствуют, выполните следующие действия.

1. Остановите все транзакции, выполняемые в базе данных глобальной основной группы доступности.
2. Убедитесь, что глобальный основной сервер и глобальный сервер пересылки находятся в режиме SYNCHRONOUS_COMMIT. Если нет, задайте для них значение SYNCHRONOUS_COMMIT через ALTER AVAILABILITY GROUP.
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

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

   Примечание.

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

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

Удаление распределенной группы доступности

Следующая инструкция Transact-SQL удаляет распределенную группу доступности с именем distributedAG:

DROP AVAILABILITY GROUP distributedAG;

Создание распределенной группы доступности в экземплярах отказоустойчивого кластера

Вы можете создать распределенную группу доступности, используя группу доступности на экземпляре отказоустойчивого кластера (FCI). В этом случае прослушиватель группы доступности не требуется. Используйте имя виртуальной сети (VNN) для первичной реплики экземпляра отказоустойчивого кластера. В следующем примере показана распределенная группа доступности с именем SQLFCIDAG. Группа доступности SQLFCIAG SQLFCIAG содержит две реплики FCI. Имя виртуальной сети для первичной реплики FCI имеет значение SQLFCIAG-1, а для вторичной — 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.

Ручная отработка отказа отказоустойчивого кластера в распределенной группе доступности

Для выполнения ручной отработки отказа в группе доступности отказоустойчивого кластера обновите распределенную группу доступности в соответствии с измененным URL-адресом прослушивателя. Например, выполните следующую команду DDL на глобальном первичном экземпляре распределенной группы доступности и на сервере пересылки распределенной группы доступности SQLFCIDAG:

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)