Механизм сохранения Redis: RDB и AOF

Redis

Сохранение данных Redis

Redis какОЗУВ базе данных данные хранятся в памяти, поэтому после завершения процесса сервера Redis данные на сервере также исчезнут. Чтобы решить эту проблему, Redis предоставляет механизм сохранения, который заключается в сохранении данных в памяти на диск, чтобы избежать случайной потери данных.

Redis предоставляет две схемы сохранения:постоянство RDBиСохранение AOF, один из них — метод моментального снимка, а другой — метод, аналогичный log append

Сохранение моментального снимка RDB

Сохранение RDB осуществляется черезснимок, который записывает моментальный снимок набора данных в памяти на диск через заданный интервал времени. После создания моментального снимка пользователь может создать его резервную копию, скопировать моментальный снимок на другой сервер, чтобы создать серверную копию тех же данных, или восстановить данные после перезапуска сервера. RDB — это метод сохраняемости по умолчанию для Redis.

Сохранение моментального снимка

Постоянство RDB создает файл RDB, который являетсякомпрессияпрошедшийбинарный файл, этот файл можно использовать для восстановления состояния базы данных на момент создания моментального снимка, то есть данных сервера на момент создания файла RDB. Файл RDB по умолчанию соответствует текущему рабочему каталогу.dump.rdb, согласно конфигурационному файлуdbfilenameиdirУстановите имя файла и расположение файла RDB

# 设置 dump 的文件名
dbfilename dump.rdb

# 工作目录
# 例如上面的 dbfilename 只指定了文件名,
# 但是它会写入到这个目录下。这个配置项一定是个目录,而不能是文件名。
dir ./

Когда запускать снимок

  • воплощать в жизньsaveиbgsaveЗаказ
  • Настройки профиляsave <seconds> <changes>Правила, автоматически выполняемые через определенные промежутки времениbgsaveЗаказ
  • Во время репликации master-slave подчиненная база данных полностью реплицируется для синхронизации данных главной базы данных, и основная база данных будет выполняться.bgsave
  • воплощать в жизньflushallкоманда для очистки данных сервера
  • воплощать в жизньshutdownКогда команда закроет Redis, она выполнитсяsaveЗаказ

команды save и bgsave

воплощать в жизньsaveиbgsaveкомандой, вы можете вручную запускать моментальные снимки и генерировать файлы RDB.Разница между ними заключается в следующем.

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

127.0.0.1:6379> save
OK

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

127.0.0.1:6379> bgsave
Background saving started

fork()это функция, предоставляемая операционной системой для создания копии текущего процесса в качестве дочернего процесса

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

Автоматический интервальный триггер

установить в конфигурационном файлеsave <seconds> <changes>Правила, которые могут автоматически выполняться через определенные промежутки времениbgsaveЗаказ

################################ SNAPSHOTTING  ################################
#
# Save the DB on disk:
#
#   save <seconds> <changes>
#
#   Will save the DB if both the given number of seconds and the given
#   number of write operations against the DB occurred.
#
#   In the example below the behaviour will be to save:
#   after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed
#
#   Note: you can disable saving completely by commenting out all "save" lines.
#
#   It is also possible to remove all the previously configured save
#   points by adding a save directive with a single empty string argument
#   like in the following example:
#
#   save ""

save 900 1
save 300 10
save 60 10000

save <seconds> <changes>Указывает, что в течение секунд, если есть хотя бы время изменения, он будет запущен автоматически.gbsaveЗаказ

  • save 900 1Когда время достигнет 900 секунд, если изменится хотя бы 1 ключ, он будет запущен автоматически.bgsaveкоманда для создания снимка
  • save 300 10Когда время достигнет 300 секунд, если изменится хотя бы 10 ключей, он автоматически сработает.bgsaveкоманда для создания снимка
  • save 60 10000Когда время достигнет 60 секунд, если изменится не менее 10 000 ключей, он автоматически сработает.bgsaveкоманда для создания снимка

Сохранение AOF

В дополнение к сохранению RDB, Redis также предоставляет функцию сохранения AOF (Append Only File).Сохранение AOF запишет выполненную команду записи в конец файла AOF для записи изменений данных. По умолчанию Redis не включает сохранение AOF.После его включения каждый раз, когда выполняется команда для изменения данных Redis, команда будет добавляться в файл AOF, что снизит производительность Redis, но в большинстве случаев это влияет Это приемлемо, и использование более быстрого жесткого диска может повысить производительность AOF.

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

