Preparação da Infraestrutura para Sentinel

Para garantir a resiliência do banco de dados Redis, é fundamental estabelecer um ambiente que suporte a auto-recuperação. A configuração padrão envolve a interação entre nós de armazenamento (Master e Slaves) e os monitores responsáveis pela supervisão.

• Sistema Operacional: Distribuição Linux tipo RHEL/CentOS.
• Endereçamento IP: Rede privada isolada (ex: 172.168.x.x).
• Arquitetura de Rede: Gateway configurado corretamente para roteamento interno.
• Instâncias Sentinel: É recomendado executar três processos de monitoramento para quorum adequado (portas 26379 a 26381).
• Políticas de Persistência: Durante a fase de monitoramento, a persistência local do próprio processo Sentinel não é necessária.

A base deste cenário pressupõe uma topologia de replicação já ativa, composta por um nó primário e dois nós secundários distribuídos em máquinas virtuais distintas.

Em cenários reais de produção, evitar a concentração de todos os componentes em uma única máquina física mitiga riscos de ponto único de falha. Contudo, para fins demonstrativos de laboratório, podemos instanciar múltiplos serviços de monitoramento em uma estação central.

Parâmetros de Configuração Críticos

O comportamento do sistema é definido no arquivo de configuração (sentinel.conf). Existem duas abordagens principais para iniciar o daemon: utilizando o executável específico redis-sentinel ou invocando o binário padrão do servidor com a flag --sentinel. O estado atual do monitoramento é persistente via arquivos de configuração gerados automaticamente.

Os atributos abaixo são essenciais para definir a sensibilidade e segurança do cluster:

# Definição do alvo de monitoramento
# Nome lógico | IP Mestre | Porta | Quorum necessário para declarar falha
sentinel monitor db-principal 172.168.18.201 6379 2

# Tempo limite (ms) sem resposta antes de marcar como offline subjetivamente
sentinel down-after-milliseconds db-principal 60000

# Duração máxima permitida para conclusão de uma failover (ms)
sentinel failover-timeout db-principal 180000

# Quantidade paralela de slaves sincronizando com o novo mestre durante failover
# Valor baixo reduz carga momentânea no cluster
parallel-syncs db-principal 1

# Credencial de acesso ao servidor Redis alvo (se protegido)
sentinel auth-pass db-principal senha_complexa_123

Provisionamento dos Serviços Sentinel

Depender de um único processo de vigilância compromete a integridade do sistema. Caso esse processo caia, não haverá quem coordene a promoção de novos mestres. Para mitigar isso, iniciamos três instâncias independentes nas portas designadas.

Crie arquivos de configuração distintos na diretório de instalação do binário do banco de dados:

• monitord_26379.conf
• monitord_26380.conf
• monitord_26381.conf

O conteúdo básico varia apenas na porta de escuta e no caminho do log, mantendo as regras de monitoramento consistentes:

# Exemplo: monitord_26379.conf
protected-mode no
port 26379
daemonize yes
logfile "/var/log/redis/sentinel_26379.log"
pidfile "/var/run/sentinel_26379.pid"

# Diretivas de Controle
sentinel monitor db-principal 172.168.18.201 6379 2
sentinel auth-pass db-principal senha_complexa_123
sentinel down-after-milliseconds db-principal 30000
sentinel parallel-syncs db-principal 1
sentinel failover-timeout db-principal 180000

Execução e Verificação Inicial

Inicie os três processos manualmente utilizando o caminho absoluto do executável:

[root@sistema ~]# /usr/local/bin/redis-sentinel /etc/sentinel/monitord_26379.conf
[root@sistema ~]# /usr/local/bin/redis-sentinel /etc/sentinel/monitord_26380.conf
[root@sistema ~]# /usr/local/bin/redis-sentinel /etc/sentinel/monitord_26381.conf

Confirme a atividade verificando o uso da memória e processos ativos. Em seguida, utilize a ferramenta de linha de comando conectada a uma das portas de monitoramento para inspecionar o status atual:

172.168.18.200:26380> INFO sentinel
# Sentinel
sentinel_masters:1
sentinel_tilt:0
master0:name=db-principal,status=ok,address=172.168.18.201:6379,slaves=2,sentinels=3

Observe que o registro indica corretamente o endereço IP .201 como o líder atual.

Validação de Tolerância a Falhas

O objetivo final é assegurar que, diante de uma indisponibilidade inesperada do nó mestre, o tráfego seja redirecionado sem intervenção manual.

1. Verifique a integridade da replicação inicial através de uma escrita simples no mestre (.201) e leia nos seguidores (.200 e .203).
2. Simule a queda do servidor principal enviando o comando de desligamento ou interrompendo o processo via kill.

Ao realizar a ação de parada no nó original:

172.168.18.201:6379> SHUTDOWN NOSAVE
Não conectado>

Monitore o status do cluster novamente via cliente Sentinel. O sistema deve identificar automaticamente um novo líder entre os seguidores disponíveis.

172.168.18.200:26381> INFO sentinel
# Sentinel
...
master0:name=db-principal,status=ok,address=172.168.18.200:6379,slaves=2,sentinels=3

Note a mudança crítica: o endereço agora aponta para a porta .200. Isso confirma que um dos nós escravos foi promovido. Para validar funcionalidade completa de escrita:

172.168.18.200:6379> SET chave-teste valor_novo_leader
OK
172.168.18.203:6379> GET chave-teste
"valor_novo_leader"

A análise dos arquivos de log gerados pelos monitores fornecerá detalhes forenses sobre a tomada de decisão, incluindo o momento da detecção de queda (down), votação para liderança (vote-for-leader) e a atualização da configuração (config-update-from).

... # +sdown master db-principal 172.168.18.201 6379
... # +new-epoch 1
... # +vote-for-leader hash_identificador_processo
... # +switch-master db-principal 172.168.18.201 6379 172.168.18.200 6379
... # +slave slave 172.168.18.203:6379 172.168.18.203 6379 @ db-principal 172.168.18.200 6379