Guia do Redis Sentinel: Alta Disponibilidade e Failover Automático

23 de março de 2026

12 min de leitura

Recente

TL;DR — Resumo Rápido

Implante o Redis Sentinel para failover automático e alta disponibilidade. Configure quorum, topologia master-réplica, clientes e segurança em produção.

O Redis Sentinel é a solução de alta disponibilidade integrada ao Redis, oferecendo failover automático, monitoramento de topologia e descoberta de serviços sem a complexidade do Redis Cluster. Este guia cobre a arquitetura completa, uma implantação de três nós pronta para produção, a configuração de clientes compatíveis com Sentinel, os conceitos de quorum e os controles de segurança necessários antes de ir para produção.

Pré-requisitos

Três servidores Linux (físicos ou virtuais) com conectividade entre si nas portas 6379 (Redis) e 26379 (Sentinel).
Redis 7.0 ou superior instalado em todos os nós.
Acesso root ou sudo em cada servidor.
Familiaridade básica com arquivos de configuração do Redis e redis-cli.

Arquitetura do Sentinel

O Redis Sentinel é executado como um processo separado junto às instâncias do Redis. Cada Sentinel desempenha quatro funções:

Monitoramento: Verifica a integridade do master e das réplicas a cada segundo usando PING/INFO.
Notificação: Publica alertas nos canais +switch-master, +slave e outros via pub/sub.
Failover automático: Ao atingir o quorum, o Sentinel elege um líder, promove a melhor réplica e reconfigura as demais.
Provedor de configuração: Os clientes consultam o Sentinel com SENTINEL get-master-addr-by-name para descobrir o endereço atual do master.

Por Que Três Sentinels?

Um único Sentinel é um ponto único de falha. Com dois Sentinels pode ocorrer um empate na votação. Três Sentinels com quorum 2 garantem:

Um Sentinel pode falhar e o failover ainda funciona.
Dois Sentinels quaisquer podem concordar em promover um novo master.
A minoria não pode acionar uma promoção que cause split-brain.

Sempre implante um número ímpar de Sentinels (3, 5 ou 7).

Passo 1 — Configurar o Master do Redis

No Servidor 1 (192.168.1.101), edite /etc/redis/redis.conf:

bind 0.0.0.0
port 6379
protected-mode no

requirepass "SenhaFortaRedis123"
masterauth "SenhaFortaRedis123"

# Persistência (AOF recomendado para implantações com Sentinel)
appendonly yes
appendfsync everysec

# Proteção split-brain: rejeita escritas se nenhuma réplica sincronizou nos últimos 10s
min-replicas-to-write 1
min-replicas-max-lag 10

Inicie e habilite o Redis:

sudo systemctl start redis-server
sudo systemctl enable redis-server

Passo 2 — Configurar as Réplicas do Redis

No Servidor 2 (192.168.1.102) e no Servidor 3 (192.168.1.103), edite /etc/redis/redis.conf:

bind 0.0.0.0
port 6379
protected-mode no

requirepass "SenhaFortaRedis123"
masterauth "SenhaFortaRedis123"

# Apontar para o master inicial
replicaof 192.168.1.101 6379

# Réplicas recusam comandos de escrita de clientes (padrão seguro)
replica-read-only yes

# Persistência
appendonly yes
appendfsync everysec

# Prioridade de promoção da réplica (menor = preferida; 0 = nunca promover)
replica-priority 100

Verifique a replicação a partir do master:

redis-cli -a "SenhaFortaRedis123" INFO replication

Você deve ver role:master e duas entradas slave com state:online.

Passo 3 — Configurar o Redis Sentinel

Crie /etc/redis/sentinel.conf nos três servidores:

port 26379
daemonize yes
logfile "/var/log/redis/sentinel.log"
dir /var/lib/redis

# Monitorar o master chamado "mymaster" com quorum 2
sentinel monitor mymaster 192.168.1.101 6379 2

# Senha para autenticação com o master (e réplicas após o failover)
sentinel auth-pass mymaster SenhaFortaRedis123

# Marcar o master como SDOWN após 5 segundos sem resposta
sentinel down-after-milliseconds mymaster 5000

# Tempo máximo para o processo completo de failover (ms)
sentinel failover-timeout mymaster 60000

# Apenas uma réplica sincroniza do novo master de cada vez
sentinel parallel-syncs mymaster 1

Inicie o Sentinel nos três servidores:

