Persistência RDB (Redis Database)

A persistência RDB, ou Redis Database, é um método que captura instantâneos (snapshots) do conjunto de dados do Redis em um determinado intervalo de tempo e os grava em disco. É uma forma de salvar o estado atual do banco de dados em um arquivo binário, que pode ser carregado de volta na memória para restaurar os dados em caso de reinício ou falha.

O Redis utiliza um processo de fork para criar um processo filho dedicado à tarefa de persistência. Esse processo filho é responsável por escrever uma cópia completa dos dados em um arquivo temporário no disco. Uma vez que a gravação é concluída com sucesso, o arquivo temporário substitui atomicamente o arquivo RDB previamente salvo. Durante todo esse processo, o processo principal do Redis não realiza operações de I/O de disco, garantindo assim um alto desempenho e mantendo a responsividade aos clientes. A abordagem RDB é particularmente eficiente para grandes volumes de dados e cenários onde a tolerância a alguma perda de dados recente é aceitável, pois os dados da última persistência até uma eventual falha podem ser perdidos. Por padrão, o Redis vem configurado para usar RDB, e o arquivo gerado é tipicamente nomeado dump.rdb.

Configuração e Acionamento do RDB

A configuração padrão para a persistência RDB é definida no arquivo redis.conf. Um exemplo de diretiva de savlamento é:

save 60 5

Esta linha instrui o Redis a gerar um instantâneo se pelo menos 5 modificações de chaves ocorrerem em um período de 60 segundos. É importante notar que o salvamento não ocorre imediatamente após atingir o número de operações, mas sim após o tempo especificado ter decorrido e as condições serem satisfeitas.

O salvamento de instantâneos RDB pode ser acionado de diversas maneiras:

• SAVE: Este comando força o Redis a realizar um salvamento síncrono. O processo principal é bloqueado durante a operação de I/O, tornando o servidor indisponível para outros clientes até que o salvamento seja concluído. É desaconselhável para ambientes de produção com grandes volumes de dados.
• BGSAVE: Uma alternativa assíncrona, este comando instrui o Redis a criar um processo filho para executar o salvamento. O processo principal permanece ativo e continua a responder às requisições do cliente. Após a execução, o comando retorna OK imediatamente. É o método preferencial para operações de persistência em ambientes de produção. O comando LASTSAVE pode ser usado para verificar o horário da última persistência bem-sucedida.
• FLUSHALL / FLUSHDB: Embora não sejam comandos de persistência diretos, esvaziar todas as bases de dados ou uma base de dados específica pode, dependendo da configuração do RDB (se houver diretivas save configuradas), levar à criação de um novo arquivo dump.rdb que representa o estado vazio do banco de dados.
• SHUTDOWN: Ao desligar o servidor Redis de forma controlada, um salvamento RDB é executado automaticamente antes do encerramento, garantindo que o estado mais recente seja persistido (se o RDB estiver habilitado).

É crucial notar que um encerramento abrupto do processo Redis (como um kill -9) impedirá a criação de qualquer instantâneo RDB, resultando em perda de dados não salvos.

Impacto da Operação fork

A operação fork, embora geralmente rápida, pode gerar um breve bloqueio no processo principal se a memória utilizada pelo Redis for muito grande, pois o sistema operacional precisa copiar a tabela de páginas do processo pai para o filho. Isso pode impactar temporariamente a latência das requisições, mesmo com BGSAVE.

Restaurando Dados RDB

Para restaurar dados a partir de um arquivo RDB:

1. Garanta que o serviço Redis esteja completamente parado.
2. Copie o arquivo dump.rdb (ou o nome do seu arquivo RDB) para o diretório configurado pelo parâmetro dir no redis.conf (geralmente /var/lib/redis ou o diretório de execução do Redis).
3. Inicie o serviço Redis. O Redis detectará e carregará automaticamente o arquivo RDB ao iniciar, reconstruindo o estado do banco de dados.

Persistência AOF (Append Only File)

A persistência AOF (Append Only File) registra cada operação de escrita que modifica os dados no Redis. Diferente do RDB que salva instantâneos binários, o AOF é um arquivo de log textual que contém uma sequência de comandos Redis. No momento da inicialização, o Redis lê este arquivo e reexecuta todos os comandos nele contidos, restaurando o estado do banco de dados. Operações de leitura não são registradas no AOF. Por padrão, a persistência AOF vem desativada e precisa ser explicitamente habilitada no arquivo de configuração do Redis. O arquivo gerado é normalmente nomeado appendonly.aof.

Reparo de Arquivos AOF

Em caso de corrupção do arquivo AOF, a ferramenta redis-check-aof pode ser utilizada para tentar repará-lo:

redis-check-aof --fix appendonly.aof

Essa ferramenta tenta remover entradas malformadas do arquivo, o que pode resultar na perda de dados relacionados a essas entradas. Recomenda-se cautela e, se possível, comparar o arquivo reparado com uma cópia original (se disponível) usando ferramentas como diff -u para entender as alterações.

Gerenciamento de Arquivos AOF

Se o arquivo appendonly.aof for excluído enquanto o Redis está em execução, o servidor continuará operando e, por manter um descritor de arquivo aberto, continuará escrevendo no inode do arquivo excluído até ser reiniciado. Contudo, um novo arquivo não será automaticamente criado, e o log de operações não será efetivamente persistido após a exclusão lógica do arquivo. Para resolver isso, é necessário reiniciar o serviço Redis para que ele crie um novo arquivo AOF ou executar o comando BGREWRITEAOF.

Reescrita do Arquivo AOF

Com o tempo, o arquivo AOF pode crescer excessivamente devido a comandos redundantes ou operações sobrepostas. Para otimizar o tamanho e a eficiência do arquivo AOF, o Redis oferece a funcionalidade de reescrita do AOF, acionada pelo comando BGREWRITEAOF. Este processo funciona da seguinte forma:

1. Um processo filho é criado (via fork), similar ao RDB.
2. Este processo filho lê o estado atual da memória do Redis e gera uma sequência mínima de comandos para recriar esse estado. Por exemplo, múltiplas operações INCR em uma chave podem ser substituídas por um único SET com o valor final.
3. Os novos comandos são escritos em um arquivo AOF temporário.
4. Enquanto isso, o processo principal continua registrando novas operações em um buffer de reescrita.
5. Quando o processo filho termina de escrever o arquivo temporário, o Redis anexa o conteúdo do buffer de reescrita a esse novo arquivo.
6. Finalmente, o novo arquivo AOF temporário substitui o arquivo AOF original de forma atômica, resultando em um arquivo menor e mais eficiente.

É importante ressaltar que a reescrita do AOF não lê o arquivo AOF existente, mas sim reconstrói o log a partir do estado atual dos dados em memória.