Compreenda a persistência do Redis, a explicação detalhada e a operação do princípio de funcionamento do modo RDB e modo AOF

persistência redis

Embora o Redis seja um programa de cache em nível de memória, ou seja, o redis usa memória para o cache de dados, mas pode salvar os dados da memória no disco rígido de acordo com uma determinada estratégia, de modo a atingir o objetivo de persistência de dados.
Atualmente o redis suporta dois tipos Diferentes tipos de mecanismos de armazenamento de persistência de dados, RDB e AOF

  • O RDB pode ser considerado um snapshot do Redis em um determinado momento, o que é mais adequado para a recuperação de desastres. Pode ser considerado um snapshot ou pode ser entendido como um Mysql Dump
    • AOF é o log de operações de gravação, que pode ser usado como MySQL Binlog para ajudar a entender

Compreenda a persistência do Redis, a explicação detalhada e a operação do princípio de funcionamento do modo RDB e modo AOF

Modo RDB

Como funciona o modo RDB

Compreenda a persistência do Redis, a explicação detalhada e a operação do princípio de funcionamento do modo RDB e modo AOF

RDB (Redis DataBase): instantâneos baseados em tempo. Por padrão, apenas o instantâneo mais recente é retido. A característica é que a velocidade de execução é relativamente rápida. A desvantagem é que os dados que não foram capturados entre o último instantâneo e o momento atual podem ser perdidos

O processo específico de RDB bgsave para implementar instantâneos:
Compreenda a persistência do Redis, a explicação detalhada e a operação do princípio de funcionamento do modo RDB e modo AOF

  • O Redis bifurca um processo filho do processo principal mestre e usa o mecanismo de cópia na gravação. O processo filho salva os dados na memória como um arquivo temporário, como: tmp-.rdb. Depois que os dados forem salvos, o último arquivo RDB salvo será salvo. Substitua e feche o processo filho, para que você possa garantir que os dados salvos sempre que um instantâneo RDB for concluído
  • Porque ao substituir diretamente o arquivo RDB, pode haver problemas como falha de energia repentina, e o arquivo RDB não foi salvo completamente porque o desligamento repentino para de salvar, resultando em perda de dados. No futuro, você pode executar manualmente o arquivo RDB gerado a cada vez. Backup, para que você possa maximizar a preservação de dados históricos

Compreenda a persistência do Redis, a explicação detalhada e a operação do princípio de funcionamento do modo RDB e modo AOF

  1. O Redis executa o comando bgsave, o Redis julga que há processos filho em execução, como processos filho RDB / AOF, e o comando bgsave retorna diretamente
  2. Bifurcar o processo filho, o processo pai do Redis será bloqueado durante a operação de bifurcação
  3. garfo 完成 返回 59117: M 13 13 de abril: 44: 40.312 * Salvamento em segundo plano iniciado por pid 59180
  4. O processo filho gera arquivos de localização rápida para dados de memória
  5. O processo filho diz ao processo pai para concluir o processamento
    Compreenda a persistência do Redis, a explicação detalhada e a operação do princípio de funcionamento do modo RDB e modo AOF

Perceba a maneira RDB

  • salvar sincronização, bloqueará outros comandos, não recomendado
  • execução assíncrona em segundo plano bgsave, não afeta outras execuções
  • Automático, especifique regras, execute automaticamente

Arquivos de configuração relacionados a RDB

In the example below the behaviour will be to save:
 206 #   after 900 sec (15 min) if at least 1 key changed
 207 #   after 300 sec (5 min) if at least 10 keys changed
 208 #   after 60 sec if at least 10000 keys changed
save 900 1   #在九百秒内有一个触发我就执行
save 300 10
save 60 10000
dbfilename dump.rdb
dir ./     #编泽编译安装,默认RDB文件存放在启动redis的工作目录,建议明确指定存入目录
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes

Vantagens e desvantagens do modo RDB

