Tarantool DataBase 3.3

Дата релиза: 20.10.26.

Tarantool Database 3.3 (Tarantool DB или TDB) — это мультипротокольная NoSQL СУБД, разработанная на основе Tarantool Enterprise Edition версии 3.x.

В релизе Tarantool Database 3.3 добавлен ряд новых возможностей и обновлений. В документе приведен краткий обзор наиболее заметных изменений и новой функциональности Tarantool Database, а также добавлена информация по процедуре обновления разных версий Tarantool Database 3.x.

Ключевые изменения:

• Восстановление данных на момент времени (PITR);
• Выполнение нескольких CRUD-операций в одной транзакции;
• Вызов хранимых функций на хранилище;
• Пример проверки целостности приложения;
• Пример миграции с изменением первичного индекса.

Подробная информация о продукте приведена в документации Tarantool Database. Отчет об испытаниях производительности можно прочитать в разделе Отчет Tarantool Database 3.3.0.

Начиная с версии Tarantool Database 3.3.0, поддерживается создание инкрементальных резервных копий и восстановление состояния базы данных на заданный момент времени (Point-in-time recovery, PITR) через консольную утилиту tt. При возникновении логической ошибки (например, после некорректной миграции, ошибки в коде или действий злоумышленника) данные невозможно восстановить переключением на работоспособный узел, поскольку такие ошибочные операции реплицируются на все узлы кластера. Механизм PITR позволяет вернуться к состоянию кластера до момента возникновения такой ошибки. Узнать больше: Резервное копирование и восстановление на момент времени.

Чтобы восстановление было согласованным, все наборы реплик восстанавливаются на один и тот же момент времени. Для этого используются точки восстановления (recovery point) — именованные метки времени в журналах упреждающей записи (WAL) резервной копии, которые периодически создаёт технологическая роль roles.recovery-point-manager. Кластер восстанавливается на точку, которая расположена ближе всего к запрошенному моменту времени и при этом не позднее этого времени.

При восстановлении на заданную точку Tarantool DB загружает последнюю полную резервную копию, созданную до этого момента, а поверх нее добавляет изменения из инкрементальных резервных копий до выбранной точки восстановления:

• полная резервная копия содержит снимок данных и журналы упреждающей записи (WAL), записанные после снимка до момента завершения резервного копирования. Полностью определяет состояние базы данных на момент создания копии;
• инкрементальная резервная копия содержит только записи в WAL, добавленные после создания предыдущей резервной копии. Создаётся быстрее и занимает меньше места, но для восстановления нужна полная цепочка копий, начиная с полной.

tt CLI выполняет резервное копирование и восстановление на узлах Tarantool и отдельном хосте-менеджере точек восстановления. Для оркестрации процесса по всему кластеру используются инсталлятор Ansible Tarantool Enterprise (ATE), скрипты или CI/CD. Начиная с версии ATE 1.22.0, инсталлятор поддерживает сценарии backup_pitr.yml (резервное копирование) и restore_pitr.yml (восстановление на момент времени).

Чтобы быстро запустить и попробовать работу с PITR, в Tarantool Database 3.3.0 добавлен запускаемый пример Резервное копирование и восстановление на момент времени (PITR). В примере в одной цепочке созданы полная и инкрементальная резервные копии, а затем выполнено восстановление на заданную точку. Подробное описание примера и файлы конфигурации для его запуска доступны в репозитории tarantool/tarantooldb-examples на GitHub.

В Tarantool Database 3.3.0 добавлен метод crud.atomic_batch(), который выполняет упорядоченный пакет простых CRUD-операций над разными спейсами в рамках одной транзакции в одном сегменте. Метод поддерживает только операции записи (insert, replace, update, upsert и delete), а также точечное чтение get. Массовые операции чтения (select, pairs, count) не поддерживаются. Все операции в пакете должны иметь одинаковый bucket_id.

Если хотя бы одна операция завершается ошибкой, вся транзакция откатывается. Пакет с разными значениями bucket_id отклоняется на этапе проверки на роутере. Сочетание спейсов на движках memtx и vinyl в одном пакете требует обязательного включения MVCC.

Отследить работу метода можно по двум группам метрик:

• tnt_crud_atomic_batch_sub_ops* — статистика выполнения вложенных операций. Включает статус и время выполнения операции, ее задержку, а также число вложенных операций;
• tnt_crud_stats_* (с указанием типа операции operation = "atomic_batch") — число вызовов и время выполнения метода на роутере.

