Серия Redis: постоянство RDB и постоянство AOF

Redis задняя часть база данных сервер

предисловие

Что такое настойчивость?

Постоянство, т. е. сохранение данных (например, объектов в памяти) на запоминающих устройствах (например, на дисках), которые можно сохранить навсегда. Основное применение постоянства — хранение объектов в памяти в базе данных или в файлах на диске, файлах данных XML и т. д. Постоянство — это механизм преобразования данных программы между постоянным и переходным состояниями. ----Из энциклопедии Baidu

Данные Redis хранятся в памяти, поэтому постоянство Redis означает сохранение данных, хранящихся в памяти Redis, на жесткий диск.
Redis предоставляет два метода сохранения

  1. Постоянство RDB (моментальные снимки)
  2. Сохранение AOF (файл только для добавления)

Давайте сначала взглянем на сохраняемость RDB.

постоянство RDB

Постоянство RDB относится к вводу на клиентеsave,bgsaveИли, когда файл конфигурации автоматически сохраняет состояние снимка, снимок данных, сгенерированных Redis в памяти, сохраняется в двоичном файле с именем dump.rdb (имя файла можно изменить).

сохранить команду

Команда сохранения блокирует процесс сервера Redis до тех пор, пока не будет создан файл RDB.В течение периода блокировки сервера Redis сервер не может обрабатывать запросы команд. Введите сохранить на клиенте

192.168.17.101:6379> save
OK

На сервере появятся следующие персонажи

1349:M 30 Jul 17:16:48.935 * DB saved on disk

команда bgsave

Команда bgsave работает следующим образом.

  1. Серверный процесс с pid 1349 разветвляет дочерний процесс с pid 1357.
  2. Дочерний процесс записывает данные во временный файл RDB.
  3. Когда дочерний процесс завершает запись в новый файл RDB, Redis заменяет старый файл RDB новым файлом RDB и удаляет старый файл RDB.

Введите bgsave на стороне клиента

192.168.17.101:6379> bgsave
Background saving started

На сервере появятся следующие персонажи

1349:M 30 Jul 17:14:42.991 * Background saving started by pid 1357
1357:C 30 Jul 17:14:42.993 * DB saved on disk
1357:C 30 Jul 17:14:42.993 * RDB: 4 MB of memory used by copy-on-write
1349:M 30 Jul 17:14:43.066 * Background saving terminated with success

Примечание: во время выполнения команды bgsave Команда СОХРАНИТЬ будет отклонена Невозможно выполнить две команды BGSAVE одновременно Невозможно одновременно выполнить команды BGREWRITEAOF и BGSAVE.

автосохранение

Это необходимо изменить в файле конфигурации redis.conf.Стратегия сохранения по умолчанию выглядит следующим образом.

save 900 1    # 900 秒内有至少有 1 个键被改动
save 300 10   # 300 秒内有至少有 10 个键被改动
save 60 10000 # 60 秒内有至少有 1000 个键被改动

Далее рассмотрим настройку RBD

настроить

################################ SNAPSHOTTING  ################################
# 触发自动保存快照
# save <seconds> <changes>
# save <秒> <修改的次数>
save 900 1    
save 300 10   
save 60 10000 

# 设置在保存快照出错时,是否停止redis命令的写入
stop-writes-on-bgsave-error yes

# 是否在导出.rdb数据库文件的时候采用LZF压缩
rdbcompression yes

#  是否开启CRC64校验
rdbchecksum yes

# 导出数据库的文件名称
dbfilename dump.rdb

# 导出的数据库所在的目录
dir ./

преимущество

  • RDB — это очень компактный (сжатый) файл, который сохраняет данные в определенный момент времени, что очень удобно для резервного копирования данных.
  • Будучи очень компактным (сжатым) файлом, RDB может быть легко перенесен в другой удаленный центр обработки данных, что очень удобно для аварийного восстановления.
  • Когда RDB сохраняет файл RDB, единственное, что нужно сделать родительскому процессу, — это разветвить дочерний процесс, а следующая работа выполняется дочерним процессом Родительскому процессу не нужно выполнять другие операции ввода-вывода, поэтому сохраняемость RDB метод может максимизировать производительность Redis.
  • По сравнению с AOF метод RDB будет быстрее при восстановлении больших наборов данных.

