Partilhar via

O que é um grupo de disponibilidade "Always On"?

  • Artigo

Aplica-se a:SQL Server

Este artigo apresenta os conceitos de grupos de disponibilidade Always On que são centrais para configurar e gerenciar um ou mais grupos de disponibilidade na edição Enterprise do SQL Server. Para a edição Standard, revise grupos de disponibilidade Always On Basic para um único banco de dados.

O recurso de grupos de disponibilidade Always On é uma solução de alta disponibilidade e recuperação de desastres que fornece uma alternativa de nível empresarial ao espelhamento de banco de dados. Os grupos de disponibilidade Always On maximizam a disponibilidade de um conjunto de bancos de dados de usuários para uma empresa. Um grupo de disponibilidade oferece 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 suporta um conjunto de bancos de dados primários de leitura-gravação e um a oito conjuntos de bancos de dados secundários correspondentes. Opcionalmente, os bancos de dados secundários podem ser disponibilizados para acesso somente leitura e/ou algumas operações de backup.

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

Visão geral

Um grupo de disponibilidade oferece suporte a um ambiente replicado para um conjunto discreto de bancos de dados de usuários, conhecido como bancos de dados de disponibilidade . Você pode criar um grupo de disponibilidade para alta disponibilidade (HA) ou para escala de leitura. Um grupo de disponibilidade de HA é um grupo de bancos de dados que fazem failover juntos. Um grupo de disponibilidade em escala de leitura é um grupo de bancos de dados que são copiados para outras instâncias do SQL Server para carga de trabalho de leitura apenas. Um grupo de disponibilidade suporta um conjunto de bancos de dados primários e um a oito conjuntos de bancos de dados secundários correspondentes. As bases de dados secundárias não são backups. Continue a fazer backup de seus bancos de dados e seus logs de transações regularmente.

Dica

Você pode criar qualquer tipo de backup de um banco de dados primário. Como alternativa, poderá criar backups de log e backups completos apenas de cópia de bases de dados secundárias. Para obter mais informações, consulte Transferir backups suportados para réplicas secundárias de um grupo de disponibilidade.

Cada conjunto de bases de dados de disponibilidade é hospedado por uma réplica de disponibilidade . Existem dois tipos de réplicas de disponibilidade: uma única réplica primária , que hospeda os bancos de dados primários, e uma a oito réplicas secundárias , cada uma das quais hospeda um conjunto de bancos de dados secundários e serve como potenciais destinos de failover para o grupo de disponibilidade. Um grupo de disponibilidade realiza 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 causados por problemas de banco de dados, como um banco de dados se tornando suspeito devido a uma perda de um arquivo de dados ou corrupção de um log de transações.

A réplica primária disponibiliza para os clientes os bancos de dados primários para conexões de leitura-gravação. A réplica primária envia registros de log de transações de cada banco de dados primário para cada banco de dados secundário. 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 (protege log) e, em seguida, aplica-os ao 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 dos outros bancos de dados. Portanto, um banco de dados secundário pode ser suspenso ou falhar sem afetar outros bancos de dados secundários, e um banco de dados primário pode ser suspenso ou falhar sem afetar outros bancos de dados primários.

Opcionalmente, você pode configurar uma ou mais réplicas secundárias para oferecer suporte ao 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. grupos de disponibilidade Always On oferecem alta disponibilidade, recuperação de desastres e balanceamento em 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 em escala de leitura . Um grupo de disponibilidade de escala de leitura fornece réplicas para trabalhos somente leitura, mas não para alta disponibilidade. Em um grupo de disponibilidade em escala de leitura, não há 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 um grupo de disponibilidade específico deve residir num nó diferente do mesmo WSFC. A única exceção é que, ao ser migrado para outro cluster WSFC, um grupo de disponibilidade pode abranger temporariamente dois clusters.

Observação

Para obter informações sobre grupos de disponibilidade no Linux, consulte Grupos de disponibilidade do SQL Server no 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 é baseado em todos os nós do cluster WSFC, independentemente de um determinado nó do cluster alojar réplicas de disponibilidade. Ao contrário do espelhamento de banco de dados, não há nenhum papel de testemunha nos 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 Cluster 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. Há suporte para até oito réplicas secundárias, sendo uma delas a réplica primária e quatro delas réplicas secundárias de confirmação síncrona.

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

