Configurar um grupo de disponibilidade Always On distribuído

Aplica-se a:SQL Server

Para criar um grupo de disponibilidade distribuído, você deve criar dois grupos de disponibilidade, cada um com seu próprio ouvinte. Em seguida, você combina esses grupos de disponibilidade em um grupo de disponibilidade distribuída. As etapas a seguir fornecem um exemplo básico em Transact-SQL. Este exemplo não abrange todos os detalhes da criação de grupos de disponibilidade e ouvintes, focando apenas nos requisitos básicos.

Para obter uma visão geral técnica dos grupos de disponibilidade distribuídos, consulte Grupos de disponibilidade distribuídos.

Pré-requisitos

Se você configurou o ouvinte para o grupo de disponibilidade em seu SQL Server na VM do Azure usando um DNN (nome de rede distribuído), não há suporte para a configuração de um grupo de disponibilidade distribuído na parte superior do grupo de disponibilidade. Para saber mais, confira SQL Server na interoperabilidade de recursos de VM do Azure com o ouvinte AG e DNN.

Definir os ouvintes do ponto de extremidade para escutar em todos os endereços IP

Verifique se os pontos de extremidade podem se comunicar entre os diferentes grupos de disponibilidade no grupo de disponibilidade distribuído. Se um grupo de disponibilidade for definido como uma rede específica no ponto de extremidade, o grupo de disponibilidade distribuída não funcionará corretamente. Em cada servidor que hospeda uma réplica no grupo de disponibilidade distribuído, configure o ouvinte para ouvir em todos os endereços IP (LISTENER_IP = ALL).

Criar um ponto de extremidade para escutar todos os endereços IP

Por exemplo, o script a seguir cria um ponto de extremidade do ouvinte na porta TCP 5022 que escuta em todos os endereços 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

Alterar um ponto de extremidade para escutar todos os endereços IP

Por exemplo, o script a seguir altera um ponto de extremidade do ouvinte para que ele escute em todos os endereços IP.

ALTER ENDPOINT [aodns-hadr] 
    AS TCP (LISTENER_IP = ALL)
GO

Criar o primeiro grupo de disponibilidade

Criar o grupo de disponibilidade primário no primeiro cluster

Crie um grupo de disponibilidade no primeiro WSFC (cluster de failover do Windows Server). Neste exemplo, o grupo de disponibilidade é denominado ag1 para o banco de dados db1. A réplica primária do grupo de disponibilidade primário é conhecida como a primária global em um grupo de disponibilidade distribuído. Neste exemplo, a primária global é o servidor1.

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  
  

Observação

O exemplo anterior usa a propagação automática, em que SEEDING_MODE é definido como AUTOMATIC para as réplicas e o grupo de disponibilidade distribuído. Essa configuração define que as réplicas secundárias e o grupo de disponibilidade secundário serão preenchidos automaticamente sem a necessidade de backup e restauração manual do banco de dados primário.

Unir as réplicas secundárias ao grupo de disponibilidade primário

Qualquer réplica secundária deve ser unida ao grupo de disponibilidade com ALTER AVAILABILITY GROUP usando a opção JOIN . Como a propagação automática é usada neste exemplo, você também deve chamar ALTER AVAILABILITY GROUP com a opção GRANT CREATE ANY DATABASE. Essa configuração permite que o grupo de disponibilidade crie o banco de dados e comece propagá-lo automaticamente da réplica primária.

Neste exemplo, os seguintes comandos são executados na réplica secundária, server2, para unir o grupo de disponibilidade ag1 . O grupo de disponibilidade então pode criar bancos de dados na réplica secundária.

ALTER AVAILABILITY GROUP [ag1] JOIN   
ALTER AVAILABILITY GROUP [ag1] GRANT CREATE ANY DATABASE  
GO  

Observação

Quando o grupo de disponibilidade cria um banco de dados em uma réplica secundária, ele define o proprietário do banco de dados como a conta que executou a instrução ALTER AVAILABILITY GROUP para conceder permissão para criar qualquer banco de dados. Para obter mais informações, consulte Conceder permissão para criar banco de dados na réplica secundária do grupo de disponibilidade.

