Como o Redis Cluster lida com falhas de nó

Comunicação de cluster e detecção de falhas

Os nós do cluster Redis se comunicam através de um protocolo binário baseado em TCP dedicado chamado barramento de cluster Redis. Cada nó mantém conexões com todos os outros nó no cluster usando este barramento, permitindo verificações contínuas de saúde e propagação do estado. Os nós enviam periodicamente pacotes de ping para confirmar o status operacional de seus colegas e compartilhar informações sobre o estado do cluster. Esta comunicação usa um protocolo de fofoca para disseminar com eficiência informações de cluster, ajudando na detecção de falhas de nó.

Os nós monitoram os colegas usando um mecanismo de ping ativo. Se um nó não responder a Pings dentro de um período de tempo limite configurado (Node_timeout), ele será sinalizado como possivelmente falhando com um status PFAIL. Esta é uma indicação de falha provisória, o que significa que o nó pode ser inacessível ou abaixo, mas ainda não está confirmado. Se a condição do PFAIL persistir e for confirmada pela maioria dos nós mestres, o nó é marcado como falha, indicando que é considerado inacessível ou abaixo pelo cluster. Esse mecanismo de detecção de falhas baseado em consenso ajuda a evitar falsos positivos na identificação de nós com falha.

manuseio de falhas de nó mestre

Quando um nó mestre é sinalizado como falha, o Redis Cluster inicia um processo de failover para promover uma de suas réplicas para se tornar o novo mestre. Esse processo é acionado automaticamente pelo detector de falha do cluster sem intervenção administrativa. A réplica promovida assume a responsabilidade de servir os slots de hash anteriormente gerenciados pelo mestre fracassado, garantindo que o cluster continue atendendo a solicitações sem reconfiguração manual.

O failover ocorre apenas se houver pelo menos uma réplica disponível e acessível para promover. Se não houver réplica adequada, o cluster entrará em um estado de erro em que parará de aceitar consultas para evitar a servir dados inconsistentes. Isso destaca a importância de ter réplicas configuradas para cada mestre manter alta disponibilidade.

mecânica e segurança de failover

Durante o failover, a réplica aguarda para sincronizar completamente com o mestre que está substituindo, garantindo que processou todas as atualizações pendentes para evitar a perda de dados. Ele alcança isso combinando o deslocamento da replicação com o mestre, por isso possui um conjunto de dados atualizado antes de assumir a função mestre.

Uma vez sincronizado, a réplica solicita uma nova época de configuração da maioria dos mestres. A época é um registro de data e hora lógico usado para rastrear alterações na configuração no cluster. Depois de obter consenso, a réplica transmite a configuração atualizada para todos os nós, anunciando sua promoção ao Master e o rebaixamento do antigo mestre para réplica ou remoção.

O antigo mestre, quando se recupera, recebe essa atualização de configuração e para de cumprir as consultas como mestre. Ele redireciona solicitações do cliente para o novo mestre, garantindo que os clientes continuem interagindo de forma transparente com o cluster sem intervenção manual.

lidando partições de rede e cenários de cérebro dividido

O Redis Cluster usa consenso baseado em maioria para evitar problemas de cérebro dividido durante partições de rede. Um mestre só falhará se for inacessível por mais da metade dos mestres no cluster. Os mestres que não podem se comunicar com a maioria pararão de aceitar gravações, impedindo estados de dados divergentes entre partições.

No entanto, se uma partição minoritária contiver clientes que continuam escrevendo para um mestre antes do failover, há um potencial de perda de gravação. Redis mitiga esse risco recusando gravações no lado da minoria após um tempo limite e no lado majoritário, falhando rapidamente sobre o mestre inacessível.

Apesar dessas precauções, as gravações podem ser perdidas durante as janelas de failover porque o Redis usa replicação assíncrona entre mestres e réplicas. Como as respostas para gravar comandos e atualizações de replicação são enviadas quase simultaneamente, a janela para perder as gravações é muito estreita, mas não impossível.

Opções de configuração que afetam o manuseio de falhas

O cluster Redis inclui opções de configuração que influenciam a disponibilidade e o comportamento durante as falhas dos nó:

-`Coberta de repercussão de cluster-requisito` (padrão sim): o cluster para de aceitar grava se alguma parte do espaço principal for descoberta devido a falhas de nó, garantindo forte consistência de dados.
-`Cluster-arel-reads-when-down` (padrão não): controla se as leituras são permitidas quando o cluster está em um estado de falha. Habilitar isso permite leituras de nós, mesmo durante falhas parciais, mas pode arriscar dados obsoletos que estão sendo atendidos.

Essas configurações permitem que os administradores equilibrem a disponibilidade e a consistência com base nos requisitos de aplicativos.

suporte de failover manual

Além do failover automático, o Redis Cluster fornece um comando de failover manual que pode ser emitido nos nós de réplicas. Isso é útil para cenários de manutenção ou teste em que um administrador deseja trocar as funções mestras sem esperar por um evento de falha real.

O failover manual funciona bloqueando os clientes no mestre atual, aguardando a réplica para recuperar o atraso completamente e depois promover a réplica com uma transição atômica suave. Isso não garante perda de dados durante a mudança de função e interrupção mínima para os clientes.

Resumo

O Redis Cluster lida com falhas no nó principalmente por meio de um sistema de detecção e failover de falhas com base no monitoramento contínuo através do barramento de cluster Redis e um protocolo de fofoca. Os nós detectam mestres inacessíveis e promovem réplicas automaticamente após um processo de consenso exigindo que a maioria dos mestres concorde com a falha. O failover foi projetado para minimizar a perda de dados, garantindo que as réplicas sejam totalmente sincronizadas antes da promoção. As partições de rede são gerenciadas por meio de decisões majoritárias para evitar condições de cérebro dividido, embora uma janela estreita de perda de gravação possa ocorrer devido à replicação assíncrona. As opções de configuração permitem o ajuste da disponibilidade versus consistência durante falhas, e os comandos de failover manual dão aos operadores controle para manutenção.