sudo redis-sentinel /etc/redis/sentinel.conf

Verifique a descoberta de topologia:

redis-cli -p 26379 SENTINEL masters
redis-cli -p 26379 SENTINEL replicas mymaster
redis-cli -p 26379 SENTINEL sentinels mymaster
redis-cli -p 26379 SENTINEL ckquorum mymaster

O Processo de Failover Passo a Passo

SDOWN (Subjetivamente Inativo): Um Sentinel para de receber PONG do master dentro do down-after-milliseconds e o marca como SDOWN.
ODOWN (Objetivamente Inativo): O Sentinel transmite SENTINEL is-master-down-by-addr para seus pares. Quando o número de quorum responde afirmativamente, o estado passa para ODOWN.
Eleição de líder: Os Sentinels que concordam sobre o ODOWN votam em um líder usando o algoritmo semelhante ao Raft integrado ao Sentinel.
Seleção de réplica: O líder classifica as réplicas por: tempo de desconexão do master → replica-priority (menor vence) → offset de replicação (mais dados vence) → run ID lexicográfico.
Promoção: O líder envia REPLICAOF NO ONE para a réplica escolhida, tornando-a o novo master.
Reconfiguração: As demais réplicas recebem REPLICAOF <novo-ip-master> 6379. Os Sentinels atualizam seus arquivos sentinel.conf. Os clientes que consultarem o Sentinel receberão o novo endereço do master.

Todo o processo normalmente é concluído em 10–30 segundos com as configurações padrão.

Conexão de Clientes Através do Sentinel

Nunca codifique o IP do master Redis diretamente na sua aplicação. Use um cliente compatível com Sentinel que consulte o Sentinel para obter o master atual.

Python (redis-py)

from redis.sentinel import Sentinel

sentinel = Sentinel(
    [
        ("192.168.1.101", 26379),
        ("192.168.1.102", 26379),
        ("192.168.1.103", 26379),
    ],
    socket_timeout=0.5,
    password="SenhaFortaRedis123",
)

master = sentinel.master_for("mymaster", socket_timeout=0.5)
replica = sentinel.slave_for("mymaster", socket_timeout=0.5)

master.set("sessao:abc", "dados-usuario")
valor = replica.get("sessao:abc")

Node.js (ioredis)

const Redis = require("ioredis");

const redis = new Redis({
  sentinels: [
    { host: "192.168.1.101", port: 26379 },
    { host: "192.168.1.102", port: 26379 },
    { host: "192.168.1.103", port: 26379 },
  ],
  name: "mymaster",
  password: "SenhaFortaRedis123",
  sentinelPassword: "SenhaFortaRedis123",
});

await redis.set("chave", "valor");

Segurança em Produção

Proteger o Sentinel

Adicione requirepass ao Sentinel para que apenas clientes autorizados possam emitir comandos Sentinel:

requirepass "SenhaAdminSentinel"
sentinel sentinel-pass SenhaAdminSentinel

Habilitar TLS

O Redis 6.0+ suporta TLS para conexões Redis e Sentinel:

tls-port 26380
port 0
tls-cert-file /etc/redis/tls/sentinel.crt
tls-key-file /etc/redis/tls/sentinel.key
tls-ca-cert-file /etc/redis/tls/ca.crt
tls-replication yes

Usar ACLs (Redis 6.0+)

# Em redis.conf
aclfile /etc/redis/users.acl

# users.acl
user default off
user sentinel on >SentinelPass ~* &* +@all
user app on >AppPass ~sessao:* ~cache:* +GET +SET +DEL +EXPIRE

Comparação: Sentinel vs Alternativas

Recurso	Sentinel	Redis Cluster	KeyDB	Dragonfly	Redis Gerenciado
Failover automático	Sim	Sim	Sim	Sim	Sim
Fragmentação de dados	Não	Sim	Sim	Não	Varia
Complexidade de configuração	Média	Alta	Baixa	Baixa	Nenhuma
Requisito de cliente	Compatível Sentinel	Compatível Cluster	Padrão	Padrão	Padrão
Tamanho máximo do dataset	RAM de um nó	RAM × shards	RAM de um nó	RAM de um nó	Limitado pelo plano
Custo	Gratuito	Gratuito	Gratuito	Gratuito	$$/mês
Ideal para	HA sem fragmentação	Datasets grandes	HA drop-in do Redis	Alto throughput	Sem gerenciamento de infra

Problemas Comuns e Advertências

