Глава 6. Перманентность

В своей предыдущей главе мы изучили как настраивать Redis подчинённым для репликации данных с хозяина. С точки зрения избыточности данных для резервного копирования имеющихся данных могут применяться репликации данных Redis/

Для того чтобы сберегать свои данные в безопасности Redis также предоставляет механизм удержания (persist - перманентности) данных на диске. Существует два варианта удержания данных: RDB и AOF. RDB является снимком на некий момент времени данных Redis, что исключительно для резервного копирования и восстановления данных. AOF является неким журналом операций записи, которые будут повторно выполняться при запуске сервера.

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

Как мы уже описывали в своём предыдущем рецепте, для некоторого хранилища данных в оперативной памяти подобного Redis, включение свойств удержания является наилучшей защитой от утраты данных. Одним из очевидных способов реализации перманентности является создание время- от- времени моментальных снимков оперативной памяти, в которой хранятся наши данные. Именно таким способом в основном и работает в Redis RDB.

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

Вам требуется завершить установку своего Cервера Redis, которое мы описывали в своём рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis.

Для целей данной демонстрации вам следует сбросить все данные при помощи команды FLUSHALL, а затем мы наполним какими- то образцами данных свой экземпляр Redis применив инструментарий случайной генерации данных для Redis, введённый нами в рецепте Поиск неисправности репликации из Главы 5, Репликации:

for i in `seq 10`
do
nohup node generator.js hash 1000000 session &
done
 	   

Для манипуляций RDB основные шаги такие:

RDB работает подобно фотоаппарату для имеющейся оперативной памяти Redis. Когда достигается необходимая политика включения, выполняется некая фотография имеющихся в Redis данных путём вывода дампа в некий файл на текущем локальном диске. Прежде чем перейти к подробному рассмотрению данного процесса, мы для начала поясним те значения опции save, которые определяют установленную политику включения RDB, которые упомянуты в нашем предыдущем разделе. Соответствующий шаблон устанавливаемых значений выглядит как x¹, y¹, x², y²,..... Что означает, что выполнение дампа имеющихся данных в Redis осуществляется после x секунд если были изменены по крайней мере по крайней мере y ключей и нет никакого иного процессы выполнения дампа.

Для нашего предыдущего примера, 900 1 означает, что если по крайней мере 1 ключ был изменён в пределах 900 секунд, будет выполнен некий моментальный снимок. Мжет иметься более одной политики в соответствующей опции save для управления тем насколько часто выполняется моментальный снимок RDB.

Redis не выполняет соответствующий дамп пока не завершится в фоновом режиме самый последний сброс. Вам никогда не следует применять SAVE в своей промышленной реализации, так как он блокирует ваш Сервер Redis. Вместо этого, применив BGSAVE, имеющийся основной поток Redis продолжит обработку входящих команд пока создаётся посредством fork() некий дочерний процесс, который затем сохранит необходимый файл данных дампа в каом- то временном файле с названием temp-<bgsave-pid>.rdb. После того как этот процесс выполнения дампа завершится, данный временный файл будет переименован в то имя, которое определено настройкой dbfilename в том локальном каталоге, который задан настройкой dir для замены имеющегося старого дампа. Между прочим, эти две настройки можно изменять динамически из redis-cli.

Отслеживая свои процессы при помощи команды ps вы можете перехватить соответствующий процесс с установленным названием redis-rdb-bgsave, который ответвляется вашим Сервером Redis для выполнения BGSAVE. Этот дочерний процесс сохраняет все данные в то время, когда осуществляется соответствующая команда BGSAVE. Благодаря механизму COW (Copy-On-Write, Копирования- записью) нет необходимости для запущенного дочернего процесса применять такой же объём памяти, который имеет сам Сервер Redis.

На протяжении выполнения дампа мы можем воспользоваться INFO Persistence для получения соответствующих измерений выполняемого удержания. В данном примере значением rdb_bgsave_in_progress является 1, что указывает на тот факт, что выполняется процесс получения дампа. Значением rdb_current_bgsave_time_sec является то время, которое прошло при выполнении BGSAVE.

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

777:C 21 Oct 21:22:04.346 * RDB: 322 MB of memory used by copy-on-write
		