Перевод с http://www.redis.cn

недостаток

  • При неожиданном сбое Redis некоторые данные будут потеряны.
  • Когда объем данных Redis относительно велик, процесс форка занимает очень много времени, и дочерний процесс форка будет заблокирован, в течение этого периода Redis не может ответить на запрос клиента.

Сохранение AOF

Постоянство AOF записывает состояние базы данных, сохраняя команды записи, выполняемые сервером Redis, то есть всякий раз, когда Redis выполняет команду, которая изменяет набор данных (например, SET), эта команда будет добавлена ​​в конец файла AOF.

Так как же нам включить постоянство AOF?

Включить сохранение AOF

Измените файл конфигурации redis.conf, по умолчанию используется только добавление no (закрытое состояние), измените no на yes

appendonly yes

Вы также можете ввести следующую команду на клиенте, но она не будет выполнена после перезапуска сервера Redis.

192.168.17.101:6379> config set appendonly yes
OK

Далее давайте взглянем на реализацию функции сохранения AOF.

выполнить

Реализация функции персистентности AOF может быть разделена на три этапа: добавление команды (append), запись файла и синхронизация файла (sync). Ниже весь процесс в три шага.

Введите следующую команду в клиенте Redis

192.168.17.101:6379> set learnRedis testAOF
OK

Файл appendonly.aof добавит следующее содержимое

*2
$6
SELECT
$1
0
*3
$3
set
$10
learnRedis
$7
testAOF

команда добавить

Когда функция постоянства AOF включена, после выполнения сервером команды записи он добавляет выполненную команду записи в конец буфера aof_buf состояния сервера в формате протокола. На данный момент запись буфера не была записана в файл appendonly.aof.

Запись файлов и синхронизация

Почему запись файлов и синхронизация файлов объединены? Поскольку в файле конфигурации указан параметр appendfsync, этот параметр управляет поведением при записи и синхронизации файлов.

Информация о записи файлов и синхронизации выглядит следующим образом

Потому что для повышения эффективности записи файла, в современных операционных системах, когда пользователь вызывает функцию записи для записи каких-то данных в файл, ОС обычно временно сохраняет записанные данные в буфере памяти (например, unix). реализация имеет буферный кеш или кеш страниц в ядре, когда мы записываем данные в файл, ядро ​​обычно сначала копирует данные в буфер, затем ставит их в очередь и позже записывает на диск), этот метод называется отложенной записью. буферное пространство заполнено, или указанный лимит времени превышен, или ядру необходимо повторно использовать буфер для хранения других данных блока диска, все данные в буфере будут фактически записаны в буфер внутри диска.

Проще говоря

Запись файла: только что записанный в буфер памяти, возможно, не был записан в блок данных диска, принадлежащий файлу
синхронизация файлов: сброс содержимого буфера на диск

параметр appendfsync

Значение параметра appendfsync Эффект
always Каждый раз, когда появляется новая команда, данные буфера записываются и синхронизируются с файлом AOF.
каждую секунду (по умолчанию) Каждую секунду записывает и синхронизирует данные буфера с файлом AOF.
no Запишите данные буфера в файл AOF, но передайте синхронную операцию операционной системе для обработки.

Загрузка и восстановление данных

Шаги для чтения файла AOF и восстановить базу данных следующим образом

  1. Создайте поддельный клиент без подключения к сети
  2. Разобрать и прочитать команду записи из файла AOF
  3. Выполните команду чтения и записи, используя псевдоклиент.
  4. Продолжайте выполнять шаги 2 и 3, пока не будут обработаны все команды записи в файле AOF.

图片来自Redis设计与实现

На этом этапе может возникнуть проблема. Сервер может остановиться, когда программа записывает файл AOF, вызывая ошибку файла AOF, тогда Redis откажется загружать файл AOF при перезапуске, чтобы гарантировать, что согласованность данных не будет нарушена. Файлы AOF можно восстановить следующими способами:

  • Создайте резервную копию существующего файла AOF.
  • Используйте программу redis-check-aof, включенную в Redis, для восстановления исходного файла AOF: redis-check-aof –fix
  • (Необязательно) Используйте diff -u, чтобы сравнить восстановленный файл AOF с резервной копией исходного файла AOF, чтобы увидеть различия между двумя файлами.
  • Перезапустите сервер Redis, подождите, пока сервер загрузит восстановленный файл AOF, и выполните восстановление данных.

