Compartilhar via

Solucionar problemas do SQL Server Always On

  • Artigo

Este artigo ajuda você a resolver o problema comum sobre a configuração Always On no SQL Server.

Observação

Para obter uma experiência guiada deste artigo, consulte Solucionando problemas do SQL Server Always On.

Versão original do produto: SQL Server 2012 Enterprise, SQL Server 2014 Enterprise, SQL Server 2016 Enterprise
Número original do KB: 10179

Observações importantes

Preciso de dicas sobre como instalar e configurar grupos de disponibilidade AlwaysOn

Se você estiver procurando documentação sobre como definir a configuração Always On, consulte os seguintes documentos:

Introdução aos Grupos de Disponibilidade AlwaysOn (SQL Server) – o documento fornece respostas para muitas perguntas que você pode ter sobre grupos de disponibilidade e instalação. Seguir todas as etapas deste artigo e examinar os pré-requisitos, as restrições e as recomendações para Grupos de Disponibilidade AlwaysOn (SQL Server) ajudará a evitar muitos problemas que você pode encontrar com a configuração e a manutenção de grupos de disponibilidade em seu ambiente.

Recursos adicionais

Se essas informações não forem úteis, consulte Mais informações sobre Grupos de Disponibilidade AlwaysOn.

Estou tendo problemas para configurar grupos de disponibilidade Always On

Os problemas de configuração típicos incluem Grupos de Disponibilidade Always On desabilitados, contas configuradas incorretamente, o ponto de extremidade de espelhamento de banco de dados não existe, o ponto de extremidade está inacessível (Erro 1418 do SQL Server), o acesso à rede não existe e um comando de banco de dados de junção falha (Erro 35250 do SQL Server). Revise o seguinte documento para obter ajuda sobre como solucionar esses problemas:

Solucionar problemas de configuração de grupos de disponibilidade AlwaysOn (SQL Server)

Link adicional: Correção: Erro 41009 ao tentar criar vários grupos de disponibilidade

Se o problema persistir, consulte Mais informações sobre Grupos de Disponibilidade AlwaysOn.

Estou tendo problemas com a configuração do Listener (19471, 19476 e outros erros)

Um dos problemas de configuração mais comuns que os clientes encontram é a criação do ouvinte do grupo de disponibilidade. Os erros são semelhantes aos seguintes:

  • Msg 19471, Nível 16, Estado 0, Linha 2O cluster WSFC não pôde colocar o recurso Nome de Rede com o nome DNS '' online. O nome DNS pode ter sido usado ou ter um conflito com os serviços de nome existentes, ou o serviço de cluster WSFC pode não estar em execução ou pode estar inacessível. Use um nome DNS diferente para resolver conflitos de nome ou verifique o log do cluster WSFC para obter mais informações.

  • Msg 19476, Nível 16, Estado 4, Linha 2Falha na tentativa de criar o nome da rede e o endereço IP para o ouvinte. O serviço WSFC pode não estar em execução ou pode estar inacessível em seu estado atual, ou os valores fornecidos para o nome da rede e o endereço IP podem estar incorretos. Verifique o estado do cluster WSFC e valide o nome da rede e o endereço IP com o administrador da rede.

Na maioria das vezes, a falha na criação do ouvinte que resulta nas mensagens anteriores é devido à falta de permissões para o CNO (Objeto de Nome de Cluster) no Active Directory para criar e ler o objeto de computador ouvinte. Para solucionar esse problema, consulte os seguintes artigos:

Se o problema persistir, consulte Mais informações sobre Grupos de Disponibilidade AlwaysOn.

O failover automático não está funcionando conforme o esperado

Se você perceber que o failover automático não está funcionando conforme o esperado durante o teste ou na produção, consulte: Solução de problemas de failover automático em ambientes Always On do SQL Server 2012.

A configuração inadequada de falhas máximas no período especificado é uma das principais causas para o primário não falhar automaticamente para o secundário. O valor padrão para essa configuração é N-1, em que N é o número de réplicas. Para obter mais informações, consulte Limite máximo de falhas do cluster de failover (grupo).

Se o problema persistir, consulte Mais informações sobre Grupos de Disponibilidade AlwaysOn.

Estou tendo problemas para me conectar a grupos de disponibilidade Always On

Depois de configurar o ouvinte do grupo de disponibilidade para um Grupo de Disponibilidade Always On no SQL Server 2012, talvez você não consiga executar ping no ouvinte ou conectar-se a ele de um aplicativo. Você pode receber um erro semelhante ao seguinte:

Sqlcmd: Erro: Microsoft SQL Native Client: Tempo limite de logon expirado.

Para solucionar esse e outros erros semelhantes, revise o seguinte:

Mais links de informações:

Se o problema persistir, consulte Mais informações sobre Grupos de Disponibilidade AlwaysOn.

Estou tendo problemas para configurar grupos de disponibilidade Always On na minha VM do Azure (IaaS)

  1. Muitos problemas relacionados ao Always On ocorrem devido à configuração inadequada do ouvinte. Se você estiver tendo problemas de conexão com o ouvinte,

    1. Certifique-se de ler todas as limitações do ouvinte ILB e seguir todas as etapas documentadas no artigo a seguir, prestando atenção especial à configuração de dependência, endereço IP e vários outros parâmetros no script do PowerShell.

    2. Se não tiver certeza, convém excluir e recriar o ouvinte de acordo com o documento acima.

  2. Se você moveu recentemente sua VM para um serviço diferente ou se os endereços IP foram alterados, será necessário atualizar o valor do recurso de endereço IP para refletir o novo endereço e recriar o ponto de extremidade com balanceamento de carga para o AG. Você pode atualizar o endereço IP usando os Get comandos ou Set da seguinte maneira:

    Get-ClusterResource "IPResourceName" | Set-ClusterParameter -name Address -value "w.x.y.z"

