Recuperação após desastre do WSFC por quórum forçado (SQL Server)

Aplica-se a: SQL Server

A falha de quórum é geralmente causada por um desastre sistémico, uma falha persistente nas comunicações ou uma má configuração envolvendo vários nós no cluster WSFC. É necessária intervenção manual para a recuperação de uma falha de quórum.

• Antes de começar:Pré-requisitos, Segurança

• Recuperação após desastre do WSFC através do procedimento de quórum forçadoRecuperação após desastre do WSFC através do procedimento de quórum forçado

• Tarefas relacionadas

• Conteúdo relacionado

Prerequisites

O Procedimento de Quórum Forçado assume que existia um quórum saudável antes da falha do quórum.

Segurança

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

Recuperação após desastre do WSFC através do procedimento de quórum forçado

Lembre-se que a falha do quórum fará com que todos os serviços clusterizados, instâncias do SQL Server e grupos de disponibilidade Always On no cluster WSFC fiquem offline, porque o cluster, tal como configurado, não pode garantir tolerância a falhas ao nível do nó. Uma falha de quórum significa que os nós de voto saudáveis no grupo WSFC já não satisfazem o modelo de quórum. Alguns nós podem ter falhado completamente, e outros podem simplesmente ter encerrado o serviço WSFC e estão de resto saudáveis, exceto pela perda da capacidade de comunicar com quórum.

Para reativar o cluster WSFC, deve corrigir a causa raiz da falha do quórum na configuração existente, recuperar as bases de dados afetadas conforme necessário, e poderá querer reconfigurar os nós restantes no cluster WSFC para refletir a topologia do cluster sobrevivente.

Pode utilizar o procedimento de quórum forçado num nó de um cluster WSFC para contornar os controlos de segurança que deixaram o cluster offline. Isto instrui efetivamente o cluster a suspender as verificações de votação do quórum e permite colocar novamente os recursos do cluster WSFC e o SQL Server em linha em qualquer dos nós do cluster.

Este tipo de processo de recuperação de desastres deve incluir os seguintes passos:

Para recuperar de falha de quórum:

1. Determinar a dimensão da falha. Identifique quais os grupos de disponibilidade ou instâncias do SQL Server que não respondem, quais os nós do cluster que estão online e disponíveis para uso pós-desastre, e examine os registos de eventos do Windows e os registos do sistema do SQL Server. Sempre que possível, deve preservar dados forenses e registos do sistema para análise posterior.

   Sugestão

   Numa instância responsiva de SQL Server, pode obter informações sobre o estado dos grupos de disponibilidade que possuem uma réplica de disponibilidade na instância do servidor local consultando a vista de gestão dinâmica sys.dm_hadr_availability_group_states (DMV).

2. Inicie o cluster WSFC utilizando o quórum forçado em um único nó. Identifique um nó com um número mínimo de falhas de componentes, exceto que o serviço do cluster WSFC foi desligado. Verifique se este nó consegue comunicar com a maioria dos restantes nós.

   Neste nó, forçar manualmente o cluster a entrar online usando o procedimento de quórum forçado. Para minimizar a perda potencial de dados, selecione um nó que estava a hospedar por última vez uma réplica primária do grupo de disponibilidade.

   Para mais informações, veja: Forçar um Agrupamento WSFC a começar sem quórum

   Note

   A configuração de quórum forçado tem efeito em todo o cluster para bloquear as verificações de quórum até que o cluster lógico do WSFC atinja uma maioria de votos e transicione automaticamente para um modo de funcionamento de quórum normal.

3. Inicie normalmente o serviço WSFC em cada nó que, de outra forma, está em bom estado, um de cada vez. Não precisa de especificar a opção de quórum forçado quando inicia o serviço de cluster nos outros nós.

   À medida que o serviço WSFC em cada nó volta a funcionar, negocia com os outros nós saudáveis para sincronizar o novo estado de configuração do cluster. Lembre-se de fazer isto um nó de cada vez para evitar potenciais condições de corrida na resolução do último estado conhecido do cluster.

   Advertência

   Certifique-se de que cada nó que iniciar consegue comunicar com os outros nós que acabaram de ficar online. Considere desativar o serviço WSFC nos restantes nós. Caso contrário, corre o risco de criar mais do que um conjunto de nós de quórum; Isso é um cenário de cérebro dividido. Se as tuas conclusões no passo 1 forem corretas, isso não deveria acontecer.

4. Aplicar o novo modo de quórum e a configuração de voto dos nós. Se forçar o quorum reiniciou com sucesso todos os nós do cluster e a causa raiz da falha do quorum foi corrigida, alterações ao modo original de quórum e à configuração do voto dos nós tornam-se desnecessárias.

   Caso contrário, deve avaliar o nó de cluster recém-recuperado e a topologia de réplica de disponibilidade, e alterar o modo de quórum e as atribuições de votos para cada nó, conforme apropriado. Os nós não recuperados devem ser definidos offline ou ter os votos dos nós definidos a zero.

   Sugestão

   Neste ponto, os nós e instâncias do SQL Server no cluster podem parecer ter sido restaurados para a operação normal. No entanto, pode ainda não existir um quórum saudável. Utilize o Gestor de Clusters de Ativação Pós-falha, ou o Painel Always On no SQL Server Management Studio, ou os DMVs apropriados, para verificar se foi restaurado um quórum.

5. Recuperar réplicas da base de dados do grupo de disponibilidade conforme necessário. As bases de dados de grupos de indisponibilidade devem recuperar e voltar a funcionar sozinhas como parte do processo normal de arranque do SQL Server.

   Pode minimizar a perda potencial de dados e o tempo de recuperação das réplicas do grupo de disponibilidade ao trazê-las de volta online nesta sequência: réplica primária, réplicas secundárias síncronas, réplicas secundárias assíncronas.

6. Reparar ou substituir componentes avariados e revalidar o cluster. Agora que recuperou do desastre inicial e da falha do quórum, deve reparar ou substituir os nós avariados e ajustar as configurações relacionadas do WSFC e do Always On em conformidade. Isto pode incluir remover réplicas do grupo de disponibilidade, remover nós do cluster ou reformatar e reinstalar o software num nó.

   Deve reparar ou remover todas as réplicas de disponibilidade falhadas. O SQL Server não trunca o registo de transações para 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 registos de transações irão aumentar e corre o risco de esgotar o espaço do registo de transações nas outras réplicas.

   Note

   Se executar o Assistente Validar uma Configuração do WSFC quando existir um detetor de grupo de disponibilidade no cluster do WSFC, o assistente gera a seguinte mensagem de aviso incorreta:

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

   Por favor, ignore esta mensagem.

7. Repita o passo 4 conforme necessário. O objetivo é restabelecer o nível adequado de tolerância a falhas e alta disponibilidade para operações saudáveis.

8. Realizar uma análise RPO/RTO. Deve analisar os registos do sistema do SQL Server, os carimbos temporais da base de dados e os registos de eventos do Windows para determinar a causa principal da falha e para documentar os valores reais observados do ponto de recuperação e do tempo de recuperação.

Tarefas relacionadas

• Forçar um Cluster WSFC a Iniciar Sem Quórum

• Executar um Failover Manual Forçado de um Grupo de Disponibilidade (SQL Server)

• Exibir configurações de peso do nó do quórum do cluster

• Configurar definições de Peso do Nodo do Quórum do Cluster

• Usar o painel Always On (SQL Server Management Studio)

Conteúdo relacionado

• Ver eventos e logs de um cluster de failover

• Get-ClusterLog Cmdlet de Cluster de Failover

Ver também

Windows Server Failover Clustering (WSFC) com SQL Server