Пример:

 
local crud = require('crud')local operations = {    { type = 'get',    space = 'users',  key = { 42 } },    { type = 'insert', space = 'orders', tuple = { 10001, box.NULL, 42, 'created', 1500 } },    { type = 'insert', space = 'audit_log', object = {        id = 5001, user_id = 42, order_id = 10001, event = 'ORDER_CREATED', created_at = os.time()    } },}local res, err = crud.atomic_batch(operations, { timeout = 1.5 })

Здесь:

• operations — упорядоченный массив операций;
• timeout — время ожидания на выполнение всего пакета в секундах.

В Tarantool Database 3.3.0 добавлены методы crud.storage_call() и crud.storage_call_many(), которые вызывают персистентные хранимые функции из box.func на мастер-узле набора реплик, которому принадлежит сегмент. Метод crud.storage_call() выполняет одну хранимую функцию, а crud.storage_call_many() — пакет вызовов. Для одного набора реплик вызовы выполняются последовательно, а для разных наборов реплик — параллельно. Маршрутизация вызова задаётся идентификатором сегмента (bucket_id) или парой space_name и key.

Хранимая функция должна соответствовать условиям ниже:

• функция создана в box.func с сохранённым телом (body);
• функция задана миграцией на всех хранилищах, где может находиться сегмент. Если после переноса сегмента функции не будет на нужном хранилище, вызов не будет выполнен;
• опция setuid задана со значением setuid = false;
• функция должна завершать собственную локальную транзакцию. Если она оставит транзакцию открытой, модуль CRUD откатит её и вернёт ошибку вызова. Уже зафиксированные изменения не откатываются. При вызове метода crud.storage_call_many() ошибка одного элемента пакета не откатывает уже зафиксированные изменения;
• пользователь, вызвавший метод crud.storage_call() или crud.storage_call_many(), должен иметь права на вызов хранимой функции (execute). На роутере нужно выдать права на вызов метода crud.storage_call() или crud.storage_call_many() соответственно.

Чтобы быстро запустить и попробовать добавленные методы, в Tarantool Database 3.3.0 добавлен запускаемый Docker-пример Вызов функций на хранилищах с помощью CRUD. Подробное описание примера и файлы конфигурации для его запуска доступны в репозитории tarantool/tarantooldb-examples на GitHub.

Пример с маршрутизацией по первичному ключу спейса:

 
crud.storage_call(  'app.get_balance', {101},  {    space_name = 'accounts',    key = {101},  })

Здесь:

• app.get_balance — имя хранимой функции в box.func;
• {101} — массив аргументов функции (параметр args);
• space_name — спейс, по первичному ключу которого вычисляется сегмент;
• key — значение первичного ключа в этом спейсе.

Результаты испытаний производительности методов приведены в отчёте по методу storage_call.

Tarantool Database поддерживает контроль целостности компонентов приложения во время его работы. При упаковке архива приложения утилита tt CLI генерирует файлы с хешами всех компонентов приложения, используя опцию --with-integrity-check. При запуске Tarantool Database с опцией --integrity-check экземпляры кластера периодически сверяют эти хеши и при обнаружении изменений переходят в нерабочее состояние (статус узла NOT RUNNING при вызове команды tt status).

Проверка целостности также поддерживается при использовании централизованного хранилища конфигурации на основе etcd или Tarantool (TbCS). В этом случае также проверяется конфигурация кластера, загруженная в хранилище.

Чтобы быстро запустить и попробовать эту функциональность, в Tarantool Database 3.3.0 добавлен запускаемый пример Проверка целостности приложения при его запуске. Подробное описание примера и файлы конфигурации для его запуска доступны в репозитории tarantool/tarantooldb-examples на GitHub.

Tarantool Database позволяет изменить первичный индекс существующего спейса без потери данных при помощи миграций. Данные при этом копируются в новый одноимённый спейс, а имя старого спейса обновляется.

Чтобы быстро запустить и попробовать эту функциональность, в Tarantool Database 3.3.0 добавлен запускаемый Docker-пример Изменение первичного индекса для существующего спейса. Запись на время миграции останавливать не требуется. Миграция в примере реализована путем создания нового спейса и копирования данных в него. Для спейсов на движке memtx это приводит к удвоенному потреблению памяти этим спейсом на время миграции. Подробное описание примера и файлы конфигурации для его запуска доступны в репозитории tarantool/tarantooldb-examples на GitHub.