Vantagens do modo RDB

  • RDB é mais adequado para o modo de backup completo para salvar os dados em um determinado ponto no tempo. Você pode executar o comando redis bgsave (sem bloqueio, execução em segundo plano) ou salvar (bloqueará a operação de gravação, recomendado) para autodefinir o backup no ponto no tempo, e você pode manter mais Um backup, quando ocorre um problema, é conveniente restaurar para um nó de tempo diferente, o que é muito adequado para backup, e este formato de arquivo suporta muitas ferramentas de terceiros para análise de dados subsequente,
    como: Arquivos RDB podem ser copiados a cada hora nas últimas 24 horas , E faça backup de um arquivo RDB todos os dias de cada mês, de forma que mesmo se você encontrar problemas, você pode restaurar o conjunto de dados para uma versão diferente a qualquer momento
  • O RDB pode maximizar o desempenho do Redis . Quando o processo pai salva o arquivo RDB, a única coisa a fazer é bifurcar um processo filho e, em seguida, este processo filho processará todo o próximo trabalho salvo, o processo pai não precisa executar nenhuma E / S de disco operativo
  • REB recupera muitos dados, como vários dados G, mais rápido do que AOF

Desvantagens do RDB

  • O método REB não pode salvar dados em tempo real e pode perder os dados do último backup RDB para a memória atual.
    Se você precisar tentar evitar a perda de dados quando o servidor falhar, o RDB não é para você. Embora o Redis permita definir diferentes pontos de salvamento para controlar a frequência de salvamento de arquivos RDB, porque os arquivos ROB precisam salvar o estado de todo o conjunto de dados, não é uma operação fácil. Portanto, você pode salvar o arquivo RDB por pelo menos 5 minutos. Nesse caso, quando ocorre um tempo de inatividade, você pode perder vários minutos de dados.
  • Versão compatível com o problema de formato RDB. Quando a quantidade de dados é muito grande, leva um tempo para salvar do processo pai para o processo filho no arquivo RDB, que pode ser milissegundos ou segundos, dependendo do desempenho de E / S do disco. Quando o conjunto de dados é relativamente grande, fork () Pode ser muito demorado, fazendo com que o servidor pare de processar o cliente dentro de um determinado período de tempo; se o conjunto de dados for muito grande e o tempo de CPU muito curto, então esse tempo de parada pode ser tão longo quanto um segundo inteiro ou mais. Embora a reescrita de AOF também exija fork (), não importa quanto tempo seja o intervalo de execução da reescrita de AOF, não haverá perda de durabilidade de dados

Pratique o script para fazer backup manualmente de arquivos RDB

[root@centos7 ~]#vim /apps/redis/etc/redis.conf
save ""
dbfilename dump_6379.rdb
dir "/data/redis"
appendonly no

[root@centos8 ~]#cat redis_backup_rdb.sh
#!/bin/bash
. /etc/init.d/functions
BACKUP=/backup/redis-rdb
DIR=/data/redis
FILE=dump_6379.rdb
PASS=123456
redis-cli -h 127.0.0.1 -a $PASS --no-auth-warning bgsave
result=`redis-cli -a 123456 --no-auth-warning info Persistence |grep
rdb_bgsave_in_progress| sed -rn 's/.*:([0-9]+).*/\1/p'`
until [ $result -eq 0 ] ;do
  sleep 1
  result=`redis-cli -a 123456 --no-auth-warning info Persistence |grep
rdb_bgsave_in_progress| sed -rn 's/.*:([0-9]+).*/\1/p'`
done
DATE=`date +%F_%H-%M-%S`
[ -e $BACKUP ] || { mkdir -p $BACKUP ; chown -R redis.redis $BACKUP; }
mv $DIR/$FILE $BACKUP/dump_6379-${DATE}.rdb
action "Backup redis RDB"
#执行
[root@centos8 ~]#bash redis_backup_rdb.sh
Background saving started
Backup redis RDB                      [ OK ]
[root@centos8 ~]#ll /backup/redis-rdb/ -h
total 143M
-rw-r--r-- 1 redis redis 143M Oct 21 11:08 dump_6379-2020-10-21_11-08-47.rdb

Exemplo: Observe o processo de execução de save e bgsave 67255

#阻塞
#生成临时文件

Exemplo: salvar automaticamente

