Compartilhar via

O que é um grupo de disponibilidade Always On?

Aplica-se ao:SQL Server

Este artigo apresenta os conceitos fundamentais do Grupos de disponibilidade AlwaysOn para configurar e gerenciar um ou mais grupos de disponibilidade na edição Enterprise do SQL Server. Para a edição Standard, veja Grupos de Disponibilidade AlwaysOn básicos para um banco de dados individual.

O recurso grupos de disponibilidade Always On é uma solução de alta disponibilidade e recuperação de desastre que fornece uma alternativa de nível empresarial ao espelhamento de banco de dados. Os grupos de disponibilidade AlwaysOn maximizam a disponibilidade de um conjunto de bancos de dados de usuário para uma empresa. Um grupo de disponibilidade dá suporte a um ambiente de failover para um conjunto discreto de bancos de dados de usuário, conhecidos como bancos de dados de disponibilidade, que fazem failover juntos. Um grupo de disponibilidade dá suporte a um conjunto de bancos de dados primários de leitura/gravação e a um dos oito conjuntos de bancos de dados secundários correspondentes. Opcionalmente, é possível tornar disponíveis os bancos de dados secundários para acesso somente leitura e/ou algumas operações de backup.

Com o SQL Server habilitado pelo Azure Arc, você pode exibir grupos de disponibilidade no portal do Azure.

Visão geral

Um grupo de disponibilidade dá suporte a um ambiente replicado para um conjunto discreto de bancos de dados de usuário, conhecidos como bancos de dados de disponibilidade. Crie um grupo de disponibilidade para HA (alta disponibilidade) ou escala de leitura. Um grupo de disponibilidade HA é um grupo de bancos de dados que fazem failover juntos. Um grupo de disponibilidade de escala de leitura é um grupo de bancos de dados que são copiados para outras instâncias do SQL Server para carga de trabalho somente leitura. Um grupo de disponibilidade dá suporte a um conjunto de bancos de dados primários e de um a oito conjuntos de bancos de dados secundários correspondentes. Bancos de dados secundários não são backups. Continue fazendo backup de seus bancos de dados e de seus logs de transações regularmente.

Dica

Você pode criar qualquer tipo de backup de um banco de dados primário. Como alternativa, você pode criar backups de log e backups completos somente cópia dos bancos de dados secundários. Para obter mais informações, consulte Descarregar backups com suporte para réplicas secundárias de um grupode disponibilidade.

Cada conjunto de bancos de dados de disponibilidade é hospedado por uma réplica de disponibilidade. Existem dois tipos de réplicas de disponibilidade: uma réplica primária única, que hospeda os bancos de dados primários, e de uma a oito réplicas secundárias, cada uma hospedando um conjunto de bancos de dados secundários e serve como potenciais destinos de failover para o grupo de disponibilidade. Um grupo de disponibilidade faz failover no nível de uma réplica de disponibilidade. Uma réplica de disponibilidade fornece redundância somente no nível do banco de dados para o conjunto de bancos de dados em um grupo de disponibilidade. Os failovers não são provocados por problemas de banco de dados, como um banco de dados que se torna suspeito devido à perda de um arquivo de dados ou à corrupção de um log de transações.

A réplica primária torna os bancos de dados primários disponíveis para conexões de leitura-gravação de clientes. A réplica primária envia registros de log de transações de cada banco de dados primário para todos os bancos de dados secundários. Esse processo – conhecido como sincronização de dados – ocorre no nível do banco de dados. Cada réplica secundária armazena em cache os registros do log de transações (intensifica o log) e os aplica a seu banco de dados secundário correspondente. A sincronização de dados ocorre entre o banco de dados primário e cada banco de dados secundário conectado, independentemente de outros bancos de dados. Assim, um banco de dados secundário pode ser suspenso ou falhar sem que isso afete outros bancos de dados secundários, e um banco de dados primário pode ser suspenso ou falhar sem que isso afete outros bancos de dados primários.

Opcionalmente, você pode configurar uma ou mais réplicas secundárias para dar suporte a acesso somente leitura a bancos de dados secundários, e pode configurar qualquer réplica secundária para permitir backups em bancos de dados secundários.

