Recuperação de desastres do WSFC por meio de quórum forçado (SQL Server)

Aplica-se:SQL Server

A falha de quórum normalmente é causada por um desastre sistêmico, por uma falha persistente de comunicações ou por uma configuração incorreta envolvendo vários nós no cluster WSFC. É necessária intervenção manual para se recuperar de uma falha de quorum.

Pré-requisitos

O Procedimento de Quorum Forçado supõe que um quorum íntegro existia antes da falha de quorum.

Aviso

O usuário deve estar bem-informado sobre os conceitos e as interações do Windows Server Failover Clustering, Modelos de Quorum do WSFC, o SQL Servere a configuração de implantação específica do ambiente.

Para obter mais informações, consulte: Clustering de Failover do Windows Server (WSFC) com SQL Server, Modos de Quórum e Configuração de Votação do WSFC (SQL Server)

Segurança

O usuário deve ser uma conta de domínio que seja membro do grupo Administradores local em cada nó do cluster WSFC.

Recuperação de desastre do WSFC por meio do procedimento de quórum forçado

Lembre-se de que a falha de quorum fará com que todos os serviços em cluster, as instâncias do SQL Server e os grupos de disponibilidade Always On no cluster WSFC fiquem offline, pois o cluster, conforme configurado, não pode garantir tolerância a falhas em nível de nó. Uma falha de quorum significa que os nós de votação saudáveis no cluster WSFC não atendem mais ao modelo de quorum. Alguns nós podem ter falhado totalmente e outros podem ter apenas desligado o serviço WSFC e, nesse caso, são íntegros, exceto pela perda da capacidade de comunicação com um quorum.

Para colocar o cluster WSFC novamente online, corrija a causa raiz da falha de quorum na configuração existente, recupere os bancos de dados afetados quando necessário e, se desejar, reconfigure os nós restantes no cluster WSFC para refletir a topologia de cluster sobrevivente.

Você pode usar o procedimento de quorum forçado em um nó de cluster WSFC para ignorar os controles de segurança que colocaram o cluster offline. Isso efetivamente instrui o cluster a suspender as verificações de quórum de votação e permite que você coloque novamente em funcionamento os recursos do cluster WSFC e o SQL Server em qualquer um dos nós do cluster.

Esse tipo de processo de recuperação de desastres deve incluir as seguintes etapas:

Para recuperar de falha de quorum:

  1. Determine o escopo da falha. Identifique quais grupos de disponibilidade ou instâncias do SQL Server estão sem resposta, quais nós de cluster estão online e disponíveis para uso pós-desastre, e examine os logs de eventos do Windows e os logs do sistema SQL Server. Quando for prático, você deve preservar dados forenses e os logs do sistema para análise futura.

    Dica

    Em uma instância responsiva do SQL Server, você pode obter informações sobre a integridade de grupos de disponibilidade que possuam uma réplica de disponibilidade na instância de servidor local consultando a DMV (exibição de gerenciamento dinâmico) sys.dm_hadr_availability_group_states .

  2. Inicie o cluster do WSFC usando o quórum forçado em um único nó. Identifique um nó com o menor número de falhas de componentes, exceto pelo desligamento do serviço de cluster do WSFC. Verifique se este nó pode se comunicar com a maioria dos demais nós.

    Neste nó, force o cluster manualmente a entrar em funcionamento por meio do procedimento de quorum forçado. Para minimizar a perda potencial de dados, selecione um nó que foi o último a hospedar uma réplica primária de um grupo de disponibilidade.

    Para obter mais informações, confira: Forçar um cluster WSFC a iniciar sem um quorum

    Observação

    A configuração de quórum forçado afeta todo o cluster ao bloquear as verificações de quórum até que o cluster WSFC lógico alcance a maioria dos votos e faça a transição automaticamente para um modo normal de operação de quórum.

  3. Inicie normalmente o serviço WSFC em cada nó que, fora isso, esteja íntegro, um de cada vez. Você não precisará especificar a opção de quorum forçado quando iniciar o serviço de cluster nos outros nós.

    À medida que o serviço WSFC em cada nó volta a ficar disponível, ele negocia com os outros nós saudáveis para sincronizar o novo estado da configuração do cluster. Lembre-se de fazer isso em um nó por vez para evitar possíveis condições de corrida ao determinar o último estado conhecido do cluster.

    Aviso

    Verifique se cada nó que você iniciar pode se comunicar com os outros nós que acabaram de entrar em operação. Considere a desabilitação do serviço WSFC nos outros nós. Caso contrário, você corre o risco de criar mais de um conjunto de nós de quórum; ou seja, um cenário de split-brain. Se seus resultados na etapa 1 forem precisos, isso não deve ocorrer.

  4. Aplique o novo modo de quorum e a configuração de voto de nó. Se a imposição do quórum reiniciou com êxito todos os nós do cluster e a causa raiz da falha de quórum foi corrigida, não é necessário fazer alterações no modo de quórum original nem na configuração de votos dos nós.

    Caso contrário, você deve avaliar o nó de cluster recém-recuperado e a topologia das réplicas de disponibilidade, e alterar o modo de quorum e as atribuições de voto de cada nó, conforme necessário. Nós não recuperados devem ser colocados offline ou ter seus votos de nó definidos como zero.

    Dica

    Neste momento, os nós e as instâncias do SQL Server no cluster podem parecer terem voltado à operação normal. Entretanto, talvez ainda não exista um quorum íntegro. Usando o Gerenciador de Cluster de Failover ou o Painel AlwaysOn no SQL Server Management Studio ou os DMVs apropriados, verifique se um quorum foi restaurado.

  5. Recupere as réplicas de banco de dados do grupo de disponibilidade, conforme necessário. Os bancos de dados que não pertencem a um grupo de disponibilidade devem se recuperar e voltar a ficar online por conta própria, como parte do processo normal de inicialização do SQL Server.

    Você pode minimizar a possível perda de dados e o tempo de recuperação para as réplicas de grupo de disponibilidade, colocando-os novamente online nesta sequência: réplica primária, réplicas secundárias síncronas, réplicas secundárias assíncronas.

Observação

Depois de usar quorum forçado, é necessário executar um failover forçado com possível perda de dados para colocar o grupo de disponibilidade novamente online. Para obter mais informações, consulte Executar um failover manual forçado de um grupo de disponibilidade (SQL Server).

  1. Repare ou substitua componentes com falha e revalide o cluster. Agora que você se recuperou do desastre inicial e da falha de quorum, deve reparar ou substituir os nós com falhas e ajustar as configurações de WSFC e AlwaysOn relacionadas adequadamente. Isso pode incluir a exclusão de réplicas de grupos de disponibilidade, a remoção de nós do cluster ou a reconfiguração e reinstalação do software em um nó.

    Você deve reparar ou remover todas as réplicas de disponibilidade com falha. O SQL Server não truncará o log de transações além do último ponto conhecido da réplica de disponibilidade mais atrasada. Se uma réplica com falha não for reparada ou removida do grupo de disponibilidade, os logs de transação crescerão e você correrá o risco de ficar sem espaço de log de transação nas outras réplicas.

    Observação

    Se você executar o Assistente para Validar uma Configuração do WSFC quando houver um ouvinte de grupo de disponibilidade no cluster do WSFC, o assistente gerará a seguinte mensagem de aviso incorreta:

    "A propriedade RegisterAllProviderIP para nome de rede "Name:<network_name>" é definida como 1. Para a configuração do cluster atual, este valor deve ser definido como 0."

    Ignore esta mensagem.

  2. Repita a etapa 4 conforme necessário. A meta é restabelecer o nível apropriado de tolerância a falhas e a alta disponibilidade para operações íntegras.

  3. Realize a análise de RPO/RTO. Você deve analisar os logs do sistema do SQL Server, as marcas de data e hora dos bancos de dados e os logs de eventos do Windows para determinar a causa raiz da falha, bem como documentar os valores reais observados do ponto de recuperação e do tempo de recuperação.

Tarefas Relacionadas

Conteúdo relacionado

Consulte Também

WSFC (Windows Server Failover Clustering) com o SQL Server

  • Last updated on