Diferenças entre os modos de disponibilidade para um grupo de disponibilidade "Always On"

Aplica-se a:SQL Server

Nos grupos de disponibilidade Always On, o modo de disponibilidade é uma propriedade de réplica que determina se uma determinada réplica de disponibilidade pode ser executada no modo de confirmação síncrona. Para cada réplica de disponibilidade, o modo de disponibilidade deve ser configurado para o modo de confirmação síncrona, modo de confirmação assíncrona ou modo de configuração apenas.

Se a réplica primária estiver configurada para o modo de confirmação assíncrona, ela não aguardará que nenhuma réplica secundária grave registros de log de transações de entrada no disco (para proteger o log).

Se uma determinada réplica secundária estiver configurada para o modo de confirmação assíncrona, a réplica primária não espera que essa réplica secundária endureça o log. Se a réplica primária e uma determinada réplica secundária estiverem configuradas para o modo de confirmação síncrona, a réplica primária aguardará que a réplica secundária confirme que endureceu o log (a menos que a réplica secundária não faça ping à réplica primária dentro do período de tempo limite da sessão da réplica primária).

Modos de disponibilidade suportados

Os grupos de disponibilidade Always On suportam três modos de disponibilidade:

• Modo de confirmação assíncrona
• Modo de confirmação síncrona
• Modo apenas de configuração

O modo de confirmação assíncrona é uma solução de recuperação de desastres que funciona bem quando as réplicas de disponibilidade são distribuídas por distâncias consideráveis. Se cada réplica secundária estiver sendo executada no modo de confirmação assíncrona, a réplica primária não aguardará que nenhuma das réplicas secundárias proteja o log. Em vez disso, imediatamente após gravar o registro de log no arquivo de log local, a réplica primária envia a confirmação da transação para o cliente. A réplica primária é executada com latência mínima de transação em relação a uma réplica secundária configurada para o modo de confirmação assíncrona.

Se o primário atual estiver configurado para o modo de disponibilidade de confirmação assíncrona, ele confirmará transações de forma assíncrona para todas as réplicas secundárias, independentemente das configurações individuais do modo de disponibilidade.

Para obter mais informações, consulte Asynchronous-Commit Modo de disponibilidade, mais adiante neste artigo.

O modo de confirmação síncrona enfatiza a alta disponibilidade sobre o desempenho, ao custo do aumento da latência da transação. No modo de confirmação síncrona, as transações aguardam para enviar a confirmação da transação ao cliente até que o registo na réplica secundária esteja gravado no disco. Quando a sincronização de dados começa em um banco de dados secundário, a réplica secundária começa a aplicar registros de log de entrada do banco de dados primário correspondente. Assim que todos os registros de log forem protegidos, o banco de dados secundário entrará no SYNCHRONIZED estado. Depois disso, cada nova transação é protegida pela réplica secundária antes que o registro de log seja gravado no arquivo de log local. Quando todos os bancos de dados secundários de uma determinada réplica secundária são sincronizados, o modo de confirmação síncrona oferece suporte a failover manual e, opcionalmente, failover automático.

Para obter mais informações, consulte Synchronous-Commit Modo de disponibilidade, mais adiante neste artigo.

O modo de configuração único aplica-se a grupos de disponibilidade que não estão num Cluster de Failover do Windows Server. Uma réplica no modo somente configuração não contém dados do usuário. No modo de configuração apenas, o banco de dados de réplica master armazena metadados de configuração do grupo de disponibilidade. Para obter mais informações, consulte Alta disponibilidade e proteção de dados para configurações de grupo de disponibilidade.

A ilustração a seguir mostra um grupo de disponibilidade com cinco réplicas de alta disponibilidade. A réplica primária e uma réplica secundária são configuradas para o modo de confirmação síncrona com troca automática em caso de falha. Outra réplica secundária é configurada para o modo de confirmação síncrona com failover manual apenas planejado, e duas réplicas secundárias são configuradas para o modo de confirmação assíncrona, que suporta apenas o failover manual forçado (normalmente denominado failover forçado).

O comportamento de sincronização e failover entre duas réplicas de disponibilidade depende do modo de disponibilidade de cada uma das réplicas. Por exemplo, para que ocorra uma confirmação síncrona, tanto a réplica primária quanto a réplica secundária devem ser configuradas para confirmação síncrona. Da mesma forma, para que ocorra o failover automático, ambas as réplicas precisam estar configuradas para isso. Portanto, o comportamento para o cenário de implantação ilustrado anteriormente pode ser resumido na tabela a seguir, que explora o comportamento com cada réplica primária potencial:

Normalmente, o Nó 04 como réplica de confirmação assíncrona é implantado em um local de recuperação de desastres. O fato de os Nós 01, 02 e 03 permanecerem no modo de confirmação assíncrona após o failover para o Nó 04 ajuda a evitar a potencial degradação do desempenho em seu grupo de disponibilidade devido à alta latência de rede entre os dois sites.

Modo de disponibilidade de compromisso assíncrono

No modo de confirmação assíncrona, a réplica secundária nunca se torna sincronizada com a réplica primária. Embora um determinado banco de dados secundário possa alcançar o banco de dados primário correspondente, qualquer banco de dados secundário pode ficar para trás a qualquer momento. O modo de confirmação assíncrona pode ser útil em um cenário de recuperação de desastres no qual a réplica primária e a réplica secundária estão separadas por uma distância significativa e em que você não deseja que pequenos erros afetem a réplica principal ou em situações em que o desempenho é mais importante do que a proteção de dados sincronizada. Além disso, como a réplica primária não espera por confirmações da réplica secundária, os problemas na réplica secundária nunca afetam a réplica primária.

Uma réplica secundária de confirmação assíncrona tenta acompanhar os registros de log recebidos da réplica primária. Mas os bancos de dados secundários de confirmação assíncrona sempre permanecem não sincronizados e provavelmente ficarão um pouco atrás dos bancos de dados primários correspondentes. Normalmente, a lacuna entre um banco de dados secundário de confirmação assíncrona e o banco de dados primário correspondente é pequena. Mas a lacuna pode se tornar substancial se o servidor que hospeda a réplica secundária estiver sobrecarregado ou se a rede estiver lenta.

A única forma de failover suportada pelo modo de confirmação assíncrona é o failover forçado (com possível perda de dados). Forçar o failover é um último recurso destinado apenas a situações em que a réplica primária atual permanecerá indisponível por um longo período e a disponibilidade imediata de bancos de dados primários é mais crítica do que o risco de possível perda de dados. O destino de failover deve ser uma réplica cuja função esteja no estado SECONDARY ou RESOLVING. O destino de alternância em caso de falha passa a desempenhar a função de principal, e as suas cópias dos bancos de dados tornam-se os bancos de dados principais. Todos os bancos de dados secundários restantes, juntamente com os bancos de dados primários anteriores, assim que estiverem disponíveis, serão suspensos até que você os retome manualmente individualmente. No modo de confirmação assíncrona, todos os logs de transações que a réplica primária original ainda não havia enviado para a réplica secundária anterior são perdidos. Isso significa que alguns ou todos os novos bancos de dados primários podem não ter transações confirmadas recentemente. Para obter mais informações sobre como o failover forçado funciona e sobre as práticas recomendadas para usá-lo, consulte Modos de failover e failover (grupos de disponibilidade Always On).

Modo de disponibilidade com confirmação síncrona

No modo de disponibilidade de confirmação síncrona (modo de confirmação síncrona), depois de integrar-se a um grupo de disponibilidade, um banco de dados secundário alcança o banco de dados primário correspondente e entra no SYNCHRONIZED estado. O banco de dados secundário permanece SYNCHRONIZED enquanto a sincronização de dados estiver em curso. Isso garante que todas as transações confirmadas em um determinado banco de dados primário sejam confirmadas no banco de dados secundário correspondente. Quando cada banco de dados secundário em uma determinada réplica secundária é sincronizado, o estado de integridade da sincronização da réplica secundária como um todo é HEALTHY.

Nesta secção:

• Fatores que interrompem a sincronização de dados
• Como funciona a sincronização em uma réplica secundária
• Modo de operação com confirmação síncrona apenas e failover manual
• Modo de confirmação síncrona com failover automático

Fatores que interrompem a sincronização de dados

Depois que todos os bancos de dados estiverem sincronizados, uma réplica secundária entrará no HEALTHY estado. A réplica secundária sincronizada permanece íntegra, a menos que ocorra uma das seguintes situações:

• Um atraso ou falha de rede ou computador faz com que a sessão entre a réplica secundária e a réplica primária atinja o tempo limite.

  Observação

  Para obter informações sobre a propriedade de tempo de sessão das réplicas de disponibilidade, consulte O que é um grupo de disponibilidade Always On?

• Você suspende um banco de dados secundário na réplica secundária. A réplica secundária deixa de ser sincronizada e o seu estado de integridade de sincronização é marcado como NÃO_SAUDÁVEL. A réplica secundária não pode tornar-se saudável novamente até que o banco de dados secundário suspenso seja retomado e ressincronizado ou removido do grupo de disponibilidade.