O SQL Server 2017 introduziu duas arquiteturas diferentes para grupos de disponibilidade. Os grupos de disponibilidade Always On fornecem alta disponibilidade, recuperação de desastre e balanceamento de escala de leitura. Esses grupos de disponibilidade exigem um gerenciador de cluster. No Windows, o recurso de clustering de failover fornece o gerenciador de cluster. No Linux, você pode usar o Pacemaker. A outra arquitetura é um grupo de disponibilidade de escala de leitura. Um grupo de disponibilidade de escala de leitura fornece réplicas para cargas de trabalho somente leitura, mas não para alta disponibilidade. Em um grupo de disponibilidade de escala de leitura, não há nenhum gerenciador de cluster, pois o failover não pode ser automático.

A implantação de grupos de disponibilidade Always On para HA no Windows requer um WSFC (Cluster de Failover do Windows Server). Cada réplica de disponibilidade de determinado grupo de disponibilidade deve residir em um nó diferente do mesmo WSFC. A única exceção é que, embora tenha sido migrado para outro cluster WSFC, um grupo de disponibilidade pode temporariamente abranger dois clusters.

Observação

Para obter informações sobre grupos de disponibilidade no Linux, consulte Grupo de disponibilidade para SQL Server em Linux.

Em uma configuração de HA, uma função de cluster é criada para cada grupo de disponibilidade criado. O cluster WSFC monitora essa função para avaliar a integridade da réplica primária. O quorum para grupos de disponibilidade Always On baseia-se em todos os nós no cluster WSFC, independentemente de um determinado nó de cluster hospedar réplicas de disponibilidade. Em contraste com o espelhamento de banco de dados, não há nenhuma função testemunha em grupos de disponibilidade Always On.

Observação

Para obter informações sobre a relação dos componentes always on do SQL Server com o cluster WSFC, consulte Clustering de Failover do Windows Server com o SQL Server.

A ilustração a seguir mostra um grupo de disponibilidade que contém uma réplica primária e quatro réplicas secundárias. Até oito réplicas secundárias têm suporte, incluindo uma réplica primária e quatro réplicas secundárias de confirmação síncrona.

Diagrama de um grupo de disponibilidade com cinco réplicas.

Configurar a criptografia TLS 1.3

O SQL Server 2025 (17.x) apresenta o suporte ao Fluxo de Dados Tabular 8.0 , que permite impor a criptografia TLS 1.3 para comunicação entre o Cluster de Failover do Windows Server e suas réplicas do grupo de disponibilidade AlwaysOn. Para começar, examine Conectar-se com criptografia estrita.

Termos e definições

Termo Descrição
grupo de disponibilidade Um contêiner para um conjunto de bancos de dados, bancos de dados de disponibilidade, que executam failover juntos.
banco de dados de disponibilidade Um banco de dados que pertence a um grupo de disponibilidade. Para cada banco de dados de disponibilidade, o grupo de disponibilidade mantém uma única cópia de leitura/gravação (o banco de dados primário) e de uma a oito cópias somente leitura (bancos de dados secundários).
banco de dados primário. A cópia de leitura-gravação de um banco de dados de disponibilidade.
banco de dados secundário Uma cópia somente leitura de um banco de dados de disponibilidade.
réplica de disponibilidade Uma instanciação de um grupo de disponibilidade que uma instância específica do SQL Server hospeda e mantém uma cópia local de cada banco de dados de disponibilidade que pertence ao grupo de disponibilidade. Existem dois tipos de réplica de disponibilidade: uma única réplica primária e uma a oito réplicas secundárias.
réplica primária A réplica de disponibilidade que torna disponíveis os bancos de dados primários para conexões de leitura/gravação de clientes e, também, envia registros do log de transações para cada banco de dados primário a toda réplica secundária.
réplica secundária Uma réplica de disponibilidade que mantém uma cópia secundária de cada banco de dados de disponibilidade e serve como destinos potenciais de failover para o grupo de disponibilidade. Opcionalmente, uma réplica secundária pode incluir o suporte ao acesso somente leitura para que bancos de dados secundários possam oferecer suporte à criação de backups em bancos de dados secundários.
ouvinte do grupo de disponibilidade Um nome do servidor ao qual os clientes podem se conectar para acessar um banco de dados em uma réplica primária ou secundária de um grupo de disponibilidade. Os ouvintes de grupo de disponibilidade direcionam conexões de entrada para a réplica primária ou para uma réplica secundária somente leitura.

