Partilhar via

Failover do grupo de disponibilidade Always On no Linux

Aplica-se a:SQL Server em Linux

No contexto de um grupo de disponibilidade (AG), a função principal e a função secundária das réplicas de disponibilidade são normalmente intercambiáveis, em um processo conhecido como failover. Existem três formas de failover: failover automático (sem perda de dados), failover manual planejado (sem perda de dados) e failover manual forçado (com possível perda de dados), normalmente chamado de failover forçado . Failovers automáticos e manuais planejados preservam todos os seus dados. Um AG faz failover no nível de réplica de disponibilidade. Ou seja, um AG faz failover para uma de suas réplicas secundárias (o destino de failover atual).

Para obter informações básicas sobre failover, consulte Failover e Modos de Failover (Grupos de Disponibilidade Always On).

Failover manual

Use as ferramentas de gestão de clusters para realizar o failover de um Grupo de Disponibilidade gerido por um gestor de cluster externo. Por exemplo, se uma solução usa o Pacemaker para gerenciar um cluster Linux, use pcs para executar failovers manuais no Red Hat Enterprise Linux (RHEL) ou no Ubuntu. No ambiente do SUSE Linux Enterprise Server (SLES), utilize crm.

Importante

Em operações normais, não faça failover com ferramentas de gerenciamento do Transact-SQL ou do SQL Server, como SSMS ou PowerShell. Quando CLUSTER_TYPE = EXTERNAL, o único valor aceitável para FAILOVER_MODE é EXTERNAL. Com essas configurações, todas as ações de failover manuais ou automáticas são executadas pelo gerenciador de cluster externo. Para obter instruções sobre como forçar o failover com perda potencial de dados, consulte Force failover.

Etapas manuais de comutação

Para fazer failover, a réplica secundária que se tornará a réplica primária deve ser síncrona. Se uma réplica secundária for assíncrona, altere o modo de disponibilidade.

Faça failover manualmente em duas etapas.

  1. Primeiro, faça failover manualmente, movendo o recurso AG do nó do cluster atual para um novo nó.

    O cluster falha no recurso AG e adiciona uma restrição de localização. Essa restrição configura o recurso para ser executado no novo nó. Remova essa restrição para fazer failover com êxito no futuro.

  2. Em segundo lugar, retirar a restrição de localização.

Passo 1. Fazer falha manual movendo o recurso do grupo de disponibilidade

Para fazer failover manualmente de um recurso AG chamado ag_cluster para o nó do cluster chamado nodeName2, execute o comando apropriado para a sua distribuição.

  • Exemplo RHEL/Ubuntu

    sudo pcs resource move ag_cluster-master nodeName2 --master --lifetime=30S

  • exemplo de SLES

    crm resource migrate ag_cluster nodeName2 --lifetime=30S

Quando você usa a opção --lifetime, a restrição de local criada para mover o recurso é temporária por natureza e é válida por 30 segundos no exemplo anterior.

A restrição temporária não é eliminada automaticamente e pode aparecer na lista de restrições, mas como uma restrição expirada. As restrições expiradas não afetam o comportamento de failover do cluster de marcapasso. Se você não usar a opção --lifetime ao mover o recurso, deverá remover uma restrição de local adicionada automaticamente, que é observada na seção a seguir.

Passo 2. Remover a restrição de local

Durante um failover manual, o comando pcsmove ou o comando crmmigrate adiciona uma restrição de localização para colocar o recurso no novo nó de destino. Para ver a nova restrição, execute o seguinte comando depois de mover manualmente o recurso:

  • Exemplo RHEL/Ubuntu

    sudo pcs constraint list --full

  • exemplo de SLES

    crm config show

    Este é um exemplo da restrição, que é criada devido a um failover manual.

    Enabled on: Node1 (score:INFINITY) (role: Master) (id:cli-prefer-ag_cluster-master)

    Observação

    O nome do recurso AG nos clusters Pacemaker no Red Hat Enterprise Linux 8.x e Ubuntu 18.04 pode assemelhar-se a ag_cluster-clone à medida que a nomenclatura em relação aos recursos tem evoluído para usar clone promovível.

  • Exemplo RHEL/Ubuntu

    No comando a seguir, cli-prefer-ag_cluster-master é a ID da restrição que precisa ser removida. sudo pcs constraint list --full retorna este ID.

    sudo pcs resource clear ag_cluster-master

    Ou

    sudo pcs constraint remove cli-prefer-ag_cluster-master

    Como alternativa, você pode executar a movimentação e a limpeza de restrições geradas automaticamente em uma única linha da seguinte maneira. O exemplo a seguir usa a terminologia clone de acordo com o Red Hat Enterprise Linux 8.x.

    sudo pcs resource move ag_cluster-clone --master nodeName2 && sleep 30 && sudo pcs resource clear ag_cluster-clone

  • exemplo de SLES

    No comando a seguir, cli-prefer-ms-ag_cluster é a ID da restrição. crm config show retorna este ID.

    crm configure
