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

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

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

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

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

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

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

Примечание.

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

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

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

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

1. Остановите все транзакции в глобальных базах данных-источниках (т. е. базы данных основной группы доступности)
2. Задайте для распределенной группы доступности синхронную фиксацию.
3. Подождите, пока распределенная группа доступности синхронизируется и все базы данных в ней получат одинаковое значение last_hardened_lsn.

После синхронизации данных можно выполнить отработку отказа распределенной группы доступности:

1. На глобальной первичной реплике задайте для распределенной роли SECONDARYгруппы доступности значение , что делает распределенную группу доступности недоступной.
2. Задайте для распределенной группы REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT доступности значение 1 с помощью ALTER AVAILABILITY GROUP.
3. Проверьте готовность к отработке отказа.
4. Отработка отказа основной группы доступности с помощью ALTER AVAILABILITY GROUPFORCE_FAILOVER_ALLOW_DATA_LOSS.
5. Задайте для распределенной группы доступности REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT значение 0.

В следующих примерах Transact-SQL показаны подробные шаги по отработке отказа распределенной группы доступности с именем distributedag:

1. Чтобы избежать потерь данных, остановите все транзакции в глобальных базах данных-источниках (то есть базах данных в первичной группе доступности). Затем настройте для распределенной группы доступности синхронную фиксацию, выполнив приведенный ниже код в обеих репликах (глобальной основной и пересылки).

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

   Примечание.

   В распределенной группе доступности состояние синхронизации между двумя группами доступности зависит от режима доступности обеих реплик. Для режима синхронной фиксации текущая основная группа доступности и текущая вторичная группа доступности должны иметь SYNCHRONOUS_COMMIT режим доступности. По этой причине необходимо запустить предыдущий сценарий как на глобальной первичной реплике, так и на сервере пересылки.

2. Подождите, пока состояние распределенной группы доступности изменится на 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 не совпадают, выполняйте команду каждые пять секунд, пока значения не изменятся. Не продолжайте работу до установки значения synchronization_state_desc = SYNCHRONIZED и совпадения значений last_hardened_lsn для каждой базы данных.

3. В глобальной первичной реплике задайте для роли группы доступности значение SECONDARY.

   ALTER AVAILABILITY GROUP distributedag SET (ROLE = SECONDARY); 
   

   На этом этапе распределенная группа доступности недоступна.

4. Для SQL Server 2022 (16.x) и более поздних версий задайте REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

   ALTER AVAILABILITY GROUP distributedag 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
   

5. Проверьте готовность к отработке отказа. Выполните следующий запрос как в глобальной первичной реплике, так и в реплике пересылки:

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

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

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

   После этого этапа распределенная группа доступности будет доступна.

7. Для SQL Server 2022 (16.x) и более поздних версий очистите распределенную группу REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMITдоступности.

   ALTER AVAILABILITY GROUP distributedag 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);
   

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

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

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

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

1. Остановите все транзакции в глобальных базах данных-источниках (то есть базы данных основной группы доступности).
2. Задайте для распределенной группы доступности синхронную фиксацию.
3. Подождите, пока распределенная группа доступности синхронизируется и все базы данных в ней получат одинаковое значение last_hardened_lsn.

После синхронизации данных можно выполнить отработку отказа распределенной группы доступности:

1. На глобальной первичной реплике задайте для распределенной роли SECONDARYгруппы доступности значение , что делает распределенную группу доступности недоступной.
2. Проверьте готовность к отработке отказа.
3. Отработка отказа основной группы доступности с помощью ALTER AVAILABILITY GROUPFORCE_FAILOVER_ALLOW_DATA_LOSS.

В следующем примере Transact-SQL пошагово демонстрируется отработка отказа распределенной группы доступности с именем distributedag:

1. Чтобы избежать потерь данных, остановите все транзакции в глобальных базах данных-источниках (то есть базах данных в первичной группе доступности). Затем настройте для распределенной группы доступности синхронную фиксацию, выполнив приведенный ниже код в обеих репликах (глобальной основной и пересылки).

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

   Примечание.

   В распределенной группе доступности состояние синхронизации между двумя группами доступности зависит от режима доступности обеих реплик. В режиме синхронной фиксации текущие первичная и вторичная группы доступности должны быть настроены с использованием режима доступности SYNCHRONOUS_COMMIT. По этой причине приведенный выше скрипт необходимо выполнить как в глобальной первичной реплике, так и в реплике пересылки.

2. Подождите, пока состояние распределенной группы доступности изменится на 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 не совпадают, выполняйте команду каждые пять секунд, пока значения не изменятся. Не продолжайте работу до установки значения synchronization_state_desc = SYNCHRONIZED и совпадения значений last_hardened_lsn для каждой базы данных.

3. В глобальной первичной реплике задайте для роли группы доступности значение SECONDARY.

   ALTER AVAILABILITY GROUP distributedag SET (ROLE = SECONDARY); 
   

   На этом этапе распределенная группа доступности недоступна.

4. Проверьте готовность к отработке отказа. Выполните следующий запрос как в глобальной первичной реплике, так и в реплике пересылки:

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

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

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

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

Следующая инструкция 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)