Bancos de dados de disponibilidade

Para adicionar um banco de dados a um grupo de disponibilidade, o banco de dados deve estar online, banco de dados de leitura/gravação que existe na instância do servidor que hospeda a réplica primária. Quando você adiciona um banco de dados, ele se une ao grupo de disponibilidade como um banco de dados primário, permanecendo disponível a clientes. Nenhum banco de dados secundário correspondente existe até que você restaure os backups do novo banco de dados primário para a instância do servidor que hospeda a réplica secundária (usando RESTORE WITH NORECOVERY). O novo banco de dados secundário estará no estado RESTORING até que seja unido ao grupo de disponibilidade. Para obter mais informações, confira Iniciar movimentação de dados em um banco de dados secundário Always On (SQL Server).

A junção coloca o banco de dados secundário no estado ONLINE e inicia sincronização de dados com o banco de dados primário correspondente. Sincronização de dados é o processo pelo qual as alterações em um banco de dados primário são reproduzidas em um banco de dados secundário. A sincronização de dados envolve o envio pelo banco de dados primário dos registros do log de transações ao banco de dados secundário.

Importante

Um banco de dados de disponibilidade muitas vezes é chamado de réplica de banco de dados no Transact-SQL, no PowerShell e em nomes do SMO (SQL Server Management Objects). Por exemplo, o termo "réplica de banco de dados" é usado nos nomes das exibições de gerenciamento dinâmico AlwaysOn que retornam informações sobre bancos de dados de disponibilidade: sys.dm_hadr_database_replica_states e sys.dm_hadr_database_replica_cluster_states. Porém, nos Manuais Online do SQL Server, o termo "réplica" normalmente refere-se a réplicas de disponibilidade. Por exemplo, "réplica primária" e "réplica secundária" sempre referem-se a réplicas de disponibilidade.

Réplicas de disponibilidade

Cada grupo de disponibilidade define um conjunto de dois ou mais parceiros de failover conhecidos como réplicas de disponibilidade. As réplicas de disponibilidade são componentes do grupo de disponibilidade. Cada réplica de disponibilidade hospeda uma cópia dos bancos de dados de disponibilidade no grupo de disponibilidade. Para um determinado grupo de disponibilidade, instâncias separadas do SQL Server que residem em nós diferentes de um cluster WSFC devem hospedar as réplicas de disponibilidade. Cada uma dessas instâncias de servidor deve estar habilitada para AlwaysOn.

SQL Server 2019 (15.x) aumenta o número máximo de réplicas síncronas para 5, um aumento com relação às 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.

Uma determinada instância pode hospedar apenas uma réplica de disponibilidade por grupo de disponibilidade. No entanto, você pode usar cada instância para muitos grupos de disponibilidade. Uma determinada instância pode ser uma instância autônoma ou uma FCI (instância de cluster de failover) do SQL Server . Se você precisar de redundância em nível de servidor, use instâncias de cluster de failover.

Cada réplica de disponibilidade recebe uma função inicial - a função primária ou a função secundária, que os bancos de dados de disponibilidade dessa réplica herdam. A função de uma determinada réplica determina se ela hospeda bancos de dados de leitura/gravação ou bancos de dados somente leitura. Uma réplica, conhecida como a réplica primária, recebe a função primária e hospeda bancos de dados de leitura/gravação, que são conhecidos como bancos de dados primários. Pelo menos uma outra réplica, conhecida como uma réplica secundária, recebe a função secundária. Uma réplica secundária hospeda bancos de dados somente leitura, conhecidos como bancos de dados secundários.

Observação

Quando a função de uma réplica de disponibilidade está indeterminada, como durante um failover, seus bancos de dados estão temporariamente em um estado NOT SYNCHRONIZING. Sua função é definida como RESOLVENDO até que a função da réplica de disponibilidade seja resolvida. Se uma réplica de disponibilidade for resolvida para a função primária, seus bancos de dados se tornarão os bancos de dados primários. Se uma réplica de disponibilidade for resolvida para a função secundária, seus bancos de dados se tornarão os bancos de dados secundários.

