Melhores Práticas para Prevenir Perda de Dados: Configuração RDB vs. AOF

A persistência do Redis é fácil de entender errado porque o Redis parece um banco de dados, mas se comporta primeiro como memória. Se você reiniciá-lo sem persistência, os dados desaparecem. Se a persistência estiver ativada, mas ajustada descuidadamente, você ainda pode perder gravações recentes, travar clientes durante pressão de disco ou descobrir durante uma interrupção que a única cópia dos seus dados está no mesmo volume com falha que o processo Redis.

A estratégia correta de perda de dados do Redis começa com uma pergunta honesta: o que acontece se os últimos segundos, minutos ou horas de gravações desaparecerem? Um cache de páginas de produto geralmente pode ser reconstruído. Um armazenamento de sessão pode irritar os usuários, mas não destruir o negócio. Uma fila, um registro de limite de taxa, um carrinho de compras ou um armazenamento de flags de funcionalidade podem precisar de durabilidade muito mais rigorosa. RDB e AOF são as duas ferramentas que o Redis oferece, e elas resolvem diferentes partes desse problema.

Compreendendo os Mecanismos de Persistência do Redis

O Redis tem dois modos principais de persistência:

Snapshots RDB

O RDB grava um snapshot pontual do conjunto de dados no disco, geralmente como dump.rdb. O Redis bifurca um processo filho, o filho serializa o conjunto de dados e o pai continua atendendo clientes. Isso torna o RDB útil para backups, réplicas e reinicializações rápidas, mas tem uma desvantagem clara: qualquer coisa gravada após o último snapshot bem-sucedido pode ser perdida se o processo ou host falhar.

As configurações típicas do RDB são assim:

save 900 1       # Salvar após 15 minutos se pelo menos 1 chave mudou
save 300 10      # Salvar após 5 minutos se pelo menos 10 chaves mudaram
save 60 10000    # Salvar após 1 minuto se pelo menos 10000 chaves mudaram
dbfilename dump.rdb
dir /var/lib/redis

Essas linhas save não são uma promessa de que o Redis salvará exatamente nesse cronograma. Elas são regras de gatilho: se chaves suficientes mudaram durante o intervalo, o Redis inicia um salvamento em segundo plano. Se o disco for lento, o conjunto de dados for enorme ou o host estiver com pouca memória, o salvamento em segundo plano pode falhar ou criar latência através da bifurcação e pressão de copy-on-write.

O RDB é mais forte quando você quer snapshots compactos e comportamento de restauração rápida. É mais fraco quando sua tolerância para perda de dados recentes é baixa.

Log AOF

AOF, ou persistência de arquivo somente anexado, registra comandos de gravação para que o Redis possa reproduzi-los na reinicialização. Geralmente oferece melhor durabilidade que o RDB porque pode liberar gravações com mais frequência do que um cronograma de snapshot. A desvantagem é mais E/S de disco, arquivos maiores antes da reescrita e, às vezes, inicialização mais lenta se o Redis tiver que reproduzir um log grande.

As configurações principais são:

appendonly yes
appendfilename "appendonly.aof"
appendfsync everysec
aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb
aof-rewrite-incremental-fsync yes

A linha importante é appendfsync. Com everysec, o Redis pede ao sistema operacional para liberar o AOF aproximadamente uma vez por segundo. Em uma falha normal do processo Redis, isso geralmente limita a perda a cerca do último segundo de gravações. Em uma falha completa do host ou de armazenamento, a perda exata depende do SO, sistema de arquivos, cache de disco e comportamento do armazenamento, então não descreva como uma garantia matemática.

appendfsync always libera após cada gravação e é muito mais caro. Pode ser apropriado para uma implantação Redis pequena e crítica com volume de gravação modesto, mas pode prejudicar a latência gravemente sob tráfego real. appendfsync no deixa o SO decidir quando liberar; é rápido, mas oferece uma janela de perda muito maior e menos previsível.

Melhores Práticas para Prevenção de Perda de Dados

Use ambos apenas quando você entender qual arquivo o Redis carregará

Muitas implantações Redis de produção ativam tanto RDB quanto AOF. Esse é um padrão sensato quando o Redis armazena dados que seriam dolorosos de reconstruir. RDB fornece artefatos de backup compactos. AOF fornece uma janela de perda recente menor.

Use configuração como esta:

save 900 1
save 300 10
save 60 10000
appendonly yes
appendfsync everysec

Um detalhe importante durante a restauração: quando o AOF está ativado, o Redis normalmente carrega os dados do AOF na inicialização porque espera-se que sejam mais completos que o snapshot RDB. Não presuma que o Redis carregará o RDB primeiro e depois recorrerá ao AOF. Teste o caminho de restauração para sua versão do Redis e layout de implantação, especialmente em versões do Redis que usam o formato AOF de múltiplas partes mais novo.

Escolha appendfsync a partir da janela de perda para trás

