Configurar um grupo de disponibilidade Always On distribuído

Aplica-se: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

Para configurar um grupo de disponibilidade distribuída, você deve ter o seguinte:

• Uma versão com suporte do SQL Server.

Observação

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ída), não há suporte para configurar 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 estiver definido como uma rede específica no ponto de extremidade, o grupo de disponibilidade distribuído 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 DATABASE_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. Nesse caso, o banco de dados não é especificado, pois é 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 para a 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 de um grupo de disponibilidade distribuído

Como o SQL Server 2022 (16.x) introduziu o suporte ao grupo de disponibilidade distribuído para a configuração REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT, as instruções para fazer failover de uma disponibilidade distribuída são diferentes para o SQL Server 2022 e versões posteriores do que para o SQL Server 2019 e versões anteriores.

Para um grupo de disponibilidade distribuído, o único tipo de failover com suporte é um FORCE_FAILOVER_ALLOW_DATA_LOSS. Portanto, para evitar a perda de dados, você deve executar etapas extras (descritas em detalhes nesta seção) para garantir que os dados sejam sincronizados entre as duas réplicas antes de iniciar o failover.

No caso de uma emergência em que a perda de dados é aceitável, você pode iniciar um failover sem garantir a sincronização de dados executando:

ALTER AVAILABILITY GROUP distributedAG FORCE_FAILOVER_ALLOW_DATA_LOSS;

Você pode usar o mesmo comando para fazer failover para o encaminhador, bem como failback para o primário global.

SQL Server 2022 e posterior

No SQL Server 2022 (16.x) e posterior, você pode definir a configuração REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT de um grupo de disponibilidade distribuído, que foi projetado para garantir que não haja perda de dados quando um grupo de disponibilidade distribuído falhar. Se essa configuração estiver definida, siga as etapas nesta seção para fazer failover do grupo de disponibilidade distribuído. Se você não quiser usar a configuração REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT, siga as instruções para fazer failover de um grupo de disponibilidade distribuído no SQL Server 2019 e versões anteriores.

Observação

Definir REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT como 1 significa que a réplica primária aguarda que as transações sejam confirmadas na réplica secundária antes de serem confirmadas na réplica primária, o que pode prejudicar o desempenho. Embora a limitação ou interrupção de transações no primário global não seja necessária para que o grupo de disponibilidade distribuída seja sincronizado no SQL Server 2022 (16.x), isso pode melhorar o desempenho para transações de usuário e sincronização de grupo de disponibilidade distribuída com REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT definido como 1.

Etapas para garantir que não haja perda de dados

Para garantir que não haja perda de dados, primeiro você deve configurar o grupo de disponibilidade distribuída para não dar suporte a nenhuma perda de dados seguindo estas etapas:

1. Para se preparar para a transferência automática (failover), verifique se o primário global e o reencaminhador global estão no modo SYNCHRONOUS_COMMIT. Caso contrário, defina-os para SYNCHRONOUS_COMMIT até ALTER AVAILABILITY GROUP.
2. Defina o grupo de disponibilidade distribuído como confirmação síncrona em ambos, primário global e encaminhador.
3. Aguarde até que o grupo de disponibilidade distribuído seja sincronizado.
4. No primário global, ajuste a configuração do grupo de disponibilidade distribuído REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT para 1 usando ALTER AVAILABILITY GROUP.
5. Verifique se todas as réplicas nos AGs locais e nos grupos de disponibilidade distribuída estão íntegras e se o grupo de disponibilidade distribuída está SYNCHRONIZED.
6. Na réplica primária global, defina a função do grupo de disponibilidade distribuído como SECONDARY, o que torna o grupo de disponibilidade distribuído indisponível.
7. No encaminhador (o novo primário pretendido), faça failover do grupo de disponibilidade distribuído usando ALTER AVAILABILITY GROUP com FORCE_FAILOVER_ALLOW_DATA_LOSS.
8. No novo secundário (a réplica primária global anterior), defina o grupo de disponibilidade distribuído REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT como 0.
9. Opcional: se os grupos de disponibilidade estiverem em uma distância geográfica que cause latência, altere o modo de disponibilidade para ASYNCHRONOUS_COMMIT. Isso reverte a alteração da primeira etapa, se necessário.