Modos de disponibilidade

Cada réplica de disponibilidade tem uma propriedade de modo de disponibilidade. O modo de disponibilidade determina se a réplica primária aguarda pela confirmação de transações em um banco de dados até que uma determinada réplica secundária grave os registros de log de transações no disco (consolida o log). O Grupos de disponibilidade AlwaysOn permite dois modos de disponibilidade: o modo de confirmação assíncrona e o modo de confirmação síncrona.

  • Modo de confirmação assíncrona

    Uma réplica de disponibilidade que usa esse modo de disponibilidade é conhecida como réplica da confirmação assíncrona. No modo de confirmação assíncrona, a réplica primária confirma as transações sem esperar a confirmação de que as réplicas secundárias de confirmação assíncrona protegeram o log de transações. O modo de confirmação assíncrona minimiza a latência de transações nos bancos de dados secundários, mas permite que elas atrasem os bancos de dados primários, possibilitando a perda de dados.

  • Modo de confirmação síncrona

    Uma réplica de disponibilidade que usa esse modo de disponibilidade é conhecida como uma réplica de confirmação síncrona. No modo de confirmação síncrona, antes de confirmar transações, uma réplica primária de confirmação síncrona aguarda uma réplica secundária de confirmação síncrona para reconhecer que terminou de proteger o log. O modo de confirmação síncrona garante que, quando um determinado banco de dados secundário é sincronizado com o banco de dados primário, as transações confirmadas sejam totalmente protegidas. Essa proteção ocorre às custas de latência de transação aumentada. O SQL Server 2017 introduziu a opção de um recurso de secundários sincronizados necessários para aumentar ainda mais a segurança mediante o aumento da latência. O recurso REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT pode ser habilitado para exigir que um determinado número de réplicas síncronas confirmem uma transação antes que uma réplica primária tenha permissão para confirmar.

Para obter mais informações, consulte Diferenças entre os modos de disponibilidade de um grupo de disponibilidade AlwaysOn.

Tipos de failover

No contexto de uma sessão entre a réplica primária e uma réplica secundária, as funções primária e secundária podem alternar em um processo conhecido como failover. Durante um failover, a réplica secundária de destino faz a transição para a função primária e se torna a nova réplica primária. A nova réplica primária coloca seus bancos de dados online como os bancos de dados primários, e os aplicativos cliente podem conectar-se a eles. Quando a réplica primária anterior está disponível, ela muda para a função secundária e se torna uma réplica secundária. Os bancos de dados primários anteriores se tornam bancos de dados secundários e a sincronização de dados é retomada.

Um grupo de disponibilidade faz failover no nível de uma réplica de disponibilidade. Os failovers não ocorrem devido a problemas de banco de dados, como um banco de dados se tornando suspeito devido à perda de um arquivo de dados, exclusão de um banco de dados ou corrupção de um log de transações.

Existem três formas de failover: automática, manual e forçada (com possível perda de dados). A forma ou formas de failover que uma réplica secundária suporta dependem do seu modo de disponibilidade. Para o modo de confirmação síncrona, depende também do modo de failover na réplica primária e na réplica secundária de destino, como segue.

  • O modo de confirmação síncrona dá suporte a duas formas de failover: failover manual planejado e failover automático, se a réplica secundária de destino estiver sincronizada com a réplica primária no momento. A configuração da propriedade do modo de failover nos parceiros de failover determina o suporte para essas formas de failover. Se você definir o modo de failover como manual na réplica primária ou secundária, a réplica secundária oferecerá suporte apenas ao failover manual. Se você definir o modo de failover como automático nas réplicas primária e secundária, a réplica secundária oferecerá suporte ao failover automático e manual.

    • Failover manual planejado (sem perda de dados)

    Um failover manual acontece depois que um administrador de banco de dados emite um comando de failover. Isso faz com que uma réplica secundária sincronizada faça a transição para a função primária (com proteção de dados garantida) e a réplica primária seja alterada para a função secundária. Um failover manual requer que a réplica primária e a réplica secundária de destino sejam executadas no modo de confirmação síncrona, e que a réplica secundária já esteja sincronizada.

    • Failover automático (sem perda de dados)

    Um failover automático ocorre em resposta a uma falha. Isso faz com que uma réplica secundária sincronizada faça a transição para a função primária (com proteção de dados garantida). Quando a réplica primária anterior fica disponível, ela assume o papel de secundária. O failover automático requer que tanto a réplica primária quanto a réplica secundária de destino operem em modo de confirmação síncrona com o modo de failover configurado como Automático. Além disso, a réplica secundária já deve estar sincronizada, ter quorum de WSFC e atender às condições especificadas pela política de failover flexível do grupo de disponibilidade.

  • No modo de confirmação assíncrona, a única forma de failover é o failover manual forçado (com possível perda de dados), geralmente conhecido como failover forçado. O failover forçado é uma forma de failover manual porque você deve iniciá-lo manualmente. O failover forçado é uma opção de recuperação de desastres. É a única forma de failover possível quando a réplica secundária de destino não é sincronizada com a réplica primária.

