Redis: O padrão da indústria

Persistência e recuperação de dados

Conheça RDB, AOF, snapshots, recuperação após falhas e estratégias de backup.

Intermediário 45 min 32 pontos Leitura 0%

Nesta aula você vai

  • Diferenciar RDB e AOF e quando combinar ambos
  • Configurar políticas de fsync e avaliar impacto em durabilidade versus throughput
  • Planejar procedimentos de backup, restore e recuperação após falha

Persistência e recuperação de dados

Objetivos

Nesta aula você vai:

  • Compreender os dois mecanismos nativos de persistência do Redis: RDB e AOF
  • Calibrar trade-offs entre perda de dados aceitável e performance de escrita
  • Executar backup e restore com segurança em ambientes de produção

Introdução

Redis é in-memory, mas não precisa ser efêmero. Milhões de deploys dependem de recuperação após restart — seja reboot do SO, deploy de versão ou falha de hardware. Sem persistência configurada, o dataset some e a aplicação reconstrói cache a partir do banco (cache-aside) ou perde dados que só existiam no Redis (sessões, filas, contadores não replicados).

Persistência no Redis é configurável e negociável. Não existe configuração "perfeita" — existe alinhamento com RPO (Recovery Point Objective) e RTO (Recovery Time Objective) do negócio.

Conteúdo

RDB — snapshots point-in-time

O Redis periodicamente serializa o dataset completo em arquivo dump.rdb (fork + copy-on-write).

Configuração típica em redis.conf:

save 900 1      # 1 alteração em 15 min
save 300 10     # 10 alterações em 5 min
save 60 10000   # 10000 alterações em 1 min
Vantagem RDB Desvantagem RDB
Arquivo compacto, restore rápido Perda de dados desde último snapshot
Impacto de I/O concentrado no fork Fork pode ser custoso em datasets enormes
Bom para backups frios Não loga cada write individualmente

Disparo manual:

redis-cli BGSAVE
redis-cli LASTSAVE

AOF — Append Only File

Cada comando de escrita é appendado a um log. No restart, o Redis replay o log para reconstruir estado.

Modos appendfsync:

Modo Comportamento Durabilidade Performance
no SO decide quando flush Mais fraca Mais rápida
everysec fsync a cada segundo Perda ≤ ~1s Bom equilíbrio (padrão)
always fsync a cada write Mais forte Muito mais lenta 
appendonly yes
appendfsync everysec

AOF rewrite compacta o log em snapshot de comandos equivalentes — evita arquivo infinito:

redis-cli BGREWRITEAOF

RDB + AOF juntos

Prática comum em produção:

  • AOF com everysec para RPO de ~1 segundo
  • RDB periódico para backup portátil e restore mais rápido que replay de AOF gigante

No restart, Redis prioriza AOF se ambos existirem (AOF geralmente mais completo se everysec).

Recuperação e cenários de falha

Restart limpo: Redis carrega AOF ou RDB automaticamente.

AOF corrompido: redis-check-aof --fix ou restore de backup.

Réplica como backup quente: REPLICAOF mantém cópia; promoção via Sentinel/Cluster coberta na próxima aula.

Não confundir persistência local com backup off-site: copie dump.rdb / appendonly.aof para S3 ou storage imutável com periodicidade e teste de restore.

Impacto na arquitetura de aplicação

Dados que podem ser reconstruídos (cache puro) podem rodar sem persistência — simplifica operação.

Dados autoritativos no Redis (sessão longa, fila sem DLQ externa, locks) exigem AOF ou replicação com failover testado.

Sempre documente: "Se Redis perder últimos 60 segundos, o que quebra?"

Exemplos práticos

Verificar persistência ativa:

redis-cli CONFIG GET save
redis-cli CONFIG GET appendonly
redis-cli CONFIG GET appendfsync
redis-cli INFO persistence

Campos úteis em INFO persistence: aof_enabled, rdb_last_save_time, aof_last_rewrite_time_sec.

Teste controlado em ambiente de desenvolvimento:

SET persist-test "valor-importante"
CONFIG SET appendonly yes
CONFIG SET appendfsync everysec

# Simular restart do container/processo
# Após subir novamente:
GET persist-test

Backup manual antes de upgrade:

redis-cli BGSAVE
# Aguardar conclusão
redis-cli LASTSAVE
cp /var/lib/redis/dump.rdb /backup/dump-$(date +%F).rdb

Restore: pare Redis, substitua dump.rdb, inicie Redis — nunca sobrescreva AOF/RDB com instância rodando.

Resumo

  • RDB = snapshots compactos; AOF = log de writes com RPO configurável.
  • appendfsync everysec é o padrão sensato para maioria dos casos; always só com justificativa forte.
  • Combine RDB + AOF para backup e recuperação balanceados; teste restore regularmente.
  • Cache reconstructível pode omitir persistência; estado crítico não.
  • Persistência interage com memória (fork COW) — monitore latência durante BGSAVE em datasets grandes.