Настройка распределенной группы доступности 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 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. Подробные инструкции по созданию прослушивателя см. в статье Настройка прослушивателя для группы доступности Always On.

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 2022 и более поздних версий)

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

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

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

Важно!

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

1. Задайте для распределенной группы доступности REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT значение 1.
2. Проверьте готовность к отработке отказа.
3. Возобновите работу первичной группы доступности.
4. Задайте для распределенной группы доступности 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.

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

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