Preparação de Ambiente

Inicie três máquinas virtuais em um ambiente físico isolado. A redee deve permitir comunicação entre elas sem restrições de firewall que bloqueiem portas Redis. A topologia de rede definida para este teste utiliza os seguintes endereços:

• Nó 1: 192.168.10.10
• Nó 2: 192.168.10.20
• Nó 3: 192.168.10.30

O sistema operacional utilizado é base CentOS (versão 6.8 ou superior) e o pacote Redis foi compilado a partir da versão 6.2.4 em todas as instâncias.

Configuração do Nó Primário (Master)

No nó de IP 192.168.10.10, edite o arquivo de configuração padrão do Redis (redis.conf). As seguintes diretrizes devem ser aplicadas para garantir funcionamento corretamente na rede local e em segundo plano:

daemonize yes
protected-mode no
port 6379
bind 192.168.10.10
loglevel notice
logfile /var/log/redis-data.log

Inicie o serviço e verifique o estado da replicação via linha de comando:

$ redis-cli -h 192.168.10.10 -p 6379
192.168.10.10:6379> info replication
# Replication
role:master # Identifica o nó como primário
connected_slaves:0
master_failover_state:no-failover
master_replid:f2816f8d2bae0165e69939f2c68c7893d404afd6

Configuração do Nó Secundário (Slave)

No segundo host (192.168.10.20), configure o Redis para atuar como réplica do primeiro nó. A modificação chave aqui é adicionar a diretiva apontando para o endereço do servidor mestre:

daemonize yes
protected-mode no
port 6379
bind 192.168.10.20
loglevel notice
logfile /var/log/redis-data.log
replicaof 192.168.10.10 6379

Após iniciar o serviço, verifique a conexão estabelecida:

$ redis-cli -h 192.168.10.20 -p 6379
192.168.10.20:6379> info replication
# Replication
role:slave # Identifica o nó como secundário
master_host:192.168.10.10
master_port:6379
master_link_status:up
slave_read_only:1

Retorne ao nó mestre para confirmar que a réplica está sincronizada:

192.168.10.10:6379> info replication
# Replication
role:master
connected_slaves:1 # Réplica detectada
slave0:ip=192.168.10.20,port=6379,state=online,offset=28,lag=1

Desdobramento dos Nódulos Sentinel

Crie arquivos de configuração específicos para o Sentinel em cada uma das três máquinas. Utilizando o nome lógico app-db-group para identificar o conjunto master/salve.

# Arquivo: sentinel.conf (em todos os nós, ajustando o bind)
port 26379
bind 192.168.10.10 # Altere o IP conforme o nó atual
daemonize yes
logfile /var/log/redis-sentinel.log
sentinel monitor app-db-group 192.168.10.10 6379 2

Para iniciar o processo do Sentinel, execute o executável do server com a flag dedicada:

$ ./src/redis-server sentinel.conf --sentinel

Ao iniciar o Sentinel no primeiro nó, os registros de log confirmarão a detecção automática dos outros componentes:

... # Sentinel ID is c31a742dd7b0485beff0463fcc0a15d17f31170b
+monitor master app-db-group 192.168.10.10 6379 quorum 2
* +slave slave 192.168.10.20:6379 192.168.10.20 6379 @ app-db-group 192.168.10.10 6379

Execute o mesmo comando nas demais estações (.20 e .30). Verifique novamente os logs da primeira máquina para observar a entrada dos novos participantes:

* +sentinel sentinel [ID] 192.168.10.20 26379 @ app-db-group 192.168.10.10 6379
* +sentinel sentinel [ID] 192.168.10.30 26379 @ app-db-group 192.168.10.10 6379

Teste a conectividade dos serviços sentinela:

$ redis-cli -h 192.168.10.10 -p 26379
192.168.10.10:26379> PING
PONG

Teste de Falha e Failover

Simule uma indisponibilidade no nó principal para validar a capacidade de failover. Verifique o endereço atual do mestre antes da interrupção:

$ redis-cli -h 192.168.10.10 -p 26379
(sentinel get-master-addr-by-name app-db-group)
1) "192.168.10.10"
2) "6379"

Embarra o nó mestre utilizando o comando interno do Redis para simular congelamento:

$ redis-cli -h 192.168.10.10 -p 6379 DEBUG sleep 120

Imediatamente após o comando ser emitido, interaja com o Sentinel para verificar se ele detetou a falha e promoveu a réplica:

$ redis-cli -h 192.168.10.10 -p 26379
(sentinel get-master-addr-by-name app-db-group)
1) "192.168.10.20"
2) "6379"

O novo endereço corresponde à máquina que era anteriormnete a réplica. Confirme essa mudança verificando o status de replicação direto no novo master:

$ redis-cli -h 192.168.10.20 -p 6379
info replication
role:master
connected_slaves:1
slave0:ip=192.168.10.10,port=6379,state=online # O antigo mestre agora é réplica

Os registros internos do Sentinel mostram a evolução completa do estado do cluster durante o evento:

+sdown master app-db-group 192.168.10.10 6379
+new-epoch 1
+vote-for-leader [ID] 1
+odown master app-db-group 192.168.10.10 6379
+switch-master app-db-group 192.168.10.10 6379 192.168.10.20 6379