Diferenças entre os modos de disponibilidade de um Grupo de Disponibilidade AlwaysOn

Aplica-se:SQL Server

Nos Grupos de Disponibilidade Always On, o modo de disponibilidade é uma propriedade da réplica que determina se uma determinada réplica de disponibilidade pode operar 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, o modo de confirmação assíncrona ou o modo somente de configuração.

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 escreva registros de log de transações de entrada no disco (para proteger o log).

Se uma réplica secundária específica estiver configurada para o modo de confirmação assíncrona, a réplica primária não aguardará que a réplica secundária proteja o log. Se a réplica primária e uma determinada réplica secundária estiverem ambas configuradas para modo de confirmação síncrona, a réplica primária aguardará que a réplica secundária confirme que gravou o log em disco (a menos que a réplica secundária não responda ao ping da réplica primária dentro do período de tempo limite da sessão da réplica primária).

Observação

Se uma réplica secundária de confirmação síncrona exceder o período de tempo limite de sessão da réplica primária (o padrão é 10 segundos), a réplica primária marcará temporariamente o estado de sincronização de cada banco de dados nessa réplica secundária como NOT SYNCHRONIZING e o estado da réplica como NOT_HEALTHY. Quando a réplica secundária se reconecta com a réplica primária, elas retomam o modo de confirmação síncrona.

Modos de disponibilidade suportados

Os grupos de disponibilidade Always On dão suporte a três modos de disponibilidade:

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

Modo de confirmação assíncrona é uma solução de recuperação de desastres que funciona bem quando as réplicas de disponibilidade estão distribuídas por grandes distâncias. Se cada réplica secundária estiver em execução 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 um registro de log no arquivo de log local, a réplica primária enviará a confirmação de transação ao cliente. A réplica primária é executada com latência de transação mínima 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 realizará a confirmação de transações de forma assíncrona para todas as réplicas secundárias, independentemente das configurações individuais de modo de disponibilidade destas.

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

OModo de confirmação síncrona enfatiza a alta disponibilidade sobre o desempenho, à custa do aumento da latência da transação. No modo de confirmação síncrona, as transações aguardam para enviar a confirmação de transação para o cliente até que a réplica secundária proteja o log no disco. Quando a sincronização de dados é iniciada em um banco de dados secundário, a réplica secundária começa a aplicar os registros de log recebidos do banco de dados primário correspondente. Assim que cada registro de log for tornado permanente, o banco de dados secundário entrará no estado SYNCHRONIZED. Portanto, cada nova transação é protegida pela réplica secundária antes de o registro de log ser gravado no arquivo de log local. Quando todos os bancos de dados secundários de uma determinada réplica secundária estão sincronizados, o modo de confirmação síncrona oferece suporte ao failover manual e, opcionalmente, ao failover automático.

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

Modo somente de configuração se aplica a grupos de disponibilidade que não estão em um 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, confira 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 disponibilidade. A réplica primária e uma réplica secundária estão configuradas no modo de confirmação síncrona com failover automático. Outra réplica secundária está configurada para o modo de confirmação síncrona apenas com failover manual planejado e duas réplicas secundárias estão configuradas para o modo de confirmação assíncrona, que dá suporte somente a failover manual forçado (geralmente denominado failover forçado).

Diagrama de disponibilidade e modos de failover de réplicas.

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

Réplica primária atual Destinos de failover automático Comportamento do modo de confirmação síncrona com Comportamento do modo de confirmação assíncrona com É possível fazer failover automático
01 02 02 e 03 04 Sim
02 01 01 e 03 04 Sim
03 01 e 02 04 Não
04 01, 02 e 03 Não

Normalmente, o Nó 04, como uma réplica com confirmação assíncrona, é implantado em um site 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 uma possível degradação de desempenho em seu grupo de disponibilidade devido à alta latência de rede entre os dois sites.

Modo de disponibilidade de confirmação assíncrona