delete cli-prefer-ms-ag_cluster
commit

Observação

O failover automático não adiciona uma restrição de local, portanto, nenhuma limpeza é necessária.

Para mais informações:

Forçar transição automática

Um failover forçado destina-se estritamente à recuperação após desastres. Nesse caso, não é possível fazer failover com as ferramentas de gerenciamento de cluster porque o datacenter principal está inativo. Se forçar o failover para uma réplica secundária não sincronizada, é possível alguma perda de dados. Só force o failover se precisar restaurar o serviço para o AG imediatamente e estiver disposto a correr o risco de perder dados.

Se não for possível usar as ferramentas de gerenciamento de cluster para interagir com o cluster (por exemplo, se o cluster não responder devido a um evento de desastre no data center principal), talvez seja necessário forçar o failover para ignorar o gerenciador de cluster externo. Este procedimento não é recomendado para operações regulares porque corre o risco de perda de dados. Use-o quando as ferramentas de gerenciamento de cluster não executarem a ação de failover. Funcionalmente, esse procedimento é semelhante ao executar um de failover manual forçado em um AG no Windows.

Esse processo para forçar o failover é específico do SQL Server no Linux.

  1. Verifique se o cluster não gerencia mais o recurso AG.

    • Configure o recurso para modo não gerido no nó do cluster de destino. Este comando sinaliza ao agente de recursos para interromper o monitoramento e o gerenciamento de recursos. Por exemplo:

      sudo pcs resource unmanage <resourceName>

    • Se a tentativa de definir o modo de recurso para o modo não gerenciado falhar, exclua o recurso. Por exemplo:

      sudo pcs resource delete <resourceName>

      Observação

      Quando você exclui um recurso, ele também exclui todas as restrições associadas.

  2. Na instância do SQL Server que hospeda a réplica secundária, defina a variável de contexto de sessão external_cluster.

    EXECUTE sp_set_session_context
    @key = N'external_cluster',
    @value = N'yes';

  3. Realize o failover do AG com o Transact-SQL. No exemplo a seguir, substitua <MyAg> pelo nome do seu AG. Conecte-se à instância do SQL Server que hospeda a réplica secundária de destino e execute o seguinte comando:

    ALTER AVAILABILITY GROUP <MyAg> FORCE_FAILOVER_ALLOW_DATA_LOSS;

  4. Após um failover forçado, coloque o AG em um estado saudável antes de reiniciar a monitorização e a gestão de recursos do cluster ou recriar o recurso AG. Revise as tarefas essenciais após um failover forçado.

  5. Reinicie o monitoramento e o gerenciamento de recursos de cluster:

    Para reiniciar o monitoramento e o gerenciamento de recursos de cluster, execute o seguinte comando:

    sudo pcs resource manage <resourceName>
sudo pcs resource cleanup <resourceName>

    Se você excluiu o recurso de cluster, recrie-o. Para recriar o recurso de cluster, siga as instruções em Criar recurso de grupo de disponibilidade.

Importante

Não use as etapas anteriores para exercícios de recuperação de desastres, pois eles correm o risco de perda de dados. Em vez disso, altere a réplica assíncrona para síncrona e execute as instruções para falha manual normal.

Monitoramento no nível do banco de dados e gatilho de failover

Para CLUSTER_TYPE=EXTERNAL, a semântica do gatilho de failover difere da do WSFC. Quando o AG está em uma instância do SQL Server em um WSFC, a saída do estado ONLINE para o banco de dados faz com que a saúde do AG indique uma falha. Em resposta, o gerenciador de cluster dispara uma ação de failover. No Linux, a instância do SQL Server não pode se comunicar com o cluster. O monitoramento da integridade do banco de dados é feito externo. Se o utilizador optou pelo monitoramento e failover no nível de banco de dados (definindo a opção DB_FAILOVER=ON ao criar o AG), o cluster verificará se o estado do banco de dados está ONLINE toda vez que executa uma ação de monitoramento. O cluster consulta o estado em sys.databases. Para qualquer estado diferente de ONLINE, o sistema desencadeia automaticamente um failover (se forem cumpridas as condições para failover automático). O tempo real do failover depende da frequência da ação de monitoramento e do estado do banco de dados que está sendo atualizado em sys.databases.

O failover automático requer pelo menos uma réplica síncrona.

Conteúdo relacionado

Contribuir para a documentação SQL

Você sabia que você mesmo pode editar conteúdo SQL? Se o fizer, não só ajudará a melhorar a nossa documentação, como também será creditado como contribuidor da página.

Para obter mais informações, consulte Editar a documentação do Microsoft Learn.

  • Last updated on