# appendonly参数开启AOF持久化
appendonly no

# AOF持久化的文件名,默认是appendonly.aof
appendfilename "appendonly.aof"

# AOF文件的保存位置和RDB文件的位置相同,都是通过dir参数设置的
dir ./

# 同步策略
# appendfsync always
appendfsync everysec
# appendfsync no

# aof重写期间是否同步
no-appendfsync-on-rewrite no

# 重写触发配置
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

# 加载aof出错如何处理
aof-load-truncated yes

# 文件重写策略
aof-rewrite-incremental-fsync yes

Реализация АОФ

AOF должен записывать каждую команду Redis на запись.Этапы: добавление команды (добавление), запись файла (запись) и синхронизация файлов (синхронизация).

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

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

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

когдаaof_bufСодержимое буфера записывается и сохраняется в файле AOF, а Redis предлагает различные стратегии.

  • appendfsync always:будетaof_bufВсе содержимое буфера записывается и синхронизируется с файлом AOF, и каждая команда записи записывается на диск синхронно.
  • appendfsync everysec:будетaof_bufСодержимое области буфера записывается в файл AOF, который синхронизируется раз в секунду, за эту операцию отвечает исключительно один поток.
  • appendfsync no:будетaof_bufСодержимое буферной области записывается в файл AOF, а когда синхронизировать, определяет операционная система.

appendfsyncКонфигурация по умолчанию для параметровeverysec, т.е. выполнять синхронизацию каждую секунду

Стратегия синхронизации AOF связана с операционной системой.writeфункция иfsyncфункция, как описано в разделе «Проектирование и реализация Redis».

В целях повышения эффективности записи файлов в современных операционных системах при вызове пользователемwriteФункция, при записи некоторых данных в файл, операционная система обычно временно сохраняет данные в буфере памяти.Когда пространство буфера заполнено или превышает указанный предел времени, данные буфера фактически записываются в файл на диск.

Хотя такая операция повышает эффективность, она также создает проблему безопасности при записи данных: если компьютер выходит из строя, данные в буфере памяти теряются. Для этого в системе предусмотреноfsync,fdatasyncФункция синхронизации может заставить операционную систему немедленно записать данные из буфера на жесткий диск, тем самым обеспечив безопасность записываемых данных.

Из приведенного выше введения мы знаем, что данные, которые мы записываем, не обязательно будут немедленно синхронизированы на диск операционной системой, поэтому Redis предоставляетappendfsyncконфигурация опции. Когда этот вариантalwaysКогда безопасность данных самая высокая, но на диск будет выполняться большое количество операций записи, а скорость обработки команд Redis будет ограничена производительностью диска;appendfsync everysecОпция учитывает безопасность данных и производительность записи, а также синхронизирует файлы AOF с частотой один раз в секунду.Даже в случае сбоя системы максимум будут потеряны только данные, созданные в течение одной секунды;appendfsync noОпция, Redis не будет выполнять операции синхронизации над файлами AOF, но операционная система сама решает, когда производить синхронизацию, что не повлияет на производительность Redis, но в случае сбоя системы может быть потеряно неопределенное количество данных

AOF переписать (переписать)

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

127.0.0.1:6379> set s1 hello
OK
127.0.0.1:6379> set s2 world
OK

тогда мы открываемappendonly.aofфайл, вы можете увидеть следующее

*3
$3
set
$2
s1
$5
hello
*3
$3
set
$2
s2
$5
world

Формат команды — протокол сериализации Redis (RESP).*3У этой команды есть три параметра:$3Указывает, что длина параметра равна 3

Глядя на содержимое файла AOP выше, мы должны представить, что с течением времени Redis будет выполнять все больше и больше команд записи, и файл AOF будет становиться все больше и больше, а слишком большой файл AOF может привести к повреждению сервера Redis.Влияние, если файл AOF используется для восстановления данных, время, необходимое для восстановления данных, будет больше.