В основном оно исчисляет какой объём изменений выполнил родительский процесс по сравнению с дочерним (в том числе буферы чтения, буферы записи, изменения данных и тому подобного). В нашем примере мы выполняли наполнение Redis некими образцами данных на протяжении осуществления дампа, поэтому та память, которая использовалась COW (в соответствующей команде INFO) не является очень маленьким (для 2 ГБ данных в Redis, если ничего не записывается на протяжении дампа, как правило, COW использует 10- 20 МБ). Данное измерение также сохраняется в соответствующей метрике rdb_last_cow_size, получаемой в команде INFO.

По окончанию BGSAVE, соответствующее состояние самого последнего BGSAVE сохраняется в измерении rdb_last_bgsave_status, а временной штамп UNIX этого последнего успешного сохранения запоминается в rdb_last_save_time:

127.0.0.1:6379>  INFO Persistence
# Persistence
loading:0
rdb_changes_since_last_save:0
rdb_bgsave_in_progress:0
rdb_last_save_time:1508639640
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:20
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:15036416
		

Вот некоторые относящиеся к удержанию RDBварианты настройки. Вам рекомендуется оставлять установленные по умолчанию значения, которыми является значение yes для всех перечисленных ниже опций:

Тот дамп, который вырабатывается SAVE/BGSAVE можно применять в качестве некоего файла резервной копии данных. Вы можете применять crontab в своей операционной системе для периодического копирования получаемого файла RDB в какой- то локальный каталог или в удалённую распределённую файловую систему, например, Amazon S3/ HDFS для целей применения в дальнейшем:

cp /redis/data/dump.rdb /somewhere/safe/dump.$(date +%Y%m%d%H%M).rdb
		

Для восстановления некоего моментального снимка RDB вам придётся скопировать соответствующий файл в то местоположение, которое определено установкой параметра dir и установить необходимые полномочия чтения/ записи для данного файла тому пользователю, который запускает соответствующий экземпляр Redis. После этого от вас требуется остановить исполняемый экземпляр вызвав команду SHUTDOWN NOSAVE и переименовать свой новый файл дампа в то название, которое задаётся dbfilename. При перезапуске этот набор данных загружается в Redis из данного файла резервной копии.

Дополнительное обсуждение деталей относительно перманентности RDB вы можете отыскать на https://redis.io/topics/persistence

Если вам интересно то как работает COW в некоторой операционной системе, вы можете изучить подробности в en.wikipedia.org {Прим. пер.: или ознакомиться с нашими переводами Мастерство FreeBSD: ZFS Майкла В. Лукаса и Аллана Джуда или отдельных глав Мастерство SQL Server 2016 с высокой доступностью Пауля Бертуччи и Раджу Шривастава}

Мы уже изучили что посредством перманентности Redis выполняет дамп своих хранимых в памяти данных в некий файл с названием dump.rdb по умолчанию. Для начинающих этого может быть достаточно для понимания тех моментов, которые упоминаются в нашем предыдущем рецепте. Для тех чокнутых, которые страстно желают узнать подробнее о том как соответствующий файл RDB работает в качестве двоичного представления данных Redis в оперативной памяти имеется великолепное преимущество изучить сам формат RDB. В данном рецепте мы окунёмся в тонкости формата имеющегося файла RDB чтобы понять что мы можем делать со знаниями об имеющемся формате RDB.

Вам требуется завершить установку своего Cервера Redis, которое мы описывали в своём рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis.

Для исследования двоичного формата некоего файла необходим какой- то редактор бинарных файлов. В Linux Ubuntu наиболее распространённым бинарным редактором является bvi. Установите его следующим образом:

$ sudo apt-get install bvi
		

Для MacOS вы можете выгрузить HexFiend.

Для своих целей демонстрации необходимо выполнить сброс всех данных при помощи команды FLUSHALL.

Так как мы будем изучать свой файл RDB в шестнадцатеричном виде, следует просматривать символ ASCII в какой- то таблице ASCII. Великую помощь в этом оказывает вебсайт RapidTables.

Для изучения RDB необходимые шаги таковы:

Полученное содержимое dump.rdb отображено на следующем снимке экрана:

В нашем предыдущем примере в имеющемся экземпляре Redis были размещены некоторые образцы проверочных данных. После этого был создан некий дамп RDB посредством команды SAVE.

После этого мы ближе рассмотрим что имеется в RDB в не заземлённом виде при помощи двоичного редактора bvi в Linux. Всё содержимое нашего файла RDB было преобразовано bvi в шестнадцатеричный вид. Рассматривая самые первые пять чисел (52 45 44 49 53) одно за другим в таблице ASCII (RapidTables), мы можем заключить, что этими первыми символами являются REDIS:

Следующими четырьмя символами после нашей магической строки являются 30 30 30 38, которые указывают на значение версии формата RDB 0008. REDIS0008 является магической строкой какого- то файла RDB.

После этой магической строки имеется восемь видов метаданных, сохранённых в нашем файле RDB:

Между прочим, FA в этом файле RDB является неким вспомогательным кодом операции. После такого вспомогательного кода всегда имеется некая пара ключ- значение.

После сохранения необходимых метаданных для каждой базы данных из определённого Сервера Redis текущий процесс вывода дампа сохраняет получаемый индекс базы данных (в данном примере FE 00, указывающий значение индекса базы данных равным 00), код изменения размера хэша, а также код операции изменения размера базы данных, помимо срока истечения кода операции изменения размера. Затем стартует некая итерация для записи каждого элемента из Redis для записи в этот файл дампа. Соответствующий формат пары ключ- значение в Redis таков:

Ввиду ограничений в пространстве данной книги мы не будем вдаваться в подробности указанного вышк формата данных. Если вас это интересует, вы можете рассмотреть исходные коды файлов rdb.c и rdb.h.

Данный файл RDB завершается неким EOF и контрольной суммой CRC64.

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

Относительно дополнительных деталей формата RDB вы можете обратиться к https://github.com/sripathikrishnan/redis-rdb-tools/wiki/Redis-RDB-Dump-File-Format и https://github.com/leonchen83/redis-replicator/wiki/RDB-dump-data-format

Сам автор Redis, Antirez, также описывает архитектуру RDB: https://redis.io/topics/rdd-2

В наших двух предыдущих рецептах мы изучили варианты RDB для удержания данных Redis. Однако, использование RDB для перманентности не предоставляет очень сильной устойчивости. Как уже упоминалось, некий дамп данных RDB содержит только моментальный снимок данных Redis на какой- то момент времени. Хотя Redis выполняет дампы данных в свой файл RDB периодически, имеющиеся между двумя дампами RDB данные будут утрачены навсегда в случае падения процесса Redis или же при наличии некоего аппаратного отказа. AOF является неким дописываемым только в конец (append-only) файлом журнала, который регистрирует поступающие команды записи своего Сервера Redis. Значение надёжности данных AOF выше чем у RDB, так как все команды записи добавляются в конец этого файла. В данном рецепте мы покажем как вы можете включить AOF в Redis и ознакомим вас с некоторыми важными параметрами AOF.

Вам требуется завершить установку своего Cервера Redis, которое мы описывали в своём рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis.

Основные шаги по манипуляции AOF таковы:

Когда включена опция AOF, Redis создаст соответствующий файл AOF в своём каталоге данных Redis. Значением имени файла AOF по умолчанию является appendonly.aof, которое можно изменить установкой параметра appendfilename в имеющихся настройках Redis. Redis будет также наполнять этот файл AOF текущими данными в оперативной памяти.

Всякий раз когда Сервер Redis получает некую команду на запись, которая в результате приведёт к изменению реальных данных в памяти, он также добавляет в конец своего файла AOF эту команду. Однако, если мы получше взглянем на процесс записи файла, на самом деле основная операционная система сопровождает некий буфер, в который вначале записываются соответствующие команды Redis. Данные из этого буфера подлежат сбросу на соответствующий диск для сохранения на постоянной основе. Данный процесс выполняется в имеющейся операционной системе Linoc системным вызовом API fsync(), который является неким блокирующим вызовом до тех пор, пока соответствующее дисковое устройство не подтвердит что эти данные в текущем буфере сброшены успешно.

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

При останове Сервера Redis fsync() будет вызван в явном виде чтобы убедиться что все данные из буфера записи сброшены на диск.

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