Criar um ouvinte para o grupo de disponibilidade primário

Em seguida, crie um ouvinte para o grupo de disponibilidade primário no primeiro WSFC. Neste exemplo, o ouvinte é denominado ag1-listener. Para obter instruções detalhadas sobre como criar um ouvinte, confira Criar ou configurar um ouvinte do grupo de disponibilidade (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  

Criar o segundo grupo de disponibilidade

Em seguida, no segundo WSFC, crie um segundo grupo de disponibilidade, ag2. Neste caso, o banco de dados não é especificado, pois ele é propagado automaticamente do grupo de disponibilidade primário. A réplica primária do grupo de disponibilidade secundário é conhecida como o encaminhador em um grupo de disponibilidade distribuído. Neste exemplo, o servidor3 é o encaminhador.

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  

Observação

O grupo de disponibilidade secundário deve usar o mesmo ponto de extremidade de espelhamento do banco de dados (no exemplo, a porta 5022). Caso contrário, a replicação será interrompida após um failover local.

Unir as réplicas secundárias ao grupo de disponibilidade secundário

Neste exemplo, os seguintes comandos são executados na réplica secundária, server4, para unir o grupo de disponibilidade ag2 . O grupo de disponibilidade então pode criar bancos de dados na réplica secundária para oferecer suporte à propagação automática.

ALTER AVAILABILITY GROUP [ag2] JOIN   
ALTER AVAILABILITY GROUP [ag2] GRANT CREATE ANY DATABASE  
GO  

Criar um ouvinte para o grupo de disponibilidade secundário

Em seguida, crie um ouvinte para o grupo de disponibilidade secundário no segundo WSFC. Neste exemplo, o ouvinte é denominado ag2-listener. Para obter instruções detalhadas sobre como criar um ouvinte, confira Criar ou configurar um ouvinte do grupo de disponibilidade (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  

Criar um grupo de disponibilidade distribuído no primeiro cluster

No primeiro WSFC, crie um grupo de disponibilidade distribuído (denominado distributedag neste exemplo). Use o comando CREATE AVAILABILITY GROUP com a opção DISTRIBUTED . O parâmetro AVAILABILITY GROUP ON especifica os grupos de disponibilidade membros, ag1 e ag2.

Propagação automática

Para criar seu grupo de disponibilidade distribuída usando a propagação automática, use o seguinte código 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   

Propagação manual

Para criar seu grupo de disponibilidade distribuída usando a propagação manual, use o seguinte código 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   

Observação

O LISTENER_URL especifica o ouvinte para cada grupo de disponibilidade, juntamente com o ponto de extremidade de espelhamento de banco de dados do grupo de disponibilidade. Neste exemplo, esse ponto de extremidade é a porta 5022 (não a porta 60173 usada para criar o ouvinte). Se você estiver usando um balanceador de carga, por exemplo, no Azure, adicione uma regra de balanceamento de carga à porta do grupo de disponibilidade distribuído. Adicione a regra à porta do ouvinte, além da porta da instância do SQL Server.

Cancelar a propagação automática para o encaminhador

Se, por qualquer motivo, for necessário cancelar a inicialização do encaminhador antes de os dois grupos de disponibilidade serem sincronizados, ALTERE o grupo de disponibilidade distribuído definindo o parâmetro SEEDING_MODE do encaminhador como MANUAL e cancele imediatamente a propagação. Execute o comando no primário global:

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

Ingressar o grupo de disponibilidade distribuído no segundo cluster

Em seguida, una o grupo de disponibilidade distribuída no segundo WSFC.

Propagação automática

Para ingressar em seu grupo de disponibilidade distribuída usando a propagação automática, use o seguinte código 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  

Propagação manual

Para ingressar em seu grupo de disponibilidade distribuída usando a propagação manual, use o seguinte código 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  

Se a propagação manual for usada para criar o banco de dados no encaminhador, execute um backup completo e um backup de log de transações do primário global e restaure-os para o encaminhador com a opção NORECOVERY. Por exemplo:

Para fazer backup no primário global:

BACKUP DATABASE [db1] 
TO DISK = '<full backup location>' WITH FORMAT
BACKUP LOG [db1] 
TO DISK = '<log backup location>' WITH FORMAT

Para restaurar para o encaminhador:

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

Depois disso, execute o seguinte no encaminhador

ALTER DATABASE [db1] SET HADR AVAILABILITY GROUP = [distributedag]

Ingressar no banco de dados no secundário do segundo grupo de disponibilidade

Se o segundo grupo de disponibilidade foi configurado para usar a propagação automática, vá para a etapa 2.

1. Se o segundo grupo de disponibilidade está usando propagação manual, restaure o backup que você fez no primário global para o secundário do segundo grupo de disponibilidade:

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

2. Depois que o banco de dados na réplica secundária do segundo grupo de disponibilidade tiver entrado em um estado de repouso, será necessário uni-o manualmente ao grupo de disponibilidade.

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

Fazer failover em um grupo de disponibilidade secundário

Há dois conjuntos diferentes de instruções para fazer failover para um grupo de disponibilidade secundário. Use as instruções apropriadas para sua versão e configuração.

As instruções abaixo se aplicarão ao SQL Server 2022 (16.x) ou posterior, se REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT estiver definido.

Para outras configurações, confira Fazer failover para secundário (antes do SQL Server 2022).

Fazer failover para um grupo de disponibilidade secundário (SQL Server 2022 e posterior)

As etapas nesta seção foram projetadas para garantir que não haja perda de dados quando um grupo de disponibilidade distribuído falhar. As etapas incluem a configuração REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT. O suporte para essa configuração para grupos de disponibilidade distribuídos começa com o SQL Server 2022 (16.x).

No momento, apenas o failover manual é permitido. Para fazer failover manual de um grupo de disponibilidade distribuído:

1. Para verificar se nenhum dado foi perdido, interrompa todas as transações nos bancos de dados primários globais (ou seja, bancos de dados do grupo de disponibilidade primário) e defina o grupo de disponibilidade distribuído como commit síncrono.
2. Aguarde até que o grupo de disponibilidade distribuído seja sincronizado e tenha o mesmo last_hardened_lsn por banco de dados.
3. Na réplica primária global, defina a função do grupo de disponibilidade distribuído como SECONDARY.

Importante

Neste ponto, o grupo de disponibilidade distribuído não está disponível.

1. Defina o grupo de disponibilidade distribuído REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT como 1.
2. Teste a prontidão de failover.
3. Faça failover do grupo de disponibilidade para o site primário.
4. Defina o grupo de disponibilidade distribuído REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT como 0.

Os exemplos de Transact-SQL a seguir demonstram as etapas detalhadas para fazer failover do grupo de disponibilidade distribuído denominado distributedag:

1. Para verificar se nenhum dado foi perdido, interrompa todas as transações nos bancos de dados primários globais (ou seja, bancos de dados do grupo de disponibilidade primário). Em seguida, defina o grupo de disponibilidade distribuído como commit síncrono executando o código a seguir em ambos, no primário global e no encaminhador.

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

   Observação

   Em um grupo de disponibilidade distribuído, o status de sincronização entre os dois grupos de disponibilidade depende do modo de disponibilidade de ambas as réplicas. Para o modo de confirmação síncrona, tanto o grupo de disponibilidade primária quanto o grupo de disponibilidade secundária atuais precisam ter o modo de disponibilidade SYNCHRONOUS_COMMIT. Por esse motivo, você precisa executar o script acima, tanto na réplica primária global quanto no encaminhador.

2. Aguarde até que o status do grupo de disponibilidade distribuído seja alterado para SYNCHRONIZED e todas as réplicas tenham o mesmo last_hardened_lsn (por banco de dados). Execute a seguinte consulta no primário global, que é a réplica primária do grupo de disponibilidade primário, bem como o encaminhador para verificar synchronization_state_desc e 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;
   

   Continue depois que o grupo de disponibilidade synchronization_state_desc for SYNCHRONIZED e last_hardened_lsn for igual por banco de dados no primário global e no encaminhador. Se synchronization_state_desc não for SYNCHRONIZED ou last_hardened_lsn não for igual, execute o comando a cada cinco segundos até que ele seja alterado. Não continue até que synchronization_state_desc = SYNCHRONIZED e last_hardened_lsn sejam iguais por banco de dados.

3. Na primária global, defina a função do grupo de disponibilidade distribuído como SECONDARY.

   ALTER AVAILABILITY GROUP distributedag SET (ROLE = SECONDARY); 
   

   Neste ponto, o grupo de disponibilidade distribuído não está disponível.

4. Para o SQL Server 2022 (16.x) e posterior, no primário global, defina REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

   ALTER AVAILABILITY GROUP distributedag 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
   

5. Teste a prontidão de failover. Execute a seguinte consulta no primário global e no encaminhador:

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

   O grupo de disponibilidade estará pronto para fazer failover quando last_hardened_lsn for igual para ambos os grupos de disponibilidade por banco de dados. Se last_hardened_lsn não for igual após um período de tempo, para evitar a perda de dados, faça failback para o primário global executando esse comando nele e, em seguida, comece de novo da segunda etapa:

   -- 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. Faça failover do grupo de disponibilidade primário para o grupo de disponibilidade secundário. Execute o comando a seguir no encaminhador, o SQL Server que hospeda a réplica primária do grupo de disponibilidade secundário.

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

   Após esta etapa, o grupo de disponibilidade distribuído estará disponível.

7. Para o SQL Server 2022 (16.x) e posteriores, limpe o grupo de disponibilidade distribuído REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT.

   ALTER AVAILABILITY GROUP distributedag 
     SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);
   

Depois de concluir as etapas acima, será executado failover do grupo de disponibilidade distribuído sem perda de dados. Se os grupos de disponibilidade estiverem em uma distância geográfica que causa latência, altere o modo de disponibilidade de volta para ASYNCHRONOUS_COMMIT.

Remover um grupo de disponibilidade distribuída

A seguinte instrução Transact-SQL remove um grupo de disponibilidade distribuído denominado distributedag:

DROP AVAILABILITY GROUP [distributedag]  

Criar um grupo de disponibilidade distribuído com instâncias de cluster de failover

Você pode criar um grupo de disponibilidade distribuído usando um grupo de disponibilidade em uma FCI (instância de cluster de failover). Nesse caso, não é necessário um ouvinte do grupo de disponibilidade. Use o VNN (nome de rede virtual) para a réplica primária da instância FCI. O exemplo a seguir mostra um grupo de disponibilidade distribuído chamado SQLFCIDAG. Um grupo de disponibilidade é SQLFCIAG. SQLFCIAG tem duas réplicas FCI. O VNN da réplica FCI primária é SQLFCIAG-1, e o VNN da réplica FCI secundária é SQLFCIAG-2. O grupo de disponibilidade distribuído também inclui o SQLAG-DR, para a recuperação de desastre.

A DDL a seguir cria esse grupo de disponibilidade distribuído.

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

A URL do ouvinte é o VNN da instância da FCI primária.

Fazer failover manual da FCI no grupo de disponibilidade distribuído

Para fazer failover manual do grupo de disponibilidade da FCI, atualize o grupo de disponibilidade distribuído para que ele reflita a alteração da URL do ouvinte. Por exemplo, execute a seguinte DDL no primário global do AG distribuído e o encaminhador do AG distribuído do SQLFCIDAG:

ALTER AVAILABILITY GROUP [SQLFCIDAG]  
   MODIFY AVAILABILITY GROUP ON  
 'SQLFCIAG' WITH    
    (   
        LISTENER_URL = 'tcp://SQLFCIAG-2.contoso.com:5022'
    )

Próximas etapas

CREATE AVAILABILITY GROUP (Transact-SQL)
ALTER AVAILABILITY GROUP (Transact-SQL)