Со временем в файлах AOF обычно появляются некоторые избыточные команды, такие как: команды для просроченных данных, недопустимые команды (дублирование настроек, удаление) и несколько команд могут быть объединены в одну команду (пакетная команда). Таким образом, в файлах AOF есть место для компактного сжатия.

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

Перезапись файлов можно разделить на ручной триггер и автоматический триггер, а также ручное выполнение триггера.bgrewriteaofкоманда, выполнение команды следуетbgsaveАналогично запуску моментальных снимков, сначала всеforkДочерний процесс выполняет определенную работу

127.0.0.1:6379> bgrewriteaof
Background append only file rewriting started

Автоматическое срабатывание будет основано наauto-aof-rewrite-percentageиauto-aof-rewrite-min-size 64mbНастроить для автоматизацииbgrewriteaofЗаказ

# 表示当AOF文件的体积大于64MB,且AOF文件的体积比上一次重写后的体积大了一倍(100%)时,会执行`bgrewriteaof`命令
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

Посмотрим на реализациюbgrewriteaofкоманда, переписанный процесс

  • Перезаписи будет много операций записи, поэтому серверный процесс будетforkПодпроцесс для создания нового файла AOF
  • Во время перезаписи серверный процесс продолжает обрабатывать запросы команд, добавляяaof_bufВ то же время он также будет добавлен вaof_rewrite_bufБуфер перезаписи AOF
  • Когда дочерний процесс завершит перезапись, он подаст родительскому процессу сигнал, а затем родительский процесс запишет содержимое буфера перезаписи AOF в новый временный файл AOF, а затем переименует новый файл AOF для завершения замены. чтобы обеспечить новую согласованность файла AOF с текущими данными базы данных.

Восстановление данных

Redis 4.0 начал поддерживать смешанное сохранение RDB и AOF (можно настроить черезaof-use-rdb-preambleна)

  • Если процесс Redis зависает, перезапустите процесс Redis и восстановите данные непосредственно на основе файла журнала AOF.
  • Если машина, на которой находится процесс redis, зависла, после перезагрузки машины попробуйте перезапустить процесс redis и попытаться выполнить восстановление данных непосредственно на основе файла журнала AOF.Если файл AOF поврежден, используйтеredis-check-aof fixисправить команду
  • Если файла AOF нет, он загрузит файл RDB.
  • Если текущие последние файлы AOF и RDB redis потеряны/повреждены, вы можете попытаться выполнить восстановление данных на основе текущей копии последних данных RDB на машине.

RDB vs AOF

Постоянство RDB и постоянство AOF были представлены выше, поэтому давайте рассмотрим их соответствующие преимущества и недостатки и как выбрать схему сохранения.

Преимущества и недостатки RDB и AOF

Что касается преимуществ и недостатков RDB и AOF, то официальный сайт также дает более подробное описаниеRedis.IO/topics/пирсинг…

RDB

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

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

недостаток:

  • Безопасность данных RDB не так хороша, как у AOF.Процесс сохранения всего набора данных более трудоемок.В соответствии с конфигурацией однократное создание моментального снимка может занять несколько минут.Если сервер выходит из строя, то несколько минуты данных могут быть потеряны.
  • Когда набор данных Redis большой, он потребляет ЦП и требует много времени для дочернего процесса fork для завершения моментального снимка.

AOF

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

  • Данные более полные, безопасность выше, а данные теряются за секунды (в зависимости от политики fsync, если она установлена ​​каждую секунду, данные будут потеряны на срок до 1 секунды)
  • Файл AOF представляет собой файл журнала только для добавления, а операция записи сохраняется в формате протокола Redis.Содержимое доступно для чтения и подходит для случайного удаления и аварийного восстановления.

недостаток:

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

Как выбрать RDB и AOF

  • Если данные не настолько конфиденциальны и могут быть восстановлены из другого места, сохранение можно отключить.
  • Если данные важнее, вы не хотите получать их из других мест, и вы можете терпеть потерю данных в течение нескольких минут, например, кэш и т. д., то вы можете использовать только RDB
  • Если он используется в качестве базы данных в памяти, следует использовать постоянство Redis.Рекомендуется включать и RDB, и AOF или выполнять их регулярно.bgsaveДля резервного копирования моментальных снимков метод RDB больше подходит для резервного копирования данных, AOF может гарантировать, что данные не будут потеряны.