При сохранении в конец своего файла AOF команд записи Redis, размер этого файла может значительно возрастать. Это замедляет соответствующий процесс воспроизведения при запуске Redis. Redis предоставляет некий механизм сжатия своего файла AOF с помощью некоторой AOF rewrite. Как вы можете предвосхитить, некоторые из имеющихся ключей Redis были удалены или истёк их срок, поэтому они могут быть вычищены из своего файла AOF. Соответствующие значения для определённых ключей Redis обновлялись множество раз, причём только самое последнее значение требуется сохранять в имеющемся файле AOF. Эта основная идея упаковки данных при некоторой перезаписи AOF. Мы можем воспользоваться командой BGREWRITEAOF для инициации такого процесса перезаписи или позволить Redis выполнять перезапись AOF автоматически. Мы обсудим перезаписи AOF в своём следующем рецепте.

В случае крушения основной операционной системы соответствующий файл AOF может быть разрушен или усечён. Redis предоставляет некий инструмент, redis-check-aof, который можно применять для исправления такого некорректного файла AOF. Для исправления файла AOF просто запустите:

$ bin/redis-check-aof --fix appendonly.aof
		

По следующей ссылке вы можете найти дополнительные обсуждения удержания AOF

Для пояснения удержания данных Redis самим автором написан блог-пост

Что касается fsync(): https://linux.die.net/man/2/fsync

В своём предыдущем рецепте мы изучили как устанавливать перманентность AOF в Redis. В этом рецепте мы собираемся бросить взгляд на само содержимое файла AOF и пояснить весь процесс перезаписи AOF.

Вам требуется завершить установку своего Cервера Redis, которое мы описывали в своём рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis.

Для целей данной демонстрации нам следует отключить AOF и вначале сбросить все данные при помощи команды FLUSHALL.

Основные шаги исследования AOF таковы:

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

На шаге 3 мы вызываем семь команд для манипуляции командами REDIS:

Когда мы открыли для инспекции свой файл AOF, мы обнаружили что содержимое этого файла выглядит теми командами, которые мы только что исполнили, причём в формате RESP, который мы ввели в рецепте Общее представление о протоколе Redis из Главы 1, Приступая к Redis.

Имеются два исключения:

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

Для выполнения перезаписи AOF от основного процесса Redis будет ответвлён некий дочерний процесс. Этот дочерний процесс создаст камкой- то новый файл AOF для сохранения своих результатов перезаписи, поэтому сам старый файл AOF не испытает воздействия в случае неудачной операции перезаписи. Имеющийся родительский процесс продолжит обслуживать обмен и будет выводить в дамп своего старого файла AOF команды записи. При ответвлении своего дочернего процесса применяется поддерживаемый механизм COW, поэтому он не потребует того же объёма памяти что и его предок. Тем не менее, благодаря такому механизму COW сам дочерний процесс не способен получить доступ к вновь получаемым данным после ветвления. Redis решает эту проблему позволяя своему родительскому процессу помещать команды записи которые он получает ветвления в некий буфер с названием aof_rewrite_buf_blocks. После того как его дочерний процесс завершает перезапись своего нового файла AOF, он отправляет некий сигнал своему процессу предку. Этот родительский процесс сбрасывает команды из aof_rewrite_buf_blocks в новый файл AOF, а затем заменяет свой старый файл AOF этим новым.

Помимо включения вручную перезаписи AOF с помощью команды BGREWRITEAOF, мы также можем настроить Redis на исполнение перезаписи AOF в автоматическом режиме. Этой цели служат два следующих параметра:

Команда INFO PERSISTENCE предоставляет много информации о перезаписи AOF. Например, aof_last_bgrewrite_status указывает значение состояния самой последней операции перезаписи AOF, aof_base_size является значением размера самого последнего файла AOF, aof_rewrite_buffer_length является размером aof_rewrite_buf_blocks, который мы упоминали выше:

127.0.0.1:6379> INFO PERSISTENCE
...
aof_enabled:1
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:0
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:6393856
aof_current_size:143
aof_base_size:143
aof_pending_rewrite:0
aof_buffer_length:0
aof_rewrite_buffer_length:0
aof_pending_bio_fsync:0
aof_delayed_fsync:0
		

Для получения сведений относительно прочих элементов информации перманентности AOF вы можете обратиться к https://redis.io/commands/info.

В предыдущих рецептах этой главы мы описали варианты удержания как RDB, так и AOF. Когда дело касается перманентности данных, всегда существуют различные моменты, которые вам следует принимать во внимание: утрата данных в случае некоего выхода из строя, стоимость производительности при сохранении данных, размер необходимого файла удержания, а также скорость восстановления данных. Что касается RDB, записываемые в Redis между двумя моментальными снимками данные могут быть утрачены. Значение латентности и стоимость памяти некоторого системного вызова fork() в RDB могут стать некоторой проблемой при высоком уровне обмена на запись и большом наборе данных. Однако при сопоставлении с AOF, некий файл дампа RDB занимает меньше дискового пространства и восстановление из какого- то дампа RDB выполняется быстрее. На самом деле, вы можете включить обе функциональности одновременно.

В данном рецепет мы рассмотрим как взять самое лучшее от обоих подходов удержания.

Вам требуется завершить установку своего Cервера Redis, которое мы описывали в своём рецепте Загрузка и установка Redis в Главе 1, Приступая к Redis. Потребуются также базовые знания как RDB, так и AOF.

В своём предыдущем примере в нашем экземпляре Redis были размещены некие образцы данных. После этого при помощи команды SAVE был создан некий дамп RDB, а имеющийся файл AOF был перезаписан посредством команды BGREWRITEAOF.

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

После этого мы проверили начальный и завершающий сегменты AOF при помощи редактора Vim. Соответствующие команды записи были сохранены в том виде AOF, который был описан в предыдущем рецепте Изучение AOF.

После включения обоиз методов RDB и AOF мы устанавливаем значение параметра настройки aof-use-rdb-preamble в yes чтобы разрешить новую функцию удержания смешанного формата, которая предоставляется начиная с Redis 4.x. После того как этот параметр установлен в значение yes, при перезаписи соответствующего файла AOF Redis вначале сбрасывает дамп своего набора данных в оперативной памяти в виде RDB в качестве некоей преамбулы AOF. После перезаписи Redis продолжит регистрацию в журнале всех команд записи в соответствующем файле AOF применяя обычный формат AOF. В таком виде смешанного формата ясно можно убедиться исследовав заголовок и хвост соответствующего файла AOF после перезаписи. Вначале применяется собственно формат RDB, в самом начале этого файла AOF в том случае, когда разрешено смешение форматов. Redis получает преимущества от такого смешения форматов удержания, так как он способен выполнять перезапись и загрузку необходимых данных более быстро благодаря более компактному формату RDB и в то же самое время придерживаясь преимуществ AOF для лучшей согласованности данных.

Для версий Redis, предшествующих 4.x, вы могли включать RDB и AOF одновременно для достижения большей сохранности. После появления Redis 4.x предлагается включать AOF с удержанием в смешанном формате. Обратите внимание, что нет смысла включать смешанный формат при отключении опции AOF, поскольку в такой файл AOF ничего не будет добавляться даже если вы вручную создадите этот файл AOF вызвав BGREWRITEAOF. Если вы можете жить с некоторыми возможными потерями данных, применение только RDB достигает наилучшей производительности. Более того, согласно автору Redis, Antirez, не рекомендуется применять только AOF для предотвращения утраты данных по причине ошибок в самом механизме AOF.

И, наконец, Redis гарантирует что выполнение дампа RDB и перезаписи AOF никогда не запускаются одновременно. При запуске Redis будет вначале всегда загружать свой файл AOF, если такой имеется, даже в случае когда включены оба варианта удержания и имеется также и соответствующий файл RDB. Это обусловлено тем, что имеющийся файл AOF рассматривается как предоставляющий более надёжную согласованность. При загрузке имеющегося файла AOF, в том случае, когда включено удержание в смешанном формате, Redis вначале проверяет самые первые пять символов AOF. Если ими являются REDIS, что представляет собой магическую строку некоего файла RDB, как это было описано в нашем рецепте Изучение RDB, такой файл AOF представляет собой смешанный формат. Наш Сервер Redis вначале загружает соответствующую часть RDB, а потом оставшуюся часть AOF.