Termos e definições

Vigência Descrição
grupo de disponibilidade Um contêiner para um conjunto de bancos de dados, bancos de dados de disponibilidade, que fazem 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 (banco de dados primário) e de uma a oito cópias somente leitura (bancos de dados secundários).
base de dados primária A cópia de leitura-gravação de um banco de dados de disponibilidade.
banco de dados secundário Uma cópia só de leitura de um banco de dados de alta disponibilidade.
réplica de disponibilidade Uma instanciação de um grupo de disponibilidade hospedado por uma instância específica do SQL Server e que mantém uma cópia local de cada banco de dados de disponibilidade que pertence ao grupo de disponibilidade. Existem dois tipos de réplicas 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 disponibiliza os bancos de dados primários para conexões de leitura-gravação de clientes e, também, envia entradas de log de transações de cada banco de dados primário para cada réplica secundária.
réplica secundária Uma réplica de disponibilidade que mantém uma cópia secundária de cada base de dados de disponibilidade e serve como um possível destino de failover para o grupo de disponibilidade. Opcionalmente, uma réplica secundária pode oferecer suporte a acesso somente leitura a bancos de dados secundários e à criação de backups nesses mesmos bancos de dados.
ouvinte do grupo de disponibilidade Um nome de 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 do Grupo de Disponibilidade direcionam as conexões de entrada para a réplica primária ou para uma réplica secundária em modo de leitura.

Bancos de dados de disponibilidade

Para adicionar um banco de dados a um grupo de disponibilidade, o banco de dados deve ser um banco de dados online de leitura-gravação que exista na instância do servidor que hospeda a réplica primária. Quando você adiciona um banco de dados, ele se junta ao grupo de disponibilidade como um banco de dados primário, permanecendo disponível para os clientes. Nenhum banco de dados secundário correspondente existe até que os backups do novo banco de dados primário sejam restaurados para a instância do servidor que hospeda a réplica secundária (usando RESTORE WITH NORECOVERY). O novo banco de dados secundário está no estado RESTORING até ser associado ao grupo de disponibilidade. Para obter mais informações, consulte 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 a sincronização de dados com o banco de dados primário correspondente. Sincronização de dados é o processo pelo qual as alterações numa base de dados primária são reproduzidas numa base de dados secundária. A sincronização de dados envolve o envio de registros de log de transações pelo banco de dados primário para o banco de dados secundário.

Importante

Uma base de dados de disponibilidade é às vezes chamada de réplica de base de dados nos nomes Transact-SQL, PowerShell e nos SQL Server Management Objects (SMO). Por exemplo, o termo "réplica de banco de dados" é usado nos nomes das exibições de gerenciamento dinâmico Always On que retornam informações sobre bancos de dados de disponibilidade: sys.dm_hadr_database_replica_states e sys.dm_hadr_database_replica_cluster_states. No entanto, nos Manuais Online do SQL Server, o termo "réplica" normalmente se refere a réplicas de disponibilidade. Por exemplo, "réplica primária" e "réplica secundária" sempre se referem 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. Réplicas de disponibilidade são componentes do grupo de disponibilidade. Cada réplica de disponibilidade acolhe uma cópia dos dados de disponibilidade dentro do grupo de disponibilidade. Para um determinado grupo de disponibilidade, as réplicas de disponibilidade devem ser hospedadas por instâncias separadas do SQL Server residentes em nós diferentes de um cluster WSFC. Cada uma dessas instâncias de servidor deve ser habilitada para Always On.

O SQL Server 2019 (15.x) aumenta 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.

Uma determinada instância pode hospedar apenas uma réplica de disponibilidade por grupo de disponibilidade. No entanto, cada instância pode ser usada 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 necessitar de redundância ao nível do servidor, utilize Instâncias de Cluster de Failover.

