Replicação e alta disponibilidade

Objetivos

Nesta aula você vai:

• Configurar e operar replicação master-replica no Redis
• Implementar failover automático com Redis Sentinel
• Planejar topologias de HA adequadas a diferentes SLAs

Conteúdo

A cópia que salva a narrativa

Toda história precisa de backup — uma segunda edição guardada para quando a primeira se perde. Em sistemas de cache e banco em memória, a replicação é esse mecanismo: manter cópias dos dados em múltiplos nós para que a falha de um não interrompa o serviço.

Mas replicação não é fotocópia instantânea. É um processo contínuo, com lag, trade-offs de consistência e decisões sobre quem lidera quando o mestre cai.

Replicação master-replica

No modelo clássico do Redis, um nó master aceita escritas e replicas recebem cópias assíncronas:

┌──────────┐  replicação async   ┌──────────┐
│  Master  │ ──────────────────► │ Replica 1│
│ (writes) │ ──────────────────► │ Replica 2│
└──────────┘                     └──────────┘
     ▲                                ▲
     │ writes                         │ reads
     └──────── Aplicação ─────────────┘

Configuração básica

# No master (redis-master.conf)
bind 0.0.0.0
port 6379
requirepass senha-segura

# Na replica (redis-replica.conf)
bind 0.0.0.0
port 6380
replicaof redis-master 6379
masterauth senha-segura
replica-read-only yes

# Verificar status de replicação
redis-cli -h redis-master INFO replication
# role:master
# connected_slaves:2

redis-cli -h redis-replica INFO replication
# role:slave
# master_link_status:up
# slave_repl_offset:1234567

Métricas de replicação

# Calcular lag de replicação
redis-cli INFO replication | grep offset
# master_repl_offset:1000000
# slave_repl_offset:999500
# Lag: 500 bytes (~poucos comandos)

Replicação síncrona parcial: WAIT

Por padrão, replicação é assíncrona — o master confirma a escrita antes da replica receber. Para garantir durabilidade mínima:

# Após SET, esperar confirmação de pelo menos 1 replica em até 1000ms
redis-cli SET pedido:1001 "confirmado"
redis-cli WAIT 1 1000
# Retorna número de replicas que confirmaram (0 = timeout)

Redis Sentinel: failover automático

Sentinel monitora masters e promove replicas automaticamente quando o master falha:

┌─────────────┐  ┌─────────────┐  ┌─────────────┐
│ Sentinel 1  │  │ Sentinel 2  │  │ Sentinel 3  │
│ (monitor)   │  │ (monitor)   │  │ (monitor)   │
└──────┬──────┘  └──────┬──────┘  └──────┬──────┘
       │                │                │
       └────────────────┼────────────────┘
                        │ quorum (2/3)
              ┌─────────┴─────────┐
              │     Master        │
              │   (monitorado)    │
              └─────────┬─────────┘
                        │ replicação
              ┌─────────┴─────────┐
              │    Replica        │
              │  (candidata)      │
              └───────────────────┘

Configuração Sentinel

# sentinel.conf
port 26379
sentinel monitor mymaster redis-master 6379 2
sentinel auth-pass mymaster senha-segura
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1

# Verificar estado via Sentinel
redis-cli -p 26379 SENTINEL master mymaster
redis-cli -p 26379 SENTINEL replicas mymaster
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymaster

Fluxo de failover

1. Master para de responder (crash, rede, OOM)
2. Sentinels detectam (down-after-milliseconds)
3. Quorum confirma (2 de 3 sentinels concordam)
4. Sentinel líder elege nova master (replica mais atualizada)
5. Replica promovida: REPLICAOF NO ONE
6. Outras replicas reconfiguradas para novo master
7. Clientes notificados (via Sentinel ou DNS)

Tempo típico de failover: 10–30 segundos (configurável).

Topologias de alta disponibilidade

Leitura em replicas: eventual consistency

# Cliente direciona leituras para replica
# ATENÇÃO: dados podem estar desatualizados (replication lag)

# Verificar lag antes de leitura crítica
redis-cli -h replica INFO replication | grep offset

Split-brain e prevenção

Split-brain ocorre quando dois nós acreditam ser master simultaneamente:

Master A (isolado) ←→ [rede partida] ←→ Master B (promovido)
  Aceita escritas                            Aceita escritas
  → Dados divergentes quando rede restaura

Prevenção:

• Quorum ímpar de Sentinels (3 ou 5)
• min-replicas-to-write no master — recusa escritas se replicas insuficientes
• min-replicas-max-lag — recusa escritas se lag excessivo

# Master recusa escritas se < 1 replica sincronizada nos últimos 10s
redis-cli CONFIG SET min-replicas-to-write 1
redis-cli CONFIG SET min-replicas-max-lag 10

Checklist de HA em produção

1. Mínimo 1 replica + 3 Sentinels para failover automático
2. Monitorar master_link_status e replication lag
3. Configurar min-replicas-to-write para prevenir split-brain
4. Testar failover regularmente (game day)
5. Clientes devem usar Sentinel-aware drivers (não IP fixo do master)
6. Documentar RTO (tempo de recuperação) e RPO (dados perdidos aceitáveis)

Resumo

• Replicação master-replica protege contra falha de hardware; Sentinel automatiza failover
• Replicação padrão é assíncrona — use WAIT para durabilidade parcial
• Leitura em replicas é eventual — direcione leituras críticas ao master
• Quorum ímpar de Sentinels + min-replicas-to-write previne split-brain

Para refletir

Seu Redis em produção tem Sentinel configurado? Quando foi a última vez que você testou um failover controlado?