• Você adiciona um banco de dados primário ao grupo de disponibilidade. As réplicas secundárias sincronizadas anteriormente entram no estado de integridade da NOT_HEALTHY sincronização. Esse estado indica que pelo menos um banco de dados está no NOT SYNCHRONIZING estado de sincronização. Uma determinada réplica secundária não pode ser HEALTHY novamente até que um banco de dados secundário correspondente tenha sido preparado na réplica, tenha sido associado ao grupo de disponibilidade e tenha sido sincronizado com o novo banco de dados primário.

• Altere a réplica primária ou a réplica secundária para o modo de disponibilidade com confirmação assíncrona. Depois de mudar para o modo de confirmação assíncrona, a réplica secundária permanecerá no estado de integridade da sincronização enquanto a HEALTHY sincronização de dados continuar. No entanto, se apenas a réplica primária mudar para o modo de confirmação assíncrono, a réplica secundária com confirmação síncrona entrará no estado de integridade de sincronização PARTIALLY_HEALTHY. Esse estado indica que pelo menos um banco de dados está no SYNCHRONIZING estado de sincronização, mas nenhum dos bancos de dados está no NOT SYNCHRONIZING estado.

• Você altera qualquer réplica secundária para o modo de disponibilidade de confirmação síncrona. Isso faz com que essa réplica secundária seja marcada como no estado de saúde de sincronização PARTIALLY_HEALTHY até que todas as suas bases de dados estejam no estado de sincronização SYNCHRONIZED.

Como funciona a sincronização em uma réplica secundária

No modo de confirmação síncrona, depois que uma réplica secundária ingressa no grupo de disponibilidade e estabelece uma sessão com a réplica primária:

1. A réplica secundária grava registos de log de entrada no disco (consolida o log).
2. A réplica secundária envia uma mensagem de confirmação para a réplica primária.

Depois de o log consolidado no banco de dados secundário ter alcançado o final do log no banco de dados primário, o estado do banco de dados secundário será definido como SYNCHRONIZED.

O tempo necessário para a sincronização depende de quão longe o banco de dados secundário estava atrás do banco de dados primário no início da sessão. Esse delta é medido pelo número de registros de log recebidos inicialmente da réplica primária, pela carga de trabalho no banco de dados primário e pela velocidade do host da instância da réplica secundária.

O processo de transação

No modo de confirmação síncrona, as transações são confirmadas para ambas as réplicas nesta ordem:

1. A réplica primária recebe uma transação de um cliente.

2. A réplica primária grava o registro no log de transações e, simultaneamente, envia o registro de log para as réplicas secundárias.

   Depois que um registo de log é escrito no log de transações da base de dados primária, a transação só pode ser desfeita se ocorrer um failover para um secundário que não tenha recebido o log.

3. A réplica primária aguarda a confirmação da réplica secundária, que utiliza confirmação síncrona.

4. A réplica secundária protege o log e retorna uma confirmação para a réplica primária.

5. A réplica primária conclui o processamento de confirmação e envia uma mensagem de confirmação para o cliente.

Tempo limite de confirmação síncrona

Se uma réplica secundária de confirmação síncrona ultrapassar o tempo limite sem confirmar que gravou o log, as seguintes ações acontecem no grupo de disponibilidade:

1. A réplica primária marca essa réplica secundária como falhada.
2. O estado da réplica secundária muda para DISCONNECTED.
3. O primário para de aguardar a confirmação.
4. O grupo de disponibilidade marca o estado de sincronização como NOT SYNCHRONIZING e o estado da réplica como NOT_HEALTHY.

Esse comportamento assegura que uma réplica secundária com falha durante a confirmação síncrona não impeça o fortalecimento do log na réplica primária.

Quando a réplica secundária estiver online novamente:

1. O estado da réplica secundária muda para CONNECTED.
2. A réplica secundária processa a fila de transmissão de logs da réplica primária.
3. O estado de sincronização transita para SYNCHRONIZING, e a integridade da réplica para PARTIALLY_HEALTHY.

Após a fila de envio de registos ser processada, o estado de sincronização torna-se SYNCHRONIZED, e a integridade da réplica torna-se HEALTHY.

O modo de confirmação síncrona protege seus dados exigindo que os dados sejam sincronizados entre dois locais, ao custo de aumentar um pouco a latência da transação.

Modo de confirmação síncrona com apenas failover manual