Exemplo de T-SQL

Esta seção fornece as etapas em um exemplo detalhado para fazer failover do grupo de disponibilidade distribuído chamado distributedAG usando o Transact-SQL. O ambiente de exemplo tem um total de 4 nós para o grupo de disponibilidade distribuído. O grupo de disponibilidade de host primário global N1 e N2ag1, enquanto o grupo de disponibilidade de host do encaminhador global N3 e N4ag2. O grupo de disponibilidade distribuído distributedAG transfere alterações de ag1 para ag2.

1. Consulta para verificar SYNCHRONOUS_COMMIT nas réplicas primárias dos grupos de disponibilidade locais que formam o grupo de disponibilidade distribuído. Execute o seguinte T-SQL diretamente nos encaminhadores globais e nos primários globais:

   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. Defina o grupo de disponibilidade distribuído como confirmação síncrona executando o seguinte código em ambos, primário global e 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);
   

   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ê deve executar esse script na réplica primária global e no encaminhador.

3. Aguarde até que o status do grupo de disponibilidade distribuído seja alterado para SYNCHRONIZED. Execute a seguinte consulta no primário global:

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

   Continuar depois que o grupo de disponibilidade synchronization_state_desc for SYNCHRONIZED.

4. Para o SQL Server 2022 (16.x) e posterior, no primário global, defina REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT como 1 usando o seguinte T-SQL:

   ALTER AVAILABILITY GROUP distributedAG SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 1);
   

5. Verifique se os grupos de disponibilidade estão íntegros em todas as réplicas, consultando o primário global e o encaminhador:

   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. Na primária global, defina a função do grupo de disponibilidade distribuído como SECONDARY. Neste ponto, o grupo de disponibilidade distribuído não está disponível. Após a conclusão desta etapa, você não poderá retornar até que o restante das etapas seja executado.

   ALTER AVAILABILITY GROUP distributedAG SET (ROLE = SECONDARY);
   

7. Faça failover do primário global executando a seguinte consulta no encaminhador para fazer a transição dos grupos de disponibilidade e colocar o grupo de disponibilidade distribuído novamente online:

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

   • As transições primárias globais de N1 para N3.
   • O encaminhador global faz a transição de N3 para N1.
   • O grupo de disponibilidade distribuído está disponível.

8. No novo encaminhador (primário global anterior, N1), desmarque a propriedade do grupo de disponibilidade distribuída REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT definindo-a como 0:

   ALTER AVAILABILITY GROUP distributedAG SET (REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT = 0);
   

9. OPCIONAL: se os grupos de disponibilidade estiverem em uma distância geográfica que cause latência, considere alterar o modo de disponibilidade de volta para ASYNCHRONOUS_COMMIT em ambos, primário global e o encaminhador. Isso reverte a alteração feita na primeira etapa, se necessário.

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

As instruções nesta seção se aplicam se REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT não estiver definido para o grupo de disponibilidade distribuído, como versões anteriores ao SQL Server 2022 (16.x), pois elas não dão suporte a ele para grupos de disponibilidade distribuídos.

Etapas para garantir que não haja perda de dados

Para garantir que não haja perda de dados, siga estas etapas:

1. Interrompa todas as transações em execução nos bancos de dados do grupo de disponibilidade primário global.
2. Verifique se o primário global e o encaminhador global estão no modo SYNCHRONOUS_COMMIT. Caso contrário, defina-os para SYNCHRONOUS_COMMIT até ALTER AVAILABILITY GROUP.
3. Defina o grupo de disponibilidade distribuído como confirmação síncrona no primário global e no encaminhador.
4. Aguarde até que o grupo de disponibilidade distribuído seja sincronizado e tenha o mesmo last_hardened_lsn por banco de dados. Aguarde até que o last_hardened_lsn para cada banco de dados corresponda entre as réplicas.
5. Na réplica primária global, defina a função do grupo de disponibilidade distribuído como SECONDARY, o que torna o grupo de disponibilidade distribuído indisponível.
6. Teste a preparação para failover verificando se os valores de last_hardened_lsn são os mesmos no primário e no encaminhador global. Se eles não corresponderem, faça failback para a primária global e inicie o processo novamente desde a primeira etapa.
7. Faça failover do grupo de disponibilidade primário usando ALTER AVAILABILITY GROUP com FORCE_FAILOVER_ALLOW_DATA_LOSS.
8. Opcional: se os grupos de disponibilidade estiverem em uma distância geográfica que cause latência, altere o modo de disponibilidade de volta para ASYNCHRONOUS_COMMIT.

Exemplo de T-SQL

Esta seção fornece as etapas em um exemplo detalhado para fazer failover do grupo de disponibilidade distribuído chamado distributedAG usando o Transact-SQL. O ambiente de exemplo tem um total de 4 nós para o grupo de disponibilidade distribuído. O grupo de disponibilidade de host primário global N1 e N2ag1, enquanto o grupo de disponibilidade de host do encaminhador global N3 e N4ag2. O grupo de disponibilidade distribuído distributedAG transfere alterações de ag1 para ag2.

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

2. Consulta para verificar SYNCHRONOUS_COMMIT nos primários dos grupos de disponibilidade locais que integram o grupo de disponibilidade distribuído. Execute diretamente no encaminhador global e no primário global:

   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. Defina o grupo de disponibilidade distribuído como confirmação síncrona executando o seguinte código em ambos, primário global e 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);
   
    -- 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;
   

   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ê deve executar esse script em ambos, réplica primária global e encaminhador.

4. Aguarde até que o status do grupo de disponibilidade distribuído mude para SYNCHRONIZED e que todas as réplicas apresentem o mesmo valor 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, e no encaminhador, para verificar o 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 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');
   

   Prossiga depois que o grupo de disponibilidade synchronization_state_desc estiver SYNCHRONIZED, e o last_hardened_lsn for o mesmo para cada banco de dados em ambos, primário global e encaminhador. Se synchronization_state_desc não for SYNCHRONIZED ou last_hardened_lsn não for o mesmo, execute o comando a cada cinco segundos até que ele seja alterado. Para evitar a perda de dados, não prossiga até que o synchronization_state_desc = SYNCHRONIZED e last_hardened_lsn seja o mesmo por banco de dados.

5. No primário global, defina a função de grupo de disponibilidade distribuída como SECONDARY:

   ALTER AVAILABILITY GROUP distributedAG SET (ROLE = SECONDARY);
   

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

6. Teste a prontidão de failover. Execute a consulta SELECT novamente para verificar o last_hardened_lsn (por banco de dados) tanto no servidor global primário quanto no servidor de encaminhamento. Verifique se os valores de last_hardened_lsn correspondem para todos os bancos de dados entre o primário global e o encaminhador.

7. Dependendo do resultado da etapa anterior, sua próxima etapa variará.

   • Se o last_hardened_lsns corresponder da consulta SELECT, faça failover do grupo de disponibilidade primário para o grupo de disponibilidade secundário. Execute o comando ALTER AVAILABILITY GROUP no encaminhador, o SQL Server que hospeda a réplica primária do grupo de disponibilidade secundário.

   • Se o last_hardened_lsnsnão corresponder à consulta SELECT após algum tempo, faça o failover do AG distribuído de volta para o encaminhador global original (N1) executando o comando de failover no primário global. Em seguida, inicie o processo novamente a partir da primeira etapa.

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

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

8. OPCIONAL: após um failover bem-sucedido, se os grupos de disponibilidade estiverem em uma distância geográfica que tenha latência, considere alterar o modo de disponibilidade de volta para ASYNCHRONOUS_COMMIT para reverter a alteração feita anteriormente.

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

Depois de concluir essas etapas, será executado failover do grupo de disponibilidade distribuído sem perda de dados.

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.

O seguinte DDL configura este 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'
    )

Conteúdo relacionado

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