Afirmar
Este artigo foi publicado pela primeira vez na minha conta pública: Yizhihua não é considerado romântico ; se reimprimido, indique a fonte!
Amigos interessados podem seguir o número público pessoal: Yizhihua não é considerado romântico
22.jpg
Prefácio
O Redis é um banco de dados NO SQL baseado em memória, mas todos sabemos os dados armazenados na memória.Enquanto o servidor estiver desligado, os dados na memória desaparecerão.
Para evitar a perda de dados na memória, o Redis fornece suporte para persistência. O Redis possui dois mecanismos de persistência: RDB e AOF.
Você pode primeiro examinar os princípios de dois mecanismos de persistência:
RDB e AOF.jpg em 01_Redis
Introdução aos dois mecanismos de persistência de RDB e AOF
Mecanismo de persistência RDB, executa persistência periódica nos dados em redis
O mecanismo AOF usa cada comando de gravação como um log e o grava em um arquivo de log no modo somente acréscimo.Quando o redis reinicia, todo o conjunto de dados pode ser reconstruído, repetindo as instruções de gravação no log da AOF
Se você usar os mecanismos de persistência RDB e AOF, quando o redis reiniciar, o AOF será usado para reconstruir os dados, porque os dados no AOF são mais completos
Vantagens do mecanismo de persistência RDB
-
O RDB é muito adequado para backup a frio. Você pode enviar esse arquivo de dados completo para algum armazenamento remoto seguro, como um servidor em nuvem.
-
O RDB tem muito pouco impacto nos serviços de leitura e gravação fornecidos pelo redis, o que pode manter o alto desempenho do redis, porque o processo principal do redis precisa apenas bifurcar um processo filho e permitir que o processo filho execute operações de E / S de disco para persistência do RDB
-
Comparado com o mecanismo de persistência AOF, é mais rápido reiniciar e restaurar o processo redis diretamente com base nos arquivos de dados RDB
Desvantagens do mecanismo de persistência do RDB
- Se você deseja perder o mínimo de dados possível quando o redis falhar, o RDB não será tão bom quanto o AOF. De um modo geral, os arquivos de captura instantânea de dados RDB são gerados a cada 5 minutos ou mais; nesse momento, você deve aceitar que, quando o processo de redis estiver desativado, os dados dos últimos 5 minutos serão perdidos.
- Sempre que o RDB executa a geração do arquivo de dados de captura instantânea do RDB no subprocesso fork, se o arquivo de dados for particularmente grande, poderá causar a suspensão do serviço fornecido pelo cliente por milissegundos ou mesmo segundos.
Vantagens do mecanismo de persistência AOF
- O AOF pode proteger melhor os dados contra perda.Em geral, o AOF executará uma operação fsync através de um encadeamento em segundo plano a cada 1 segundo e perderá até 1 segundo de dados.
- Os arquivos de log AOF são gravados no modo somente acréscimo, portanto, não há sobrecarga no endereçamento de disco, o desempenho de gravação é muito alto e o arquivo não é facilmente danificado, mesmo se o final do arquivo estiver danificado, é fácil reparar
- Mesmo que o arquivo de log AOF seja muito grande, a operação de reescrita em segundo plano não afetará a leitura e gravação do cliente. Porque, ao reescrever o log, as instruções nele serão compactadas para criar um log mínimo que precise ser restaurado. Ao criar um novo arquivo de log, o antigo arquivo de log é gravado como de costume. Quando o arquivo de log após a nova mesclagem estiver pronto, troque o arquivo de log antigo
- Os comandos do arquivo de log AOF são gravados de uma maneira muito legível, esse recurso é muito adequado para recuperação de emergência de exclusão acidental catastrófica. Por exemplo, se você usar acidentalmente o comando flushall para limpar todos os dados, desde que a reescrita em segundo plano não tenha ocorrido no momento, copie imediatamente o arquivo AOF, exclua o último comando flushall e, em seguida, coloque o arquivo AOF de volta, poderá passar o mecanismo de recuperação, Restaurar automaticamente todos os dados
Desvantagens do mecanismo de persistência AOF
- Para os mesmos dados, o arquivo de log AOF geralmente é maior que o arquivo de captura instantânea de dados RDB
- Depois que o AOF estiver ativado, o QPS de gravação suportado será menor que o QPS de gravação suportado pelo RDB, porque o AOF geralmente é configurado para fsync arquivos de log uma vez por segundo.Claro, uma vez fsync por segundo, o desempenho ainda é muito alto.
Como escolher RDB e AOF
- Não use apenas RDB, pois causará muita perda de dados
- Não use apenas a AOF, pois haverá problemas: primeiro: espera a frio por AOF, sem espera a frio com RDB, a velocidade de recuperação é mais rápida. Segundo: o RDB gera de maneira simples e grosseira instantâneos de dados a cada vez, o que é mais robusto e pode evitar os erros do AOF, um mecanismo tão complicado de backup e recuperação
- Uso abrangente de AOF e RDB, dois mecanismos de persistência, usando AOF para garantir que os dados não sejam perdidos, como a primeira opção para recuperação de dados; usando RDB para fazer diferentes graus de backup a frio, quando arquivos AOF são perdidos ou danificados e indisponíveis, também RDB pode ser usado para recuperação rápida de dados
Configuração RDB
// 900s内至少达到一条写命令
save 900 1
// 300秒内至少达到10条写命令
save 300 10
// 60秒内至少达到10000条写命令
save 60 10000
Você também pode chamar manualmente o comando save ou bgsave para executar a geração de instantâneo rdb de forma síncrona ou assíncrona
Fluxo de trabalho do mecanismo de persistência do RDB
- O Redis tenta gerar o arquivo de captura instantânea RDB de acordo com a configuração
- bifurcar um processo filho
- O processo filho tenta despejar os dados em um arquivo de captura instantânea RDB temporário
- Após a geração do arquivo de captura instantânea RDB, o arquivo de captura instantânea antigo é substituído
Sempre que o dump.rdb gera um novo instantâneo, ele substitui o arquivo de instantâneo antigo
Configuração persistente AOF
A persistência AOF está desativada por padrão e a configuração de persistência RDB está ativada por padrão.
Configure apendonly sim, você pode ativar a persistência AOF
Depois de ativar a persistência AOF, o redis gravará no arquivo de log toda vez que receber um comando de gravação, é claro, primeiro gravará no cache do sistema operacional e depois fsync a cada momento.
E mesmo se o AOF e o RDB estiverem ativados, o AOF será preferido quando o redis reiniciar, porque os dados do AOF são relativamente completos
Você pode configurar a estratégia fsync da AOF. Há três estratégias para escolher:
- sempre: escreva um pedaço de dados toda vez, sincronize imediatamente a gravação desses dados no disco, o desempenho é muito baixo
- everysec: fsync os dados no cache do sistema operacional para o disco a cada segundo, esse é o mais usado e o desempenho é relativamente alto
- no: somente redis é responsável por gravar dados no cache do sistema operacional, não há necessidade de gerenciar, confie no sistema operacional para atualizar os dados no disco de acordo com sua própria estratégia
Reescrita AOF
Os dados em redis são limitados e muitos dados podem expirar automaticamente, podem ser excluídos pelos usuários ou podem ser limpos por redis com um algoritmo de limpeza de cache
Os dados em redis continuarão a eliminar os dados antigos, e apenas parte dos dados comumente usados será retida automaticamente na memória redis
Portanto, é muito provável que os dados que foram limpos antes, o registro de gravação correspondente ainda permaneçam na AOF e o arquivo de log da AOF seja um, que continuará aumentando.
Portanto, com base nos motivos acima, o AOF executará automaticamente as operações de reescrita em segundo plano a cada momento, por exemplo, o log foi armazenado para dados de 100w e apenas 10w na memória redisponível nesse momento; a reescrita será baseada nos dados atuais de 10w da memória Crie um novo conjunto de logs no AOF, substituindo os logs antigos
No redis.conf, você pode configurar a estratégia de reescrita:
- percentagem automática de reescrita 100
- auto-aof-rewrite-min-size 64mb
Se o tamanho exceder 64 mb e tiver aumentado 100% desde a última vez, apenas uma reescrita será acionada
Etapas específicas de reescrita:
- redis fork um processo filho
- O processo filho cria um log com base nos dados da memória atual e começa a gravar o log em um novo arquivo AOF temporário
- O processo principal de redis, depois de receber a nova operação de gravação do cliente, grava a memória de log e o novo log continua a gravar no arquivo AOF antigo
- Substituir arquivos de log antigos por novos arquivos de log
Reparo de arquivos AOF quebrados
Se a máquina estiver inativa quando o redis anexar dados ao arquivo AOF, isso poderá causar danos ao arquivo AOF
Use o comando redis-check-aof --fix para reparar um arquivo AOF quebrado
AOF e RDB trabalham simultaneamente
- Se o RDB estiver executando operações de captura instantânea, o redis não executará operações de reescrita AOF. Se o redis estiver executando a reescrita AOF, a captura instantânea de RDB não será executada
- Se o RDB estiver executando a captura instantânea e o usuário executar o comando BGREWRITEAOF neste momento, a reescrita da AOF não será executada até que a captura instantânea do RDB seja gerada.
- Existem arquivos de captura instantânea RDB e arquivos de log AOF, portanto, quando o redis reiniciar, o AOF será usado para recuperação de dados porque os logs estão mais completos