[root@centos7 ~]#vim /apps/redis/etc/redis.conf
save 60 3
#测试60s内修改3个key,验证是否生成RDB文件

Modo AOF

O modo de trabalho do modo AOF (duas imagens são convenientes para que todos entendam)
Compreenda a persistência do Redis, a explicação detalhada e a operação do princípio de funcionamento do modo RDB e modo AOF
Compreenda a persistência do Redis, a explicação detalhada e a operação do princípio de funcionamento do modo RDB e modo AOF

  1. Anexar todos os comandos de gravação ao buffer aof
  2. O buffer AOF é sincronizado com o disco rígido de acordo com a configuração appendfsync correspondente
  3. Reescrever arquivos AOF regularmente
  4. Quando o Redis for reiniciado, você pode carregar o arquivo AOF para recuperação de dados

AOF: AppendOnylFile, siga a ordem das operações para anexar as operações ao final do arquivo de log especificado.
AOF usa o mecanismo de cópia na gravação como RDB. O padrão do AOF é fsync uma vez por segundo, o que significa que os comandos executados serão salvos no arquivo AOF, mesmo se redis Se o servidor falhar, apenas os dados em 1 segundo serão perdidos. Você também pode definir diferentes estratégias fsync sempre, ou seja, definir para executar fsync toda vez que um comando for executado, fsync executará o thread em segundo plano, para que o thread principal possa continuar a processar o do usuário Solicitação normal sem ser afetado pelo I / O gravado no arquivo AOF.
Ambos RDB e AOF estão ativados. Ao recuperar, a prioridade do arquivo AOF padrão é maior do que o arquivo RDB, ou seja, o arquivo AOF será usado para recuperação.
Nota !!!: O modo AOF é padronizado para Fechado, após abrir o AOF pela primeira vez e reiniciar o serviço para entrar em vigor, a prioridade do AOF é maior do que RDB e o AOF não possui arquivos por padrão, o que fará com que todos os dados sejam perdidos.

AOF reescrever

  • Reescrever alguns dados duplicados, mescláveis ​​e expirados em um novo arquivo AOF, economizando espaço no disco rígido ocupado pelo backup AOF e acelerando o processo de recuperação
  • Você pode executar manualmente bgrewriteaof para acionar o AOF ou definir uma estratégia de reescrita automática
    Compreenda a persistência do Redis, a explicação detalhada e a operação do princípio de funcionamento do modo RDB e modo AOF

Nota !!!: O modo AOF é desativado por padrão. Depois que o AOF é ativado pela primeira vez e o serviço é reiniciado para entrar em vigor, a prioridade do AOF é maior do que a do RDB e o AOF não tem arquivos por padrão, o que fará com que todos os dados sejam perdidos.

[root@centos8 ~]#ll /var/lib/redis/
total 314392
-rw-r--r-- 1 redis redis 187779391 Oct 17 14:23 dump.rdb
[root@centos8 ~]#redis-cli
127.0.0.1:6379> config get appendonly
1) "appendonly"
2) "no"
127.0.0.1:6379> config set appendonly  yes
OK
[root@centos8 ~]#ll /var/lib/redis/
total 314392
-rw-r--r-- 1 redis redis 187779391 Oct 17 14:23 dump.rdb
-rw-r--r-- 1 redis redis  85196805 Oct 17 14:45 temp-rewriteaof-2146.aof
[root@centos8 ~]#ll /var/lib/redis/
total 366760
-rw-r--r-- 1 redis redis 187779391 Oct 17 14:45 appendonly.aof
-rw-r--r-- 1 redis redis 187779391 Oct 17 14:23 dump.rdb
[root@centos8 ~]#vim /etc/redis.conf
appendonly yes #改为yes
#config set appendonly yes 可以同时看到下面显示

Compreenda a persistência do Redis, a explicação detalhada e a operação do princípio de funcionamento do modo RDB e modo AOF

Configuração relacionada ao AOF

appendonly yes              #是否开启AOF日志记录,默认redis使用的是rdb方式持久化,这种方式在许多应用中已经足够用了,但是redis如果中途宕机,会导致可能有几分钟的数据丢失(取决于dump数据的间隔时间),根据save来策略进行持久化,Append Only File是另一种持久化方式,可以提供更好的持久化特性,Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件,每次启动时Redis都会先把这个文件的数据读入内存里,先忽略RDB文件。默认不启用此功能
appendfilename "appendonly-${port}.aof"          #文本文件AOF的文件名,存放在dir指令指定的目录中
appendfsync everysec    #aof持久化策略的配置
#no表示由操作系统保证数据同步到磁盘,Linux的默认fsync策略是30秒,最多会丢失30s的数据
#always表示每次写入都执行fsync,以保证数据同步到磁盘,安全性高,性能较差
#everysec表示每秒执行一次fsync,可能会导致丢失这1s数据,此为默认值,也生产建议值
dir /path               #快照文件保存路径,示例:dir "/apps/redis/data"

no-appendfsync-on-rewrite yes     #在aof rewrite期间,是否对aof新记录的append暂缓使用文件同步策略,主要考虑磁盘IO开支和请求阻塞时间。
#默认为no,表示"不暂缓",新的aof记录仍然会被立即同步到磁盘,是最安全的方式,不会丢失数据,但是要忍受阻塞的问题
#为yes,相当于将appendfsync设置为no,这说明并没有执行磁盘操作,只是写入了缓冲区,因此这样并不会造成阻塞(因为没有竞争磁盘),但是如果这个时候redis挂掉,就会丢失数据。丢失多少数据呢?Linux的默认fsync策略是30秒,最多会丢失30s的数据,但由于yes性能较好而且会避免出现阻塞因此比较推荐
#rewrite 即对aof文件进行整理,将空闲空间回收,从而可以减少恢复数据时间
auto-aof-rewrite-percentage 100             #当Aof log增长超过指定百分比例时,重写AOF文件,设置为0表示不自动重写Aof日志,重写是为了使aof体积保持最小,但是还可以确保保存最完整的数据
auto-aof-rewrite-min-size 64mb              #触发aof rewrite的最小文件大小
aof-load-truncated yes                      #是否加载由于某些原因导致的末尾异常的AOF文件(主进程被kill/断电等),建议yes
aof-use-rdb-preamble no #redis4.0新增RDB-AOF混合持久化格式,在开启了这个功能之后,AOF重写产生的文件将同时包含RDB格式的内容和AOF格式的内容,其中RDB格式的内容用于记录已有的数据,而AOF格式的内容则用于记录最近发生了变化的数据,这样Redis就可以同时兼有RDB持久化和AOF持久化的优点(既能够快速地生成重写文件,也能够在出现问题时,快速地载入数据),默认为no,即不启用此功能

Exemplo: modificar dinamicamente a configuração e gerar automaticamente o arquivo appendonly.aof

127.0.0.1:6379> CONFIG set appendonly yes

Execute manualmente AOF para reescrever o comando BGREWRITEAOF

  • BGREWRITEAOF
    complexidade de tempo: O (N), N é o número de dados a serem anexados ao arquivo AOF.
    Execute uma operação de reescrita de arquivo AOF. A reescrita criará uma versão otimizada do arquivo AOF atual.
  • Mesmo se a execução de BGREWRITEAOF falhar, não haverá perda de dados, porque o arquivo AOF antigo não será modificado antes que BGREWRITEAOF seja bem-sucedido.
  • A operação de reescrita só será acionada quando nenhum outro trabalho de persistência for executado em segundo plano, ou seja:
    se o processo filho do Redis estiver realizando o trabalho de salvamento do instantâneo, a operação de reescrita AOF será agendada (agendada) e aguardará até que o trabalho seja salvo Execute a reescrita AOF após a conclusão. Neste caso, o valor de retorno de BGREWRITEAOF ainda está OK, mas uma mensagem adicional será adicionada, informando que BGREWRITEAOF não pode ser executado até que a operação de salvamento seja concluída. No Redis 2.6 ou superior, você pode usar o comando INFO [seção] para verificar se BGREWRITEAOF está reservado.
  • Se outra regravação de arquivo AOF já estiver sendo executada, BGREWRITEAOF retornará um erro e essa nova
    solicitação BGREWRITEAOF não será agendada para a próxima execução.
  • A partir do Redis 2.4, a regravação AOF é acionada pelo próprio Redis e BGREWRITEAOF é usado apenas para acionar manualmente a operação de regravação.

Exemplo: bgrewriteaof manual

127.0.0.1:6379> BGREWRITEAOF
Background append only file rewriting started

#同时可以观察到下面显示

Compreenda a persistência do Redis, a explicação detalhada e a operação do princípio de funcionamento do modo RDB e modo AOF

Vantagens e desvantagens do modo AOF

Vantagens do modo AOF

  • A segurança dos dados é relativamente alta. De acordo com a estratégia fsync usada (fsync é para sincronizar todos os arquivos modificados do redis na memória para o dispositivo de armazenamento), o padrão é appendfsync everysec, ou seja, fsync é executado uma vez por segundo. Nesta configuração, o Redis ainda O bom desempenho pode ser mantido e, mesmo se ocorrer uma falha, apenas um segundo de dados será perdido (fsync será executado em um thread de segundo plano, portanto, o thread principal pode continuar a trabalhar duro para processar solicitações de comando)
  • Como esse mecanismo usa o modo anexar para a operação de gravação do arquivo de log, não há necessidade de buscar durante o processo de gravação e, mesmo se houver um tempo de inatividade, ele não destruirá o conteúdo existente no arquivo de log. No entanto, se essa operação gravar apenas metade dos dados e o sistema travar, não se preocupe, você pode usar a ferramenta redis-check-aof para resolver o problema de consistência de dados antes que o Redis seja iniciado na próxima vez
  • O Redis pode reescrever automaticamente o AOF em segundo plano quando o volume do arquivo AOF torna-se muito grande. O novo arquivo AOF após a reescrita contém o conjunto mínimo de comandos necessários para restaurar o conjunto de dados atual. Toda a operação de reescrita é absolutamente segura, porque o Redis está em processo de criação de um novo arquivo AOF, o modo anexar continuamente anexa os dados modificados ao arquivo AOF existente, mesmo se o processo de reescrita parar, o arquivo AOF existente ainda está Não se perderá. Depois que o novo arquivo AOF for criado, o Redis mudará do arquivo AOF antigo para o novo arquivo AOF e começará a anexar o novo arquivo AOF.
  • AOF contém um arquivo de log claramente formatado e fácil de entender para registrar todas as operações de modificação. Na verdade, os dados também podem ser reconstruídos por meio desse arquivo. O arquivo AOF armazena todas as operações de gravação realizadas no banco de dados de maneira ordenada. Essas operações de gravação são salvas no formato do protocolo Redis, de modo que o conteúdo do arquivo AOF é muito fácil de ser lido pelas pessoas. , Também é muito fácil analisar o arquivo (analisar). Exportar arquivos AOF também é muito simples:
  • Por exemplo, se você acidentalmente executar o comando FLUSHALL., Mas desde que o arquivo AOF não seja regravado, apenas pare o servidor, remova o comando FLUSHAL no final do arquivo AOF e reinicie o Redis, e você pode restaurar o conjunto de dados para
    FLUSHALL. O estado anterior.

Desvantagens do modo AOF

  • Mesmo que algumas operações sejam repetidas, todas serão gravadas.O tamanho do arquivo de AOF é maior do que o do formato RDB.
  • AOF é mais lento do que RDB ao recuperar grandes conjuntos de dados
  • Dependendo da estratégia de fsync, AOF pode ser mais lento que RDB
  • Mais possibilidades para bugs

Escolha de RDB e AOF

  • Se for usado principalmente como uma função de cache, ou puder suportar a perda de vários minutos de dados, geralmente o ambiente de produção geralmente só precisa habilitar RDB, que também é o valor padrão
  • Se os dados precisarem ser armazenados de forma persistente e não puderem ser perdidos, você pode escolher ativar RDB e AOF ao mesmo tempo. Geralmente, não é recomendado ativar apenas AOF

Acho que você gosta

Origin blog.51cto.com/13887323/2543914
Recomendado
Clasificación