Documentos recomendados:

Se o problema persistir, consulte Mais informações sobre Grupos de Disponibilidade AlwaysOn.

Leva muito tempo para fazer failover do primário para o secundário ou vice-versa

Após um failover automático ou um failover manual planejado sem perda de dados em um grupo de disponibilidade, você descobre que o tempo de failover excedeu o RTO (objetivo de tempo de recuperação). Para solucionar as causas e possíveis resoluções, consulte Solução de problemas: RTO excedido do grupo de disponibilidade.

Se o problema persistir, consulte Mais informações sobre Grupos de Disponibilidade AlwaysOn.

As alterações na réplica primária não são refletidas ou demoram para serem replicadas para a réplica secundária

Você pode observar que as alterações na réplica primária não estão sendo propagadas para a secundária em tempo hábil. Para solucionar esses problemas, tente o seguinte:

Se o problema persistir, consulte Mais informações sobre Grupos de Disponibilidade AlwaysOn.

Como gerenciar o tamanho do log de transações para meus bancos de dados AG

Você pode reduzir os tamanhos dos logs de transações configurando backups regulares em servidores primários ou secundários.

Revise os seguintes tópicos para obter informações adicionais:

Se essas informações não forem úteis, consulte Mais informações sobre Grupos de Disponibilidade AlwaysOn.

Servidores primários ou secundários atingidos no estado de resolução ou você experimenta failovers inesperados

Se o problema persistir, consulte Mais informações sobre Grupos de Disponibilidade AlwaysOn.

Não é possível colocar recursos online

Verifique se os bancos de dados estão demorando muito para se recuperar revisando as mensagens no SQL ErrorLog.

Se o problema persistir, consulte Mais informações sobre Grupos de Disponibilidade AlwaysOn.

Perguntas frequentes

  1. É possível ter dois ouvintes para um grupo de disponibilidade?

    Sim, você pode configurar vários ouvintes para o mesmo grupo de disponibilidade. Consulte Como criar vários ouvintes para o mesmo grupo de disponibilidade (Goden Yao).

  2. É possível ter uma placa NIC separada para tráfego sempre ativo e conectividade do cliente?

    Sim, você pode ter uma placa NIC dedicada para o tráfego Always On. Consulte Configurar o grupo de disponibilidade para se comunicar em uma rede dedicada.

  3. Quais edições oferecem suporte a instâncias de cluster de failover Always On?

    Este tópico nos Manuais Online do SQL Server tem mais informações: Edições e recursos com suporte para o SQL Server 2016.

  4. Como recuperar em caso de falha em todos os nós do seu cluster?

    Consulte Recuperação de desastre do WSFC por meio de quorum forçado (SQL Server).

  5. Onde posso encontrar informações sobre suporte para transações distribuídas em configurações do AG?

    Consulte Transações – grupos de disponibilidade e espelhamento de banco de dados.

  6. Como atualizar as configurações do Always On?

    Consulte Atualizando instâncias de réplica do grupo de disponibilidade Always On.

  7. Como adicionar banco de dados habilitado para TDE (Transparent Data Encryption) à configuração do AG?

    Para adicionar o banco de dados habilitado para TDE ao AG, consulte Como configurar o Always On para um banco de dados TDE.

  8. Como configurar alertas para verificar se o secundário está atrasado em relação ao primário?

    Você pode usar o seguinte script:

    SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
dr_state.database_id AS database_id,
is_ag_replica_local = CASE
    WHEN ar_state.is_local = 1 THEN N'LOCAL'
    ELSE 'REMOTE'
    END,
ag_replica_role = CASE
    WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
    ELSE ar_state.role_desc
    END,
dr_state.last_hardened_lsn, dr_state.last_hardened_time,
datediff(s,last_hardened_time, getdate()) AS 'seconds behind primary'
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ag.group_id = ar.group_id)
JOIN sys.dm_hadr_availability_replica_states AS ar_state
    ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
    ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id

  9. Como ser alertado se o estado do banco de dados for diferente de sincronizado?

    Você pode usar o seguinte script:

    SELECT ag.name AS ag_name, ar.replica_server_name AS ag_replica_server,
dr_state.database_id AS database_id,
is_ag_replica_local = CASE
    WHEN ar_state.is_local = 1 THEN N'LOCAL'
    ELSE 'REMOTE'
    END,
ag_replica_role = CASE
    WHEN ar_state.role_desc IS NULL THEN N'DISCONNECTED'
    ELSE ar_state.role_desc
    END,
ar_state.connected_state_desc, ar.availability_mode_desc, dr_state.synchronization_state_desc
FROM (( sys.availability_groups AS ag
JOIN sys.availability_replicas AS ar
    ON ag.group_id = ar.group_id )
JOIN sys.dm_hadr_availability_replica_states AS ar_state
    ON ar.replica_id = ar_state.replica_id)
JOIN sys.dm_hadr_database_replica_states dr_state
    ON ag.group_id = dr_state.group_id AND dr_state.replica_id = ar_state.replica_id

    Você também pode examinar os seguintes links para métodos adicionais para monitorar grupos AlwaysOn:

Mais informações sobre Grupos de Disponibilidade AlwaysOn