Para obter mais informações, confira Failover e Modos de Failover (Grupos de Disponibilidade Always On).

Importante

  • As FCIs (Instâncias de Cluster de Failover) do SQL Server não dão suporte ao failover automático por grupos de disponibilidade, portanto, você só pode configurar o failover manual para qualquer réplica de disponibilidade hospedada por uma FCI.
  • Se você emitir um comando de failover forçado em uma réplica secundária sincronizada, a réplica secundária se comportará da mesma maneira que um failover manual planejado.

Benefícios

Grupos de disponibilidade AlwaysOn fornecem um conjunto diversificado de opções que melhoram a disponibilidade do banco de dados e o uso de recursos. Os principais componentes são os seguintes:

Conexões de cliente

Você pode fornecer conectividade de cliente à réplica primária de um determinado grupo de disponibilidade criando um ouvinte de grupo de disponibilidade. Um ouvinte de grupo de disponibilidade fornece um conjunto de recursos que é conectado a um determinado grupo de disponibilidade para direcionar conexões de cliente à réplica de disponibilidade apropriada.

Um ouvinte de grupo de disponibilidade é associado a um nome DNS exclusivo, que serve como um VNN (nome de rede virtual), um ou mais VIPs (endereços IP virtuais) e um número de porta TCP. Para obter mais informações, consulte Conectar-se a um ouvinte de grupo de disponibilidade Always On.

Se um grupo de disponibilidade tiver apenas duas réplicas de disponibilidade e não estiver configurado para permitir o acesso de leitura à réplica secundária, os clientes poderão se conectar à réplica primária usando uma cadeia de conexão de espelhamento de banco de dados. Essa abordagem pode ser útil temporariamente depois que você migra um banco de dados do espelhamento de banco de dados para grupos de disponibilidade Always On. Antes de adicionar réplicas secundárias, você precisa criar um ouvinte para o grupo de disponibilidade e atualizar suas aplicações para usar o nome de rede desse ouvinte.

Observação

O SQL Server 2025 (17.x) apresenta o suporte ao TDS 8.0, que permite a imposição de criptografia TLS 1.3 rigorosa para conexões com suas réplicas e ouvintes do grupo de disponibilidade Always On.

Requisitos de configuração:

  • Novos grupos de disponibilidade: Crie o Grupo de Disponibilidade (AG) com Encrypt=Strict na cláusula CLUSTER_CONNECTION_OPTIONS e faça failover para aplicar as configurações.
  • Grupos de disponibilidade existentes: altere o AG usando a cláusula CLUSTER_CONNECTION_OPTIONS para definir Encrypt=Strict e realizar um failover para aplicar as configurações.
  • Forçar criptografia estrita: defina essa opção como Sim no SQL Server Configuration Manager para cada réplica e reinicie as réplicas do SQL Server.
  • Requisitos de certificado: quando Encrypt=Strict for definido, TrustServerCertificate serão ignorados.

Para começar, examine Conectar-se com criptografia estrita.

Réplicas secundárias ativas