No modo de confirmação assíncrona, a réplica secundária nunca é sincronizada com a réplica primária. Embora um determinado banco de dados secundário possa ficar em dia com o banco de dados primário correspondente, qualquer banco de dados secundário pode se atrasar em qualquer ponto. O modo de commit assíncrono pode ser útil em um cenário de recuperação de desastres em que a réplica primária e a réplica secundária estão separadas por uma distância significativa e onde você não quer que pequenos erros afetem a réplica primária ou em situações onde o desempenho é mais importante do que a proteção sincronizada de dados. Além disso, como a réplica primária não espera por confirmações da réplica secundária, 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 bancos de dados secundários de confirmação assíncrona sempre permanecem não sincronizados e têm a tendência de ficarem desatualizados em relação aos bancos de dados primários correspondentes. Normalmente, é pequeno o intervalo entre um banco de dados secundário de confirmação assíncrona e o banco de dados primário correspondente. Mas o intervalo poderá ficar significativo se o servidor que hospeda a réplica secundária estiver sobrecarregado ou se a rede estiver lenta.

A única forma de failover compatível com o modo de confirmação assíncrona é o failover forçado (com possível perda de dados). Forçar o failover é o último recurso, que deve ser usado apenas em situações nas quais a réplica primária atual permanecerá indisponível por um período estendido e a disponibilidade imediata dos bancos de dados primários é mais crítica que o risco da possível perda de dados. O destino de failover deve ser uma réplica cuja função está no estado SECONDARY ou RESOLVING. O destino de failover assume a função primária, e suas cópias dos bancos de dados se tornam os bancos de dados primários. Qualquer banco de dados secundário restante, junto com os bancos de dados primários antigos, quando ficam disponíveis, é suspenso manualmente até você os retome individualmente. No modo de confirmação assíncrona, todos os logs de transação que a réplica primária original ainda não havia enviado para a réplica secundária anterior foram perdidos. Isso significa que alguns ou todos os novos bancos de dados primários podem estar sem as transações confirmadas recentemente. Para obter mais informações sobre como o failover forçado funciona e sobre as melhores práticas para utilizá-lo, consulte Failover e modos de failover (Grupos de disponibilidade Always On).

Modo de disponibilidade com confirmação síncrona

Em modo de disponibilidade de confirmação síncrona (modo de confirmação síncrona), depois de ingressar em um grupo de disponibilidade, um banco de dados secundário alcança o banco de dados primário correspondente e entra no estado SYNCHRONIZED. O banco de dados secundário permanece SYNCHRONIZED enquanto a sincronização de dados continuar. 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 seção:

Fatores que interrompem a sincronização de dados

Depois que todos os bancos de dados são sincronizados, uma réplica secundária entra no HEALTHY estado. A réplica secundária sincronizada permanece saudável, a menos que ocorra uma destas situações:

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

    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 o banco de dados secundário na réplica secundária. A réplica secundária deixa de estar sincronizada, e seu estado de integridade da sincronização é marcado como NOT_HEALTHY. A réplica secundária não poderá ficar íntegra 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. Réplicas secundárias sincronizadas anteriormente entram no NOT_HEALTHY estado de integridade de sincronização. Esse estado indica que pelo menos um banco de dados está no NOT SYNCHRONIZING estado de sincronização. Uma réplica secundária específica não poderá ser HEALTHY novamente até que um banco de dados secundário correspondente tenha sido preparado na réplica, tenha sido unido ao grupo de disponibilidade e seja sincronizado com o novo banco de dados primário.

  • Você altera a réplica primária ou a réplica secundária para o modo de disponibilidade de confirmação assíncrona. Depois de alterar para o modo de confirmação assíncrona, a réplica secundária permanecerá no HEALTHY estado de integridade da sincronização, desde que a sincronização de dados continue. No entanto, se apenas a réplica primária for alterada para o modo de confirmação assíncrona, a réplica secundária com confirmação síncrona entrará no estado de integridade da 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.

  • Altere qualquer réplica secundária para o modo de disponibilidade de confirmação síncrona. Isso faz com que a réplica secundária seja marcada no estado de integridade de sincronização PARTIALLY_HEALTHY até que todos os seus bancos de dados atinjam o estado de sincronização SYNCHRONIZED.