A cada réplica de disponibilidade é atribuída uma função inicial - a função principal ou a função secundária , que é herdada pelos bancos de dados de disponibilidade dessa réplica. 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 réplica primária , recebe a função principal e hospeda bancos de dados de leitura-gravação, conhecidos como bancos de dados primários . Pelo menos uma outra réplica, conhecida como 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 é indeterminada, como durante um failover, seus bancos de dados estão temporariamente em um estado NÃO SINCRONIZANDO. A sua função é definida como RESOLVENDO até que a função da réplica de disponibilidade seja resolvida. Se uma réplica de disponibilidade assumir a função principal, os seus bancos de dados tornar-se-ão os bancos de dados principais. Se uma réplica de disponibilidade for resolvida para a função secundária, seus bancos de dados se tornarão bancos de dados secundários.

Modos de disponibilidade

O modo de disponibilidade é uma propriedade de cada réplica de disponibilidade. O modo de disponibilidade determina se a réplica primária aguarda para confirmar transações em um banco de dados, até que uma determinada réplica secundária tenha gravado os registros do log de transações no disco (fortaleceu o log). Os grupos de disponibilidade Always On suportam dois modos de disponibilidade: modo de confirmação assíncrona e 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 de confirmação assíncrona . No modo de confirmação assíncrona, a réplica primária confirma transações sem esperar pela confirmação de réplicas secundárias de confirmação assíncrona para consolidar os logs 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 eles fiquem atrás dos bancos de dados primários, tornando possível alguma perda de dados.

  • Modo de confirmação síncrona

    Uma réplica de disponibilidade que usa esse modo de disponibilidade é conhecida como 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 confirmar que terminou de proteger o log. O modo de confirmação síncrona garante que, uma vez que um determinado banco de dados secundário seja sincronizado com o banco de dados primário, as transações confirmadas sejam totalmente protegidas. Essa proteção tem o custo do aumento da latência das transações. Opcionalmente, o SQL Server 2017 introduziu um recurso necessário de secundários sincronizados, , para aumentar ainda mais a segurança ao custo da latência, se desejado. O recurso REQUIRED_SYNCHRONIZED_SECONDARIES_TO_COMMIT pode ser habilitado para exigir um número especificado de réplicas síncronas para confirmar uma transação antes que uma réplica primária tenha permissão para confirmar.

Para obter mais informações, consulte Diferenças entre modos de disponibilidade para um grupo de disponibilidade Always On.

Tipos de recuperação de falhas

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 são potencialmente intercambiáveis num processo conhecido como failover. Durante um failover, a réplica secundária alvo passa para o papel de principal, tornando-se a nova réplica primária. A nova réplica primária coloca seus bancos de dados on-line como os bancos de dados primários, e os aplicativos cliente podem se conectar a eles. Assim que a réplica primária anterior fica disponível, ela transita para a função secundária, tornando-se uma réplica secundária. Os antigos bancos de dados primários tornam-se bancos de dados secundários e a sincronização de dados é retomada.

Um grupo de disponibilidade realiza failover no nível de uma réplica de disponibilidade. Os failovers não são causados por problemas de banco de dados, como um banco de dados se tornar suspeito devido a uma 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 suportadas por uma determinada réplica secundária dependem do seu modo de disponibilidade e, para o modo de confirmação síncrona, do modo de failover na réplica primária e na réplica secundária de destino, como se segue.

  • O modo de confirmação síncrona suporta duas formas de failover de failover manual planejado e de failover automático, se a réplica secundária de destino estiver sincronizada com a réplica primária. O suporte para essas formas de falha depende da configuração da propriedade do modo de falha nos parceiros de falha. Se o modo de failover estiver definido como "manual" na réplica primária ou secundária, somente o failover manual será suportado para essa réplica secundária. Se o modo de failover estiver definido como "automático" nas réplicas primária e secundária, há suporte para failover automático e manual nessa réplica secundária.

    • de failover manual planejado (sem perda de dados)

      Um failover manual ocorre depois que um administrador de banco de dados emite um comando de failover e 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 faça a transição para a função secundária. Um failover manual requer que a réplica primária e a réplica secundária de destino estejam sendo executadas no modo de confirmação síncrona, e a réplica secundária já deve estar sincronizada.

    • de failover automático (sem perda de dados)

      Um failover automático ocorre em resposta a uma falha que faz com que uma réplica secundária sincronizada faça a transição para a função principal (com proteção de dados garantida). Quando a réplica primária anterior fica disponível, ela passa para a função secundária. O failover automático requer que a réplica primária e a réplica secundária de destino estejam sendo executadas no modo de confirmação síncrona, com o modo de failover definido como automático . Além disso, a réplica secundária já deve estar sincronizada, ter quórum 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), normalmente chamado de failover forçado . O failover forçado é considerado uma forma de failover manual porque só pode ser iniciado 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 está sincronizada com a réplica primária.