O Sentinel reescreve seu arquivo de configuração. Nunca edite sentinel.conf manualmente enquanto o Sentinel estiver em execução — o Sentinel atualiza continuamente o arquivo com a topologia descoberta.

DNS vs endereços IP. O Sentinel armazena endereços de master e réplica por IP no momento da descoberta. Se você mudar o IP de um servidor, o Sentinel não seguirá as mudanças de DNS.

Leituras obsoletas durante o failover. Nos 10–30 segundos entre a falha do master e a promoção da réplica, as leituras podem retornar dados desatualizados. Projete a aplicação para tolerar leituras brevemente obsoletas.

requirepass sem masterauth. Se você definir requirepass no master mas esquecer masterauth nas réplicas, a autenticação de replicação falha e as réplicas se desconectam silenciosamente.

Resumo

O Redis Sentinel fornece monitoramento, failover automático e descoberta de serviços para Redis sem exigir Cluster.
Implante pelo menos 3 instâncias Sentinel em hosts separados; defina quorum como 2 para uma configuração de 3 nós.
A sequência de failover avança de SDOWN → ODOWN → eleição de líder → promoção de réplica → reconfiguração.
Use min-replicas-to-write e min-replicas-max-lag no master para evitar a perda de dados por split-brain.
Sempre use um cliente compatível com Sentinel — nunca codifique o IP do master diretamente.
Proteja o Sentinel com requirepass, ACLs e TLS em ambientes de produção.

Guide & Instructions

Estimated Time: 30m

Tools Needed:

Redis
Redis Sentinel
systemctl

Instalar o Redis nos três nós

Instale o Redis 7.0 ou superior no servidor master e nos dois servidores réplica. Certifique-se de que as portas 6379 e 26379 estejam abertas entre todos os nós nas regras do firewall.

Configurar o master do Redis

Edite /etc/redis/redis.conf no nó master. Defina bind como 0.0.0.0, requirepass, masterauth e opções de persistência. Adicione min-replicas-to-write 1 e min-replicas-max-lag 10 para proteger contra split-brain.

Configurar as réplicas do Redis

Em cada nó réplica, edite redis.conf para adicionar a diretiva replicaof apontando para o IP e porta do master. Configure replica-read-only yes e use os mesmos valores de requirepass e masterauth do master.

Criar e implantar sentinel.conf em cada nó

Crie /etc/redis/sentinel.conf em cada um dos três servidores com sentinel monitor mymaster apontando para o master, quorum 2, down-after-milliseconds 5000, failover-timeout 60000 e sentinel auth-pass com a senha do master.

Iniciar o Sentinel e verificar a descoberta de topologia

Inicie o Redis Sentinel com 'sudo redis-sentinel /etc/redis/sentinel.conf' em todos os nós. Execute 'redis-cli -p 26379 SENTINEL masters' para confirmar que os três Sentinels veem o mesmo master e se descobriram mutuamente.

Testar o failover automático e atualizar os clientes

Pare o processo master do Redis e observe os logs do Sentinel. Confirme que uma réplica é promovida em segundos. Atualize a aplicação para usar um cliente compatível com Sentinel apontando para os três endereços do Sentinel.

Frequently Asked Questions

Como o Redis Sentinel detecta uma falha no master?

Cada Sentinel envia ping ao master a cada segundo. Se nenhuma resposta chegar dentro de down-after-milliseconds, esse Sentinel marca o master como SDOWN. Quando o quorum de Sentinels concorda, o estado passa para ODOWN e o failover é iniciado.

Qual é o número mínimo de instâncias Sentinel necessárias?

São necessárias pelo menos 3 instâncias com quorum de 2. Um número ímpar evita empates na eleição de líder, e perder um Sentinel ainda deixa instâncias suficientes para atingir o quorum e acionar o failover com segurança.

O Redis Sentinel atua como proxy para conexões de clientes?

Não. O Sentinel é apenas uma camada de descoberta de serviços. Os clientes consultam o Sentinel para encontrar o endereço do master atual e depois se conectam diretamente ao Redis. É obrigatório usar uma biblioteca cliente compatível com Sentinel.

Como evitar a perda de dados por split-brain no Redis Sentinel?

Configure min-replicas-to-write e min-replicas-max-lag no master. O master rejeitará comandos de escrita se menos réplicas do que o exigido confirmarem os dados recentemente, evitando que um master isolado aceite escritas que serão perdidas após o failover.