Кроме того, файл конфигурации redis.conf также предоставляет параметр для управления тем, следует ли игнорировать последнюю инструкцию, которая может вызвать проблемы, как показано ниже.

aof-load-truncated yes

переписать

Поскольку постоянство AOF записывает состояние базы данных, постоянно добавляя команды в конец файла, по мере увеличения количества команд записи размер файла AOF также будет становиться все больше и больше. А некоторые команды изменяют одни и те же данные и могут быть объединены в одну команду. Это как вызов INCR 100 раз по счетчику, AOF будет хранить 100 записей, на самом деле достаточно хранить одну порцию данных.

Поэтому, чтобы справиться с этой ситуацией, Redis предоставляет механизм перезаписи AOF.

Существует два механизма запуска механизма перезаписи AOF, один из которых — вызов команды BGREWRITEAOF.

192.168.17.101:6379> BGREWRITEAOF
Background append only file rewriting started

Другой - запуск в соответствии с параметрами в файле конфигурации, параметры следующие:

auto-aof-rewrite-percentage 100 #当前AOF文件大小和上一次重写时AOF文件大小的比值
auto-aof-rewrite-min-size 64mb  #文件的最小体积

Сервер отобразит следующую информацию

1349:M 30 Jul 17:19:25.311 * Background append only file rewriting started by pid 1392
1349:M 30 Jul 17:19:25.379 * AOF rewrite child asks to stop sending diffs.
1392:C 30 Jul 17:19:25.379 * Parent agreed to stop sending diffs. Finalizing AOF...
1392:C 30 Jul 17:19:25.380 * Concatenating 0.00 MB of AOF diff received from parent.
1392:C 30 Jul 17:19:25.380 * SYNC append only file rewrite performed
1392:C 30 Jul 17:19:25.381 * AOF rewrite: 4 MB of memory used by copy-on-write
1349:M 30 Jul 17:19:25.466 * Background AOF rewrite terminated with success
1349:M 30 Jul 17:19:25.467 * Residual parent diff successfully flushed to the rewritten AOF (0.00 MB)
1349:M 30 Jul 17:19:25.467 * Background AOF rewrite finished successfully

переписать шаги

  1. Создайте подпроцесс для перезаписи AOF
  2. Добавить команду записи клиента в буфер перезаписи AOF.
  3. После того, как дочерний процесс завершит работу по перезаписи AOF, он отправит сигнал родительскому процессу.
  4. После того, как родительский процесс получает сигнал, он записывает все содержимое буфера перезаписи AOF в новый файл AOF.
  5. Переименуйте новый файл AOF, атомарно перезапишите существующий файл AOF.

Примечание: перезапись AOF не требует каких-либо операций чтения, синтаксического анализа и записи в существующих файлах AOF.

настроить

############################## APPEND ONLY MODE ###############################

# 是否开启AOF功能
appendonly no

# AOF文件件名称
appendfilename "appendonly.aof"

# 写入AOF文件的三种方式
# appendfsync always
appendfsync everysec
# appendfsync no

# 重写AOF时,是否继续写AOF文件
no-appendfsync-on-rewrite no

# 自动重写AOF文件的条件
auto-aof-rewrite-percentage 100 #百分比
auto-aof-rewrite-min-size 64mb #大小

# 是否忽略最后一条可能存在问题的指令
aof-load-truncated yes

преимущество

  • Использование AOF сделает ваш Redis более стойким
  • Файл AOF — это файл журнала только для добавления, который не нужно читать во время записи.
  • Redis может автоматически перезаписывать AOF в фоновом режиме, когда размер файла AOF становится слишком большим.
  • Файлы AOF легко читаются и легко анализируются.

недостаток

  • Для одних и тех же данных размер файла AOF обычно больше, чем файл RDB.
  • AOF может быть медленнее, чем RDB, в зависимости от используемой стратегии fsync.

загрузка данных

И RDB, и AOF загружаются при запуске.Когда AOF включен, данные сначала будут восстановлены из файла AOF, а данные будут восстановлены из файла RDB, когда AOF выключен.

Примечание: я не знаю, с какой версии начать, когда функция AOF включена, файл AOF не существует, а файл RDB не будет загружен.