Para obter mais informações, consulte comutação por falha e modos de comutação por falha (Always On Availability Groups).

Importante

  • As FCIs (Instâncias de Cluster de Failover) do SQL Server não oferecem suporte a failover automático por grupos de disponibilidade, portanto, qualquer réplica de disponibilidade hospedada por uma FCI só pode ser configurada para failover manual.
  • 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 forma que para um failover manual planejado.

Benefícios

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

  • Suporta até nove réplicas de disponibilidade. Uma réplica de disponibilidade é uma instanciação de um grupo de disponibilidade hospedado por uma instância específica do SQL Server e mantém uma cópia local de cada banco de dados de disponibilidade que pertence ao grupo de disponibilidade. Cada grupo de disponibilidade oferece suporte a uma réplica primária e até oito réplicas secundárias. Para obter mais informações, consulte O que é um grupo de disponibilidade Always On?

    Importante

    Cada réplica de disponibilidade deve residir em nós diferentes de um só cluster WSFC (Cluster de Failover do Windows Server). Para obter mais informações sobre pré-requisitos, restrições e recomendações para grupos de disponibilidade, consulte Pré-requisitos, restrições e recomendações para grupos de disponibilidade Always On.

  • Suporta modos de disponibilidade alternativos, da seguinte forma:

    • Modo de confirmação assíncrona. Esse modo de disponibilidade é 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.

    • Modo de confirmação síncrona. Esse modo de disponibilidade enfatiza a alta disponibilidade e a proteção de dados em relação ao desempenho, ao custo de maior latência de transação. Um determinado grupo de disponibilidade pode suportar até cinco réplicas de disponibilidade de compromisso síncrono, incluindo a réplica primária atual.

      Para obter mais informações, consulte Diferenças entre modos de disponibilidade para um grupo de disponibilidade Always On.

  • Suporta várias formas de failover de grupo de disponibilidade: failover automático, failover manual planejado (geralmente referido como simplesmente "failover manual") e failover manual forçado (geralmente referido como simplesmente "failover forçado"). Para obter mais informações, consulte Failover e Modos de Failover (Grupos de Disponibilidade Always On).

  • Permite configurar uma determinada réplica de disponibilidade para oferecer suporte a um ou a ambos os seguintes recursos ativo-secundários:

  • Suporta um ouvinte de grupo de disponibilidade para cada grupo de disponibilidade. Um de ouvinte de grupo de disponibilidade de é um nome de 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 Always On. Os listeners do grupo de disponibilidade direcionam as conexões de entrada para a réplica primária ou para uma réplica secundária de leitura apenas. O listener fornece um failover rápido de aplicações após o failover de um grupo de disponibilidade. Para obter mais informações, consulte Conectar-se a um ouvinte de grupo de disponibilidade Always On.

  • Suporta uma política de failover flexível para maior controle sobre o failover do grupo de disponibilidade. Para obter mais informações, consulte Modo de Redundância e Tolerância a Falhas (Always On Availability Groups).

  • Suporta reparo automático de página para proteção contra corrupção de página. Para mais informações, consulte Reparo Automático de Páginas (Grupos de Disponibilidade: Espelhamento de Bases de Dados).

  • Suporta criptografia e compactação, que fornecem um transporte seguro e de alto desempenho.

  • Fornece um conjunto integrado de ferramentas para simplificar a implantação e o gerenciamento de grupos de disponibilidade, incluindo:

Conexões de cliente

Você pode fornecer conectividade de cliente para a 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 anexados a um determinado grupo de disponibilidade para direcionar conexões de cliente para a réplica de disponibilidade apropriada.

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

Dica

