Saltar para o conteúdo 
O Redis Failover mantém os sistemas de alojamento em produção disponíveis em caso de falhas nos nós, transferindo automaticamente as funções primárias para instâncias réplicas e, assim, mantendo ativas as sessões, as caches e as filas. Para tal, pretendo Replicação, os processos de transição e monitorização, de modo a que as comutações ocorram de forma rápida, controlada e repetível.
Pontos centrais
Os pontos-chave que se seguem oferecem uma visão geral rápida do artigo.
- Replicação mais o Sentinel ou o Cluster para transferências automáticas
- Fragmentação para escalabilidade e tolerância a erros em grandes volumes de dados
- Quórum e os tempos de espera determinam a velocidade de comutação e a segurança
- RPO/RTO definir a perda de dados aceitável e o tempo de recuperação
- Monitorização e os testes revelam pontos fracos antes de uma situação de emergência
Por que razão o failover garante a disponibilidade
Sem uma lógica de comutação adequada, uma cache ou uma base de dados de sessão transforma-se rapidamente num estrangulamento em caso de falha; por isso, calculo Transferência em caso de falha como primeiro requisito. Defino antecipadamente qual é a perda de dados admissível (RPO) e com que rapidez os serviços têm de voltar a responder (RTO). O Redis replica de forma assíncrona, pelo que planeio tempos de buffer, mecanismos de proteção que limitam as gravações e um procedimento de escalonamento claro. As bibliotecas de cliente têm de compreender os mecanismos do Sentinel ou do cluster; caso contrário, a ligação é interrompida no momento errado. Tenho em conta a latência entre zonas, para que as decisões de quórum se mantenham seguras e os tempos de transição não se prolonguem excessivamente.
Primária única com sentinela: quando é suficiente
Para configurações compactas, recorro frequentemente a um nó primário e, pelo menos, a um nó réplica, monitorizados por três instâncias Sentinel, pois um número ímpar evita decisões instáveis no Quórum. Considero os Sentinels como guardiões independentes: detetam falhas, elegem um novo Primary por decisão maioritária e distribuem os novos pontos finais aos clientes. Para que estas decisões se mantenham fiáveis, coloco os processos em hosts ou zonas separadas. Certifico-me de que os clientes conhecem os pontos finais dos Sentinels e se reconectam utilizando uma estratégia de fallback. Quem quiser aprofundar o assunto encontrará detalhes práticos na Guia do Redis Sentinel, que explica de forma clara a configuração e os pontos mais complicados.
Cluster com sharding: escalabilidade e resiliência
Se a carga ou o volume de dados aumentarem, mudo para o Redis Cluster com sharding, uma vez que várias instâncias primárias dividem os espaços de chaves e, por cada shard, estão disponíveis uma ou mais réplicas; assim, a Disponibilidade mesmo em caso de perda de nós. Esta abordagem distribui os pontos de pico, desacopla a carga da memória e da CPU e, ao mesmo tempo, proporciona uma transição integrada por área de slot. Nesse contexto, planeio a atribuição de slots e o número de réplicas por fragmento de forma a cobrir as cargas de leitura e os requisitos de failover. O Google Cloud e o Redis.io recomendam, para este efeito, pelo menos uma réplica por fragmento; em ambientes de tráfego intenso, opto geralmente por duas. O encaminhamento do cliente é fundamental: apenas os controladores compatíveis com clusters reconhecem as migrações de slot sem interrupções.
Latência de failover, quórum e comportamento do cliente
A transição não pode ser nem demasiado rápida nem demasiado lenta, por isso procuro encontrar o equilíbrio Intervalos e os valores de quórum de forma deliberada. Se definir intervalos de tempo demasiado curtos, corre-se o risco de falhas de comutação em caso de perturbações momentâneas na rede; se os definir de forma demasiado generosa, os utilizadores notarão interrupções percetíveis. Verifico se os controladores processam corretamente os redirecionamentos (MOVED/ASK), a deteção de sentinelas e as atualizações de DNS. O Redis recomenda vários sentinelas e limiares conservadores, para que pequenas oscilações não provoquem mudanças de liderança. Em aplicações sensíveis à latência, testo mudanças bruscas de carga e perda de pacotes para medir os tempos de comutação reais e ajustar os backoffs dos clientes.
Gerir a perda de dados: RPO, AOF e repl-diskless
Como o Redis replica, de preferência de forma assíncrona, minimizo a perda potencial com RPO-Regras e persistência adequada. Com AOF (appendonly sim) e appendfsync everysec, guardo os estados em intervalos de segundos, enquanto os instantâneos RDB são gravados com menos frequência, mas de forma mais compacta. Em cargas de trabalho com grande intensidade de gravação, defino «min-replicas-to-write» e «min-replicas-max-lag», para que um primário só grave quando houver réplicas suficientes atualizadas. Avalio o «repl-diskless-sync» e um «repl-backlog-size» adequado, para que as reconexões ocorram de forma rápida e incremental. Antes do início do projeto, defino quais os dados que podem ser voláteis (reconstruíveis) e quais os que têm de ser protegidos por transações.
Cópia de segurança e reinício: o que estou a testar
O failover não substitui Cópias de segurança, por isso faço cópias de segurança regularmente e testo as recuperações a partir de artefactos reais. Pratico reinicializações: o primário é desligado, a réplica assume o controlo, o antigo primário regressa, a função é reatribuída corretamente e os clientes voltam a ligar-se sem intervenção manual. Para tal, documento manuais de procedimentos com comandos claros, vias de escalamento e critérios de interrupção. Durante as janelas de manutenção, simulo também a desconexão da rede para avaliar os riscos de «split-brain». Associo eventos de monitorização e métricas aos exercícios, para poder avaliar com precisão as linhas temporais e os pontos de estrangulamento.
Topologia e posicionamento: zonas, anfitriões, anti-afinidade
Coloco os nós de dados e os guardiões separadamente, para que um único Domínio de erros nunca ocorrem todos ao mesmo tempo. As diferentes zonas de disponibilidade reduzem o risco de que problemas de rede ou de energia paralisem várias funções ao mesmo tempo. As regras de anti-afinidade garantem que os primários e as suas réplicas não fiquem no mesmo anfitrião físico. Para prevenir o «split-brain», garanto maiorias de quórum e recuso acessos de gravação caso haja um número insuficiente de réplicas acessíveis. O artigo sobre consistência e sistemas de quórum reúne conhecimentos básicos sobre estes temas em Estratégias de cérebro dividido, que ilustra os processos de tomada de decisão.
Configuração: Interruptores importantes para a produção
Algumas opções do servidor afetam a segurança, a durabilidade dos dados e Latência É determinante, por isso defino padrões consoante a carga de trabalho. Para garantir a segurança na gravação, utilizo os parâmetros «min-replicas-to-write» e «min-replicas-max-lag», de acordo com o atraso de replicação. Para a persistência, opto por «AOF everysec» ou, em complemento, por instantâneos RDB com intervalos adequados. Para a estabilidade da rede, defino «tcp-keepalive» e valores de tempo limite realistas; no cluster, ajusto «cluster-node-timeout» de acordo com a latência da zona. A tabela seguinte apresenta os parâmetros típicos e a minha recomendação resumida.
| Parâmetros | Objetivo/Recomendação |
|---|---|
| somente adição / appendfsync | Ativar AOF; everysec para um equilíbrio entre a durabilidade e a influência da carga de escrita |
| mínimo de réplicas a escrever | Escreve apenas quando houver X réplicas; protege contra perdas de dados em caso de falhas de rede |
| min-replicas-max-lag | Atraso máximo de replicação em segundos; evita réplicas desatualizadas |
| tamanho-da-filha-de-respostas | Espaço de reserva suficiente para ressincronizações incrementais; dimensão calculada em função da taxa de gravação |
| repl-diskless-sync | Sincronização inicial mais rápida sem ficheiros temporários, desde que haja largura de banda de rede suficiente |
| tcp-keepalive | Detecção mais precoce de ligações inativas; ajustar o valor à rede e às firewalls |
| tempo limite / tempo-de-espera-do-nó-do-cluster | Vincular as janelas de comutação e de deteção à latência e ao orçamento de erros |
| limite do buffer de saída do cliente | Limitar os clientes com congestionamento; protege o servidor principal e as réplicas da sobrecarga de armazenamento |
Sentinel vs. Cluster: Guia de decisão
Decido entre o Sentinel e o Cluster com base no volume de dados, no débito, no perfil de leitura/gravação e nos requisitos necessários Tolerância a falhas. Se não precisar de escalabilidade horizontal do espaço de chaves, o Sentinel oferece uma solução simplificada com um primário e réplicas. Se eu precisar de vários primários, distribuição de slots e encaminhamento automático, opto por um cluster. Planeio as migrações de um sistema autónomo para um cluster com antecedência, para que o hash das chaves e a atribuição de slots não causem surpresas durante o funcionamento. O artigo apresenta uma comparação prática Cluster vs. Autônomo, que explica os pontos fortes e as limitações de ambas as abordagens.
Análise prática: Monitorização e alarmes
Acompanho os indicadores que apontam diretamente para falhas, atrasos ou sobrecarga de memória, pois a monitorização é determinante para Tempo de resposta. Entre estes contam-se o estado da replicação, o atraso (lag), a utilização do backlog, o número de resyncs completos, as interrupções de ligação, as evicções e os bloqueios causados por comandos lentos. Os Sentinels e os gestores de cluster têm de comunicar corretamente os eventos de heartbeat e de eleição, para que eu possa compreender as decisões tomadas. Ao nível da aplicação, registo códigos de erro do Redis e a latência P95/P99 para detetar precocemente problemas dos clientes. Aciono alarmes antes que os utilizadores se apercebam de algo: por exemplo, em caso de ultrapassagem dos limiares de repl-lag, diminuição do número de réplicas acessíveis ou aumento acentuado dos redirecionamentos «MOVED».
Manutenção durante o funcionamento: atualizações contínuas e transições planeadas
Executo as tarefas programáveis de forma a que os utilizadores, na medida do possível, não reparem em nada. Antes de uma atualização, verifico o estado da replicação, o nível do backlog e a atividade atual do AOF/RDB. Em configurações do Sentinel, se necessário, inicio uma transição controlada, faço com que os clientes mudem de servidor e, em seguida, atualizo o nó que ficou sem carga. No cluster, utilizo uma gracioso A transição é feita por shard, para que nenhum slot fique sem atribuição. Programo as reescritas AOF que causam bloqueios ou as tarefas de armazenamento em segundo plano mais demoradas para fora das janelas de transição, a fim de evitar picos de latência desnecessários. É importante definir um rollback: se um nó não conseguir participar corretamente após a atualização, reverto a alteração antes de passar para o próximo nó.
Para implementações sem tempo de inatividade, desativo os nós de aplicação gradualmente, esvazio os conjuntos de ligações, defino tempos de repetição curtos e jitter e verifico se, após a migração, não permanecem caminhos de gravação no antigo primário. Em ambientes particularmente sensíveis, aumento temporariamente o buffer de replicação antes da migração e defino tempos de espera mais conservadores, para evitar falhas de comutação durante o período de manutenção.
Funcionamento em contentores e Kubernetes
A orquestração de contentores simplifica as implementações, mas exige um cuidado adicional. Recorro a StatefulSets para garantir identidades estáveis, guardo os metadados do cluster e os ficheiros AOF/RDB em volumes fiáveis e defino a anti-afinidade, para que os primários e as réplicas não fiquem no mesmo nó. Calibro as sondas de prontidão (Readiness) e de atividade (Liveness) de forma a que os congestionamentos momentâneos não conduzam imediatamente a reinícios e, consequentemente, não desencadeiem failovers em cascata. Os PodDisruptionBudgets e a terminação ordenada, com um período de tolerância suficiente, impedem que, durante os trabalhos de manutenção, se percam maiorias indesejadas.
Para os Sentinels e a comunicação em cluster, planeio serviços «headless» e nomes de anfitrião estáveis; verifico se, em caso de alterações de IP, os ficheiros de configuração se mantêm atualizados e não sobrescrevem visões antigas do cluster após um reinício. As políticas de rede limitam as portas necessárias ao mínimo, para que os canais de controlo não fiquem expostos na rede overlay. Em configurações com várias zonas, impedo a preempção para os nós líderes e garanto capacidade suficiente para que, em caso de falha de um nó, haja espaço para novas instalações.
Segurança e fortalecimento: ACL, TLS e isolamento
A disponibilidade sem segurança é enganadora. Ativo a autenticação e trabalho com ACLs do Redis em vez de palavras-passe globais, concedo apenas os direitos de que uma função necessita e separo os acessos de manutenção dos acessos às aplicações. Protejo a comunicação com nós de dados, ligações de replicação e serviços de vigilância através de TLS; a rotação de certificados e políticas de encriptação claras fazem parte da rotina de manutenção. O modo protegido, endereços de ligação restritivos e firewalls/políticas de rede impedem que redes não autorizadas obtenham acesso. Nas topologias Sentinel, utilizo credenciais de início de sessão dedicadas para os guardiões, para que permaneçam estáveis mesmo em caso de alterações de palavra-passe. Os limites de taxa e os limites para o buffer do cliente protegem contra abusos e picos de carga involuntários.
Consistência na aplicação: padrões e armadilhas
Decido, consoante o caso de utilização, qual a consistência necessária. Para garantir uma durabilidade mais rigorosa, a aplicação pode aguardar confirmações das réplicas após operações de gravação críticas, aceitando, em troca, ligeiros aumentos de latência. Marco deliberadamente os acessos de leitura às réplicas como possivelmente coerente e utilizo-as apenas onde a obsolescência é tolerável. As transações com WATCH/MULTI/EXEC e os scripts Lua são executados de forma atómica no servidor primário; por isso, concebo os comandos de forma idempotente, para que uma nova tentativa do cliente após um failover não gere efeitos secundários duplicados. Atribuo aos operações de bloqueio (por exemplo, em listas ou fluxos) tempos de espera e recuos adequados, para que, em caso de comutação, nenhum thread fique bloqueado indefinidamente. Para filas e fluxos de eventos, planeio pelo menos uma vez-Semântica e desduplicação no lado do utilizador, em vez de uma exatamente uma vez-criar ilusões.
Modelo de dados, pressão de armazenamento e conceção de chaves
Um failover robusto começa no modelo de dados. Evito chaves excessivamente grandes e estruturas monolíticas, que provocam tempos de replicação ou AOF prolongados, e divido-as em segmentos mais fáceis de gerir. Defino os TTL de forma consistente, para que as caches voltem rapidamente ao estado ativo após uma comutação, sem provocar efeitos em cadeia. A escolha da política de evicção e um valor realista para maxmemory impedem que picos de carga desencadeiem ondas repentinas de eliminação. Acompanho de perto a fragmentação da memória e as reescritas em segundo plano; quando os recursos são escassos, dou prioridade a mecanismos que garantam latências determináveis, mesmo que o pico de débito diminua ligeiramente. Em clusters, planeio janelas de resharding e equilibro ativamente os slots, para que os pontos de congestão nem sequer surjam.
Aprofundar a observabilidade: registos, rastreios, SLOs
Para além das métricas, utilizo registos e eventos como linha do tempo: quando é que um nó foi marcado como inativo, quando é que decorreu a eleição, quando é que o novo primário ficou pronto para gravações? Agrego registos do slowlog, avalio anomalias com um Latency Doctor e correlaciono-as com métricas do sistema, como I/O-Wait, CPU-Steal ou perdas de rede. Para o serviço, defino SLOs (por exemplo, latência P99 e minutos de inatividade anuais) e verifico ativamente se as transições se mantêm dentro do orçamento de erros. As verificações sintéticas realizadas a partir do exterior do domínio do cluster detetam problemas de DNS ou de firewall que as verificações de integridade internas não detectam.
Procedimentos de teste e exercícios de simulação de situações de caos
Não me limito a testar apenas os «Happy Paths». O programa obrigatório inclui partições de rede, arranques a frio sob pressão, falhas de zonas inteiras, backlogs sobrecarregados, nós de replicação com camada de armazenamento lenta ou com erros e desvios de hora. Documento as reações esperadas e os valores reais das medições e comparo-os com o RPO/RTO. Realizo exercícios de caos em pequena escala e vou aumentando a complexidade e a duração até que as equipas e os sistemas à semelhança da memória muscular reagir. As conclusões são incorporadas nos manuais de intervenção, nos limiares de alarme e nas configurações padrão; só assim os testes se tornam uma demonstração prática de resiliência e não meros eventos pontuais.
Custos, orçamento e planeamento de capacidades
A resiliência tem um custo – sob a forma de nós, zonas e persistência adicionais. Quantifico o custo por réplica adicional e por zona contornada e comparo-o com o valor de um RTO/RPO mais curto. A persistência com sincronizações AOF frequentes aumenta a durabilidade, mas eleva os custos de E/S e a latência; procuro o ponto em que as necessidades dos utilizadores e o orçamento se equilibram. Não escolho os tamanhos do backlog, a largura de banda da rede para a sincronização «repl-diskless» e as classes de armazenamento com base na intuição, mas sim com base em taxas de gravação medidas e tempos de ressincronização. Assim, o planeamento da capacidade torna-se um seguro com uma apólice clara, em vez de uma reserva de segurança motivada pelo medo.
Resumindo: é assim que planeio o failover do Redis
Começo com uma clara Objectivos: RPO, RTO, carga prevista, número de zonas e orçamento. As configurações de pequena a média dimensão recebem um Primary, pelo menos uma réplica e três Sentinels em hosts separados; nas plataformas de maior dimensão, utilizo um cluster com várias réplicas por shard. Faço cópias de segurança dos dados com AOF ou instantâneos complementares e realizo recuperações regularmente. Ajusto a topologia, o quórum e os tempos de espera de acordo com a latência da rede e o orçamento de erros, e escolho controladores de cliente com capacidade de failover. Desta forma, o Redis mantém-se robusto, rápido e, acima de tudo, fiável no dia-a-dia da produção.