Quando essas réplicas são conectadas e o banco de dados é sincronizado, há suporte para failover manual. Se a réplica secundária ficar inativa, a réplica primária não será afetada. A réplica primária funciona de forma exposta se não existirem réplicas SYNCHRONIZED (ou seja, sem enviar dados para nenhuma réplica secundária). Se a réplica primária for perdida, as réplicas secundárias entrarão no RESOLVING estado, mas o proprietário do banco de dados poderá forçar um failover para a réplica secundária (com possível perda de dados). Para obter mais informações, consulte comutação por falha e modos de comutação por falha (Always On Availability Groups).

Modo de confirmação síncrona com failover automático

O failover automático fornece alta disponibilidade, garantindo que o banco de dados seja rapidamente disponibilizado novamente após a perda da réplica principal. Para configurar um grupo de disponibilidade para failover automático, você precisa definir a réplica primária atual e pelo menos uma réplica secundária para o modo de confirmação síncrona com failover automático. O SQL Server 2019 (15.x) aumentou o número máximo de réplicas síncronas para 5, contra 3 no SQL Server 2017 (14.x). Você pode configurar esse grupo de cinco réplicas para ter failover automático dentro do grupo. Há uma réplica primária, além de quatro réplicas secundárias síncronas.

Além disso, para que um failover automático seja possível em um determinado momento, essa réplica secundária deve ser sincronizada com a réplica primária (ou seja, os bancos de dados secundários são todos sincronizados) e o cluster WSFC (Windows Server Failover Clustering) deve ter quórum. Se a réplica primária ficar indisponível nessas condições, ocorrerá failover automático. A réplica secundária muda para a função de primária e disponibiliza a sua base de dados como base de dados primária. Para obter mais informações, consulte a seção "Failover automático" do artigo Failover e Modos de Failover (Grupos de Disponibilidade Always On).

Latência de dados na réplica secundária

Implementar acesso só de leitura às réplicas secundárias é útil quando as suas cargas de trabalho em modo de leitura conseguem tolerar alguma latência dos dados. Em situações em que a latência de dados é inaceitável, considere executar tarefas de leitura apenas na réplica principal.

A réplica primária envia registros de log de alterações no banco de dados primário para as réplicas secundárias. Em cada banco de dados secundário, um thread de refazer dedicado aplica os registros de log. Em um banco de dados secundário de acesso de leitura, uma determinada alteração de dados não aparece nos resultados da consulta até que o registro de log que contém a alteração tenha sido aplicado ao banco de dados secundário e a transação tenha sido confirmada no banco de dados primário.

Isso significa que há alguma latência, geralmente apenas uma questão de segundos, entre as réplicas primária e secundária. Em casos incomuns, no entanto, por exemplo, se problemas de rede reduzirem a taxa de transferência, a latência pode se tornar significativa. A latência aumenta quando ocorrem gargalos de E/S e quando a movimentação de dados é suspensa. Para monitorizar a movimentação de dados suspensos, pode utilizar o painel do Grupo de Disponibilidade Always On (SQL Server Management Studio) ou a vista de gestão dinâmica sys.dm_hadr_database_replica_states.

Para reduzir a latência no SQL Server 2025 (17.x) e versões posteriores, pode diminuir o tempo (em milissegundos) que a réplica primária leva a confirmar transações na réplica secundária. Para obter mais informações, consulte Configuração do servidor: tempo de confirmação do grupo de disponibilidade (ms).

Para alterar o modo de disponibilidade e o modo de failover

• Alterar o modo de disponibilidade de uma réplica dentro de um grupo de disponibilidade Always On
• Alterar o modo de failover de uma réplica dentro de um grupo de disponibilidade do Always On

Ajustar as votações do quórum

• Exibir configurações de peso do nó do quórum do cluster
• Configurar definições de Peso do Nodo do Quórum do Cluster
• Forçar um Cluster WSFC a Iniciar Sem Quórum

Para executar um failover manual

• Executar uma failover manual planeada de um grupo de disponibilidade Always On (SQL Server)
• executar um failover manual forçado de um grupo de disponibilidade Always On (SQL Server)
• Usar o Assistente para Grupo de Disponibilidade de Failover (SQL Server Management Studio)

Para exibir o grupo de disponibilidade, a réplica de disponibilidade e os estados do banco de dados

• sys.dm_hadr_availability_group_states
• sys.dm_hadr_availability_replica_states
• sys.dm_hadr_database_replica_states

Conteúdo relacionado

• Guia de soluções Always On do Microsoft SQL Server para alta disponibilidade e recuperação de desastres
• Blog Oficial da Equipa Always On do SQL Server: O Blog Oficial da Equipa Always On do SQL Server
• O que é um grupo de disponibilidade Always On?
• Modo de Failover e Modos de Failover (Grupos de Disponibilidade Always On)
• Cluster de Failover do Windows Server com o SQL Server