Сохранение данных 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 может гарантировать, что данные не будут потеряны.