Se um grupo de disponibilidade possuir apenas duas réplicas de disponibilidade e não estiver configurado para permitir 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 temporariamente útil após migrar uma base de dados da funcionalidade de espelhamento de bases de dados para os grupos de disponibilidade Always On. Antes de adicionar réplicas secundárias, é necessário criar um listener para o grupo de disponibilidade e atualizar as suas aplicações para usar o nome de rede do listener.

Réplicas secundárias ativas

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

  • Execução de operações de backup em réplicas secundárias

    As réplicas secundárias oferecem suporte à execução de backups de log e de backups apenas de cópia de um banco de dados completo, arquivo ou grupo de arquivos. Você pode configurar o grupo de disponibilidade para especificar uma preferência para onde os backups devem ser executados. É importante entender que a preferência não é imposta pelo SQL Server, portanto, não tem efeito em backups ad hoc. A interpretação dessa preferência depende da lógica, caso exista, que é incorporada nos trabalhos de backup para cada um dos bancos de dados num grupo de disponibilidade específico. Para uma réplica de disponibilidade individual, você pode especificar sua prioridade para executar backups nessa réplica em relação às outras réplicas no mesmo grupo de disponibilidade. Para obter mais informações, consulte Transferir os backups suportados para réplicas secundárias de um grupo de disponibilidade.

  • Acesso somente leitura a uma ou mais réplicas secundárias (réplicas secundárias legíveis)

    Qualquer réplica de disponibilidade secundária pode ser configurada para permitir apenas acesso de leitura aos seus bancos de dados locais, embora algumas operações não sejam totalmente suportadas. Isso impede tentativas de conexão de leitura-gravação com a réplica secundária. Também é possível evitar cargas de trabalho somente leitura na réplica principal de, permitindo apenas acesso de leitura e escrita. Isso impede que conexões somente leitura sejam feitas com a réplica primária. Para obter mais informações, consulte Transferir carga de trabalho de leitura apenas para a réplica secundária de um grupo de disponibilidade "Always On".

    Se um grupo de disponibilidade possuir atualmente uma escuta de grupo de disponibilidade e uma ou mais réplicas secundárias com capacidade de leitura, o SQL Server poderá rotear conexões com intenção de leitura para uma delas (roteamento somente leitura). Para obter mais informações, consulte Conectar-se a um ouvinte de grupo de disponibilidade Always On.

Período de tempo de inatividade da sessão

O tempo limite da sessão é uma propriedade da réplica de disponibilidade que determina quanto tempo a ligação com outra réplica de disponibilidade pode permanecer inativa antes de a ligação ser encerrada. As réplicas primária e secundária fazem ping entre si para sinalizar que ainda estão ativas. Receber um ping da 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. Ao receber um ping, uma réplica de disponibilidade redefine o seu contador de tempo limite de sessão nessa conexão.

O período de tempo limite de sessão impede que qualquer réplica aguarde indefinidamente para receber um ping da 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 expirará. Sua conexão é fechada e a réplica com tempo limite expirado entra no estado DISCONNECTED. Mesmo que uma réplica desconectada esteja configurada para o modo de confirmação síncrona, as transações não esperam que essa réplica se reconecte e ressincronize.

O período de tempo limite de sessão padrão para cada réplica de disponibilidade é de 10 segundos. Este valor é configurável pelo utilizador, com um mínimo de 5 segundos. Geralmente, recomendamos que você mantenha o período de tempo limite em 10 segundos ou mais. Definir o valor para menos de 10 segundos cria a possibilidade de um sistema muito carregado declarar uma falha falsa.

Observação

Na função de resolução de problemas, o tempo de expiração da sessão não se aplica porque o ping não ocorre.

Reparação automática de páginas

Cada réplica de disponibilidade tenta se recuperar automaticamente de páginas corrompidas em um banco de dados local resolvendo certos 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 nova cópia 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 nova cópia para todas as réplicas secundárias e obterá a página da primeira a responder. Se essa solicitação for bem-sucedida, a página ilegível será substituída pela cópia, que geralmente resolve o erro.

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

Interoperabilidade e coexistência com outros recursos do Mecanismo de Banco de Dados

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

Próximo passo

Introdução aos grupos de disponibilidade Always On