Dica

Para ver a integridade da sincronização de um grupo de disponibilidade, réplica de disponibilidade ou banco de dados de disponibilidade, consulte a coluna synchronization_health ou synchronization_health_desc de sys.dm_hadr_availability_group_states, sys.dm_hadr_availability_replica_states ou sys.dm_hadr_database_replica_states, respectivamente.

Como a sincronização funciona 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 registros 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 que o log consolidado no banco de dados secundário tiver 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 em 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 envia simultaneamente o registro de log para as réplicas secundárias.

    Depois que um registro de log é gravado no log de transações do banco de dados primário, a transação só poderá ser desfeita se houver um failover para um secundário que não recebeu o log.

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

  4. A réplica secundária endurece 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 ao cliente.

Tempo limite de confirmação síncrona

Se uma réplica secundária de confirmação síncrona atingir o tempo limite sem confirmar se ela protegeu o log, as seguintes ações ocorrerão no grupo de disponibilidade:

  1. A réplica primária marca a réplica secundária como defeituosa.
  2. O estado da réplica secundária muda para DISCONNECTED.
  3. O sistema 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 garante que uma réplica secundária com falha de confirmação síncrona não impeça o endurecimento 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 envio de log da réplica primária.
  3. O estado de sincronização faz a transição para SYNCHRONIZING, e o estado de saúde da réplica para PARTIALLY_HEALTHY.

Depois que a fila de envio de log é processada, o estado de sincronização se torna SYNCHRONIZEDe a integridade da réplica se torna HEALTHY.

O modo de confirmação síncrona protege seus dados exigindo a sincronização dos dados entre dois locais, às custas de algum aumento da latência da transação.

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

Quando essas réplicas forem conectadas e o banco de dados for sincronizado, haverá suporte ao failover manual. Se a réplica secundária for desativada, a réplica primária não será afetada. A réplica primária é executada em exposição se não houver SYNCHRONIZED réplicas (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, confira Failover e Modos de Failover (Grupos de Disponibilidade AlwaysOn).

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

O failover automático fornece alta disponibilidade, assegurando que o banco de dados seja rapidamente disponibilizado novamente após a perda da réplica primária. Para configurar um grupo de disponibilidade para failover automático, é necessário 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, em comparação com 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, esta réplica secundária deverá ser sincronizada com a réplica primária (quer dizer, os bancos de dados secundários são todos sincronizados) e o cluster WSFC (Windows Server Failover Clustering) deverá ter quorum. Se a réplica primária ficar indisponível nessas condições, ocorrerá um failover automático. A réplica secundária assume a função de primária e oferece seu banco de dados como o banco de dados primário. Para obter mais informações, consulte a seção "Failover Automático" do artigo Failover e Modos de Failover (Grupos de Disponibilidade AlwaysOn).

Observação

Para obter informações sobre o quórum do WSFC e os grupos de disponibilidade Always On, para obter mais informações, consulte Modos de quórum do WSFC e configuração de votação (SQL Server).

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

A implementação do acesso somente leitura a réplicas secundárias será útil se as suas cargas de trabalho somente leitura puderem tolerar certa latência de dados. Em situações em que a latência dos dados é inaceitável, considere executar cargas de trabalho somente de leitura na réplica primária.

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 restauração 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. No entanto, em casos incomuns, como quando problemas de rede reduzem 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 monitorar a movimentação de dados interrompida, você pode usar o painel do grupo de disponibilidade Always On do SQL Server Management Studio ou a exibição de gerenciamento dinâmico sys.dm_hadr_database_replica_states.

Para reduzir a latência no SQL Server 2025 (17.x) e versões posteriores, você pode reduzir o tempo (em milissegundos) que a réplica primária leva para confirmar transações para a 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

Para ajustar votos de quórum

Para executar um failover manual

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

Conteúdo relacionado

  • Last updated on