Comece com o impacto no negócio, não com a configuração do Redis.

Se o Redis é um cache descartável, apenas RDB pode ser suficiente, ou até mesmo nenhuma persistência se sua aplicação repovoar com segurança. Se o Redis contém sessões, appendfsync everysec é frequentemente um equilíbrio prático. Se o Redis faz parte de um fluxo de trabalho onde perder gravações reconhecidas cria danos reais ao negócio, a persistência do Redis sozinha pode não ser o limite de durabilidade correto. Você pode precisar de um banco de dados primário, uma fila durável ou comportamento de write-ahead no nível da aplicação fora do Redis.

Para a maioria dos usos operacionais do Redis, comece com:

appendonly yes
appendfsync everysec

Depois observe latência, tempo de gravação em disco, comportamento de reescrita AOF e tempo de reinicialização antes de decidir se mover em direção a always ou se afastar do AOF.

Mantenha snapshots RDB, mas não os torne muito agressivos

Salvamentos RDB frequentes reduzem a quantidade de dados perdidos entre snapshots, mas também aumentam a frequência de bifurcação. Bifurcar um processo Redis grande pode ser caro, e gravações durante o salvamento filho criam pressão de memória copy-on-write. Se sua instância Redis tem um conjunto de dados de 40 GB e a taxa de gravação é alta, salvar a cada minuto pode criar pior confiabilidade porque o host gasta muito tempo sob pressão de memória e disco.

Regras de salvamento RDB razoáveis dependem da taxa de gravação e expectativas de recuperação. Um cache pequeno pode fazer snapshots frequentemente sem problemas. Um armazenamento de sessão grande pode precisar de menos snapshots RDB mais AOF para durabilidade recente. Observe INFO persistence, logs do Redis e memória do host durante BGSAVE, não apenas o arquivo de configuração do Redis.

Trate a reescrita AOF como manutenção normal, não uma emergência

Arquivos AOF crescem porque registram gravações. O Redis os reescreve em uma representação compacta em segundo plano. Os padrões são frequentemente um ponto de partida decente:

aof-auto-rewrite-percentage 100
aof-auto-rewrite-min-size 64mb

Isso significa que o Redis considera reescrever quando o AOF cresceu significativamente em comparação com o tamanho após a reescrita anterior, uma vez que atinja o tamanho mínimo. Se as reescritas acontecem constantemente, aumente o tamanho mínimo ou investigue um padrão de gravação ruidoso. Se o AOF cresce por muito tempo sem reescrever, verifique logs, espaço em disco e INFO persistence.

Você pode acionar uma reescrita manualmente:

redis-cli BGREWRITEAOF

Faça isso durante um período tranquilo, se possível. Uma reescrita é mais segura do que deixar o arquivo crescer para sempre, mas ainda consome CPU, largura de banda de disco e memória copy-on-write.

Faça backup dos arquivos de persistência em outro lugar

Persistência não é um backup. Arquivos de persistência no mesmo host protegem você de uma reinicialização do processo Redis. Eles não protegem você de um disco perdido, exclusão acidental, uma implantação ruim que sobrescreve o diretório de dados ou um erro do operador que executa FLUSHALL.

Copie arquivos RDB e AOF para armazenamento separado. Se você usar snapshots de sistema de arquivos ou snapshots de volume em nuvem, teste a restauração em uma instância separada. Para cópias RDB, prefira copiar um arquivo de snapshot completo em vez de um arquivo sendo gravado. Para AOF, entenda o layout do arquivo para sua versão do Redis antes de construir scripts de backup em torno de nomes de arquivos.

Observe os sinais que preveem perda de dados

O comando útil durante um incidente é:

redis-cli INFO persistence

Procure por salvamentos em segundo plano com falha, status de reescrita AOF, hora do último salvamento e indicadores de fsync atrasado. Combine isso com métricas do host: latência de disco, espaço livre em disco, espaço de memória disponível e eventos OOM do kernel. Se BGSAVE falha por horas e ninguém percebe, a configuração do Redis pode parecer segura enquanto o ponto de recuperação real fica cada vez mais antigo.

Use replicação ou Sentinel para disponibilidade, não como seu único backup

Réplicas, Redis Sentinel e Redis Cluster ajudam com disponibilidade. Eles não resolvem automaticamente todos os problemas de perda de dados. Uma gravação ruim, exclusão acidental ou bug de aplicação podem se replicar rapidamente. A failover também pode promover uma réplica que está perdendo gravações recentes se existir lag de replicação. Mantenha persistência, backups e testes de restauração no design.

A configuração prática para muitas equipes é AOF com appendfsync everysec, snapshots RDB em um ritmo razoável, backups externos, monitoramento de falhas de persistência e um runbook de restauração testado. O Redis pode ser confiável nessa forma, mas apenas se você tratar a persistência como um sistema operacional em vez de uma caixa de seleção.