Os grupos de disponibilidade Always On dão suporte a réplicas secundárias ativas. Os recursos secundários ativos incluem suporte para:

  • Executar operações de backup em réplicas secundárias

    As réplicas secundárias dão suporte à execução de backups de log e somente cópia de um banco de dados completo, arquivo ou grupo de arquivos. Você pode configurar o grupo de disponibilidade para especificar a preferência de onde os backups devem ser executados. É importante entender que o SQL Server não impõe a preferência, portanto, ele não tem efeito sobre backups ad hoc. A interpretação dessa preferência depende da lógica, se houver, que você usa para o script de seus trabalhos de backup para cada um dos bancos de dados em um determinado grupo de disponibilidade. Para uma réplica de disponibilidade individual, você pode especificar suas prioridades para executar backups nesta réplica em relação às outras réplicas no mesmo grupo de disponibilidade. Para obter mais informações, consulte Descarregar backups com suporte para réplicas secundárias de um grupode disponibilidade.

  • O acesso somente leitura a uma ou mais réplicas secundárias (réplicas secundárias para leitura)

    Você pode configurar qualquer réplica de disponibilidade secundária para permitir apenas acesso de leitura para seus bancos de dados locais, embora algumas operações não tenham suporte total. Essa configuração impede tentativas de conexão de leitura/gravação para a réplica secundária. Também é possível impedir cargas de trabalho somente leitura na réplica primária permitindo apenas o acesso de leitura e gravação. Essa configuração impede que conexões só de leitura sejam feitas à réplica primária. Para obter mais informações, consulte Descarregar carga de trabalho somente leitura para a réplica secundária de um grupo de disponibilidade Always On.

    Se um grupo de disponibilidade atualmente tiver um listener de grupo de disponibilidade e uma ou mais réplicas secundárias legíveis, o SQL Server poderá direcionar solicitações de conexão com intenção de leitura para uma das réplicas legíveis (roteamento somente leitura). Para obter mais informações, consulte Conectar-se a um ouvinte de grupo de disponibilidade Always On.

Período de tempo limite da sessão

O período de tempo limite da sessão é uma propriedade de réplica de disponibilidade que determina por quanto tempo uma conexão com outra réplica de disponibilidade pode permanecer inativa antes do fechamento da conexão. As réplicas primárias e secundárias executam ping uma da outra para sinalizar que ainda estão ativas. A recepção de um ping de outra réplica durante o período de tempo limite indica que a conexão ainda está aberta e que as instâncias do servidor estão se comunicando. Durante o recebimento de um ping, uma réplica de disponibilidade redefine seu contador de tempo limite de sessão nessa conexão.

O período de tempo limite da sessão impede qualquer réplica de esperar indefinidamente para receber um ping de outra réplica. Se nenhum ping for recebido da outra réplica dentro do período de tempo limite da sessão, a réplica ultrapassa o tempo limite: sua conexão é fechada e a réplica entra no estado desconectado. Mesmo que uma réplica desconectada esteja configurada para o modo de confirmação síncrona, as transações não esperam que ela se reconecte e seja ressincronizada.

O período de tempo limite da sessão padrão para cada réplica de disponibilidade é 10 segundos. Você pode configurar esse valor, com um mínimo de 5 segundos. Em geral, mantenha o período de tempo limite em 10 segundos ou mais. Definir o valor como menos de 10 segundos cria a possibilidade de um sistema extremamente carregado declarando uma falsa falha.

Observação

Na função de resolução, o período de tempo limite da sessão não se aplica porque o ping não ocorre.

Reparo automático de página

Cada réplica de disponibilidade tenta recuperar-se automaticamente de páginas corrompidas em um banco de dados local resolvendo determinados tipos de erros que impedem a leitura de uma página de dados. Se uma réplica secundária não puder ler uma página, a réplica solicitará uma cópia atualizada da página da réplica primária. Se a réplica primária não puder ler uma página, a réplica transmitirá uma solicitação de uma cópia atualizada para todas as réplicas secundárias e obterá a página da primeira a responder. Se essa solicitação tiver êxito, a página ilegível será substituída pela cópia. Isso normalmente resolve o erro.

Para obter mais informações, confira Reparo automático de página (Grupos de disponibilidade: espelhamento de banco de dados).

Interoperabilidade e coexistência com outros recursos de mecanismo de banco de dados

Os grupos de disponibilidade Always On funcionam com os seguintes recursos ou componentes do SQL Server:

Próxima etapa

Introdução aos grupos de disponibilidade Always On

  • Last updated on