Compartilhar via


Determinar o possível motivo de falhas de conectividade entre réplicas de disponibilidade

Aplica-se a: SQL Server

Problemas físicos, do sistema operacional ou do SQL Server podem provocar uma falha em uma sessão entre duas réplicas de disponibilidade. Uma réplica de disponibilidade não verifica regularmente os componentes dos quais o sqlservr.exe depende para verificar se estão funcionando corretamente ou se houve falha. Porém, para alguns tipos de falhas, o componente afetado informa um erro ao sqlservr.exe. Um erro informado por outro componente é chamado um erro de hardware.

Para detectar outras falhas, que de outra forma passariam despercebidas, os Grupos de Disponibilidade AlwaysOn implementam o próprio mecanismo de tempo limite de sessão deles. O tempo limite da sessão é especificado em segundos. Esse tempo limite é o tempo máximo que uma instância de servidor espera para receber uma mensagem PING de outra instância antes de considerá-la desconectada. Quando um tempo limite de sessão ocorre entre duas réplicas de disponibilidade, as réplicas de disponibilidade pressupõem que ocorreu uma falha e declaram um erro de software.

Importante

Falhas em bancos de dados diferentes do banco de dados primário não são detectáveis. Além disso, é improvável que uma falha no disco de dados seja detectada, a menos que o banco de dados seja reiniciado por causa de uma falha no disco de dados.

A velocidade da detecção de erro e, consequentemente, o tempo de reação de uma falha depende do tipo do erro: de hardware ou de software. Alguns erros de hardware, como falhas de rede, são informados imediatamente. Porém, em alguns casos, períodos de tempo limite específicos do componente podem atrasar o relatório de alguns erros de hardware. Para erros de software, a duração do tempo limite da sessão determina a velocidade da detecção de erros. Por padrão, esse período é 10 segundos. Esse é o valor mínimo recomendado.

Falhas devido a erros de hardware

As possíveis causas de erros de hardware incluem, dentre outras coisas, as seguintes condições:

  • Uma conexão ou um cabo interrompido
  • Uma placa de rede incorreta
  • Uma alteração no roteador
  • Alterações no firewall
  • Reconfiguração de ponto de extremidade
  • Perda da unidade onde o log de transações reside
  • Falha de sistema operacional ou de processo

Por exemplo, quando a unidade de log do banco de dados primário se torna sem resposta e apresenta uma falha, o sistema operacional informa a sqlservr.exe que ocorreu um erro grave.

Alguns componentes, como aqueles de rede e alguns subsistemas de E/S, têm tempos limite próprios para determinar falhas. Esses tempos limite são independentes dos Grupos de Disponibilidade AlwaysOn, que não têm conhecimento sobre eles e não sabem nada sobre o comportamento deles. Nesses casos, o atraso do tempo limite aumenta o tempo entre uma falha e o momento em que a réplica de disponibilidade recebe o erro de hardware resultante.

Observação

A única verificação de erros ativa executada para réplicas de disponibilidade ocorre nos casos de erros de software. Para obter mais informações, consulte "Falhas devido a erros de software", mais adiante neste tópico.

Para ajudar o usuário a interpretar as condições de erro que ocorrem na rede, pergunte a um engenheiro de rede quais são as mensagens de erro enviadas a uma porta quando os seguintes eventos ocorrem em uma conexão TCP:

  • O DNS não está funcionando.
  • Cabos estão desconectados.
  • Microsoft O Windows tem um firewall que bloqueia uma porta específica.
  • Falha no aplicativo que está monitorando uma porta.
  • Um servidor baseado no Windows é renomeado.
  • Um servidor baseado em Windows é reiniciado.

Observação

Os Grupos de Disponibilidade AlwaysOn não protege contra problemas específicos para clientes que acessam os servidores. Considere, por exemplo, um caso em que um adaptador de rede pública controla as conexões de cliente com a réplica primária, enquanto uma placa de interface de rede privada controla todo o tráfego entre as instâncias do servidor que estão hospedando as réplicas de um grupo de disponibilidade. Nesse caso, uma falha do adaptador de rede pública impediria os clientes de acessarem os bancos de dados.

Falhas devido a erros recuperáveis

As condições que poderiam provocar expirações do tempo limite de sessão incluem, dentre outra coisas, as seguintes:

  • Erros de rede, como tempos-limite de link de TCP, pacotes descartados ou corrompidos ou pacotes que estão em ordem incorreta.

  • Um sistema operacional, servidor ou banco de dados que não está respondendo.

  • Um servidor Windows que atingiu o tempo limite.

  • Recursos computacionais insuficientes, tais como sobrecarga de uma CPU ou disco, filling up do log de transações ou o sistema está sendo executado sem memória ou threads. Nesses casos, é preciso aumentar o período de tempo limite, reduzir a carga de trabalho ou alterar o hardware para controlar a carga de trabalho.

O mecanismo de tempo-limite de sessão

Como erros recuperáveis não são detectáveis diretamente por uma instância de servidor, esse tipo de erro pode fazer com que uma réplica de disponibilidade espere indefinidamente uma resposta da outra réplica de disponibilidade em uma sessão. Para evitar isso, o Grupos de disponibilidade AlwaysOn implementa um mecanismo de tempo limite de sessão com base nas réplicas de disponibilidade conectadas, enviando um ping em cada conexão aberta em um intervalo fixo. A recepção de um ping 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 por ela. Ao receber um ping, uma réplica reajusta seu contador de tempo limite naquela conexão. Para obter informações sobre a relação de tempos limite de sessão e modo de disponibilidade, veja Modos de disponibilidade (Grupos de disponibilidade Always On).

As réplicas primárias e secundárias executam ping uma da outra para sinalizar que ainda estão ativas e um tempo limite de sessão impede que as réplicas esperem indefinidamente para receber um ping da outra réplica. O tempo limite de sessão é uma propriedade de réplica configurável pelo usuário com um valor padrão de 10 segundos. A recepção de um ping 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 por ela. Durante o recebimento de um ping, uma réplica de disponibilidade redefine seu contador de tempo limite nessa conexão.

Se nenhum ping for recebido da outra réplica dentro do período de tempo limite da sessão, ocorrerá o tempo limite da conexão. Sua conexão é fechada e a réplica de tempo limite 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 esperarão que ela se reconecte e seja ressincronizada.

Respondendo a um erro

Independentemente do tipo de erro, uma instância do servidor que detecta um erro responde adequadamente com base na função da instância, no modo de disponibilidade da sessão e no estado de qualquer outra conexão na sessão. Para obter informações sobre o que ocorre na perda de um parceiro, veja Modos de disponibilidade (Grupos de disponibilidade Always On).

Confira também

Próximas etapas