Сохранение данных
Для обеспечения сохранения данных в Tarantool предусмотрены следующие возможности:
-
Запись каждого запроса на изменение данных в файл журнала упреждающей записи (write-ahead log, WAL) (файлы
.xlog).При отключении питания или непреднамеренном завершении работы экземпляра Tarantool база данных в памяти теряется. В таком случае Tarantool восстанавливает данные из WAL-файлов, считывая их и повторно выполняя запросы на изменение данных. Это называется «процессом восстановления».
-
Создание снимков внутреннего состояния, содержащих копию всего набора данных на диске для заданного момента времени (файлы
.snap).В процессе восстановления Tarantool загружает последний файл снимка, а затем считывает запросы из WAL-файлов, созданных после этого снимка. После создания нового снимка более ранние WAL-файлы можно удалить для освобождения места.
В этом разделе описывается настройка:
-
Создания снимков в разделе snapshot файла YAML-конфигурации.
-
Записи в WAL в разделе wal файла YAML-конфигурации.
Подробнее о механизме сохранения данных в Tarantool см. ниже в этой статье. Форматы WAL-файлов и файлов снимков подробно описаны в разделе Форматы файлов.
Пример на GitHub: snapshot
В этом разделе описывается, как задать настройки снимков в разделе snapshot файла YAML-конфигурации.
В Tarantool можно автоматизировать создание снимков. Автоматическое создание включено по умолчанию и настраивается двумя способами:
-
Новый снимок создается по истечении заданного периода (см. описание параметра snapshot.by.interval).
-
Новый снимок создается, когда размер всех WAL-файлов, созданных с момента последнего снимка, превышает заданный предел (см. описание параметра snapshot.by.wal_size).
Параметр snapshot.by.interval настраивает демона контрольных точек
(демон снимков состояния), который создает новый снимок каждые snapshot.by.interval секунд. Если для параметра
snapshot.by.interval задано значение 0, демон контрольных точек отключается.
Параметр snapshot.by.wal_size задает максимальный размер в байтах для всех WAL-файлов, созданных с момента последнего снимка.
При превышении этого размера демон контрольных точек создает снимок. Затем
сборщик мусора удаляет старые WAL-файлы.
В примере показано, как задать параметры snapshot.by.interval и snapshot.by.wal_size:
by:interval: 7200wal_size: 1000000000000000000
В этом примере новый снимок создается в двух случаях:
- Каждые 2 часа (каждые 7200 секунд).
- Когда размер всех WAL-файлов, созданных с момента последнего снимка, достигает 1e18 (1000000000000000000) байт.
Чтобы настроить каталог для хранения файлов снимков, используйте конфигурационный параметр
snapshot.dir.
В приведенном ниже примере показано, как явно указать каталог снимков для instance001:
instance001:snapshot:dir: 'var/lib/{{ instance_name }}/snapshots'
По умолчанию WAL-файлы и файлы снимков хранятся в одном каталоге: var/lib/{{ instance_name }}. Однако для них можно указать
разные каталоги. Например, снимки и журналы упреждающей записи можно разместить на разных жестких дисках для повышения
надежности:
instance001:snapshot:dir: '/media/drive1/snapshots'wal:dir: '/media/drive2/wals'
Ограничить количество снимков, хранящихся в каталоге snapshot.dir, можно с помощью параметра snapshot.count. При достижении заданного предела количества снимков сборщик мусора Tarantool удаляет самый старый файл снимка и все связанные WAL-файлы после создания нового снимка состояния.
В приведенном ниже примере снимок создается каждые два часа (каждые 7200 секунд), пока в каталоге snapshot.dir не накопится три
снимка. После создания нового снимка (четвертого) самый старый снимок и соответствующие WAL-файлы удаляются.
count: 3by:interval: 7200
Пример на GitHub: wal
В этом разделе описывается, как задать настройки WAL в разделе wal файла YAML-конфигурации.
Запись в WAL включена по умолчанию. Это означает, что при перезапуске экземпляра данные будут восстановлены. Запись в WAL настраивается с помощью конфигурационного параметра wal.mode.
Существует два режима, при которых включена запись в WAL:
write(по умолчанию) – включает WAL и записывает данные без ожидания их сброса на устройство хранения.fsync– включает WAL и гарантирует, что запись сохранена на устройстве хранения.
В приведенном ниже примере показано, как задать режим WAL write:
mode: 'write'dir_rescan_delay: 3cleanup_delay: 18000max_size: 268435456ext:new: trueold: truespaces:bands:old: falseiproto:listen:- uri: '127.0.0.1:3301'
Чтобы отключить запись в WAL, задайте для параметра wal.mode значение none.
Чтобы настроить каталог для хранения WAL-файлов, используйте конфигурационный параметр
wal.dir. В
приведенном ниже примере показано, как явно указать каталог для instance001:
instance001:wal:dir: 'var/lib/{{ instance_name }}/wals'
При репликации и в режиме горячего резерва Tarantool сканирует WAL-файлы на предмет изменений каждые wal.dir_rescan_delay секунд. В приведенном ниже примере показано, как задать интервал между сканированиями:
dir_rescan_delay: 3
Новый WAL-файл создается, когда текущий достигает размера, заданного параметром wal.max_size. Конфигурация для этого параметра может выглядеть следующим образом:
max_size: 268435456ext:new: trueold: truespaces:bands:old: falseiproto:listen:- uri: '127.0.0.1:3301'
В Tarantool демон контрольных точек создает новые снимки с заданным интервалом (см. snapshot.by.interval). После перезапуска экземпляра сборщик мусора Tarantool удаляет старые WAL-файлы.
Чтобы отложить немедленное удаление WAL-файлов, используйте конфигурационный параметр wal.cleanup_delay. Задержка исключает возможные ошибочные ситуации, когда мастер-узел удаляет WAL-файлы, необходимые репликам после перезапуска. В результате реплики синхронизируются с мастером быстрее после его перезапуска и им не нужно заново скачивать все данные.
В примере задержка установлена равной 5 часам (18000 секундам):
cleanup_delay: 18000max_size: 268435456ext:new: trueold: truespaces:bands:old: falseiproto:listen:- uri: '127.0.0.1:3301'
В Tarantool Enterprise можно хранить старый и новый кортежи для каждой выполненной CRUD-операции. Подробное описание и примеры расширений WAL приведены в разделе Расширения WAL.
См. также: конфигурационные параметры wal.ext.*.
Демон контрольных точек – это постоянно работающий
файбер. Демон контрольных точек составляет расписание
периодического создания снимков на основе
конфигурационных параметров
и скорости роста размера файлов. Если демон включен, он создает новые файлы
снимков (.snap) в соответствии с этим расписанием.
Работа демона контрольных точек основана на следующих конфигурационных параметрах:
-
snapshot.by.interval – новый снимок создается по истечении заданного периода.
-
snapshot.by.wal_size – новый снимок создается, когда размер всех WAL-файлов, созданных с момента последнего снимка, превышает заданный предел.
При необходимости демон контрольных точек также активирует сборщик мусора Tarantool, который удаляет старые снимки и WAL-файлы.
Сборщик мусора Tarantool может быть активирован демоном контрольных точек. Сборщик мусора Tarantool отслеживает снимки, которые требуется передать реплике или которые нужны другим потребителям. Когда файлы больше не нужны, сборщик мусора Tarantool удаляет их.
Этот сборщик мусора вызывается в следующих случаях:
-
Когда количество снимков достигает предела, заданного параметром snapshot.count. После создания нового снимка сборщик мусора Tarantool удаляет самый старый файл снимка и все связанные WAL-файлы.
-
Когда размер всех WAL-файлов, созданных с момента последнего снимка, достигает предела, заданного параметром snapshot.by.wal_size. При превышении этого размера демон контрольных точек создает снимок, после чего сборщик мусора Tarantool удаляет старые WAL-файлы.
При удалении старого файла снимка сборщик мусора Tarantool также удаляет все WAL-файлы (.xlog), удовлетворяющие следующим условиям:
- WAL-файлы старше файла снимка.
- WAL-файлы содержат информацию, присутствующую в файле снимка.
Сборщик мусора Tarantool также удаляет устаревшие .run-файлы vinyl.
Сборщик мусора Tarantool не удаляет файл в следующих случаях:
- Выполняется резервное копирование, и файл еще не был скопирован (см. Горячее резервное копирование).
- Выполняется репликация, и файл еще не передан реплике (см. Архитектура репликации),
- Реплика подключается.
- Реплика отстала. Прогресс каждой реплики отслеживается; если позиция реплики сильно отстает от актуальной, сервер приостанавливает удаление, чтобы дать ей возможность догнать. Если администратор приходит к выводу, что реплика окончательно вышла из строя, правильной процедурой будет перезапуск сервера или (предпочтительно) удаление реплики из кластера.