Tarantool DataBase 3.1

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

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

В релизе Tarantool DataBase 3.1 добавлена базовая поддержка узлов-обработчиков, которые позволяют вынести бизнес-логику работы с данными отдельно от хранения данных в Tarantool DataBase. Кроме того, добавлена возможность проверки здоровья узлов кластера и репликации, а также поддержка идентификатора ULID.

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

• Узлы-обработчики;
• Безопасный режим работы кластера при балансировке сегментов;
• Проверка работоспособности кластера;
• Поддержка координатором отказоустойчивости синхронной репликации в топологии 2.5 ЦОДа;
• Идентификатор ULID;
• Улучшение примера шифрования трафика;
• Улучшение документации.

Подробная информация о продукте приведена в документации Tarantool DataBase.

В Tarantool DataBase 3.1.0 представлен новый тип экземпляров, который называется обработчик (worker). Узел-обработчик представляет собой Go-приложение, которое позволяет вынести бизнес-логику работы с данными отдельно от хранения данных в Tarantool DataBase и предоставляет удобный интерфейс для работы с базой данных. Такое приложение подключается к Tarantool DataBase через Go-коннектор и отслеживает изменения конфигурации и смену мастер-узла.

В Tarantool DataBase 3.1.0 попробовать работу с новым типом узлов можно в запускаемом Docker-примере tdb_worker. В примере запущены два узла-обработчика, у которых подключен мониторинг и интеграция с веб-интерфейсом Tarantool Cluster Manager (TCM). Для обработчиков настроен доступ к спейсу для чтения и записи данных. Чтобы продемонстрировать, как обработчики отслеживают изменения в конфигурации, в примере вручную добавлен новый экземпляр роутера.

Tarantool DataBase поддерживает отображение обработчиков в веб-интерфейсе TCM. В TCM обработчики отображаются на вкладке Stateboard в отдельной группе узлов workers.

Подробная информация об обработчиках и запускаемый Docker-пример работы с ними приведены в разделе Использование узлов-обработчиков.

Конфигурация каждого узла-обработчика задается в отдельном YAML-файле конфигурации и хранится по отдельному ключу в централизованном хранилище конфигурации — etcd или хранилище на основе Tarantool. Пример конфигурации узла может выглядеть так:

 
type: nontarantoolinstrumentation:    url:            worker-1:9080    metrics_url:    /metrics    metrics_format: "prometheus"    liveness_url:   /alive    info_url: /info    binary: ./bin/http-serverconfig:    addr: localhost:10000    tarantool_cluster_prefix: /tdb/config/all    tarantool_user: admin    tarantool_pass: secret-cluster-cookie

Секция config содержит произвольные поля, связанные с приложением, но при этом формат хранения конфигурации в централизованном хранилище строго определен.

В cекции instrumentation определены параметры мониторинга и интеграции с веб-интерфейсом TCM.

Обработчики в Tarantool DataBase поддерживают мониторинг своего состояния с помощью трех адресов обработчиков запросов (endpoints):

• /healthcheck — проверка работоспособности обработчика;
• /metrics — метрики экземпляра;
• /info — общая информация об обработчике.

Метрики и события журнала у обработчиков используют такой же формат, как и в самом Tarantool. Для отслеживания состояния узлов-обработчиков используются системные метрики Go.

В TCM просмотреть информацию об обработчике и его метрики можно на вкладке Stateboard, выбрав нужный экземпляр обработчика:

Подробная информация об изменениях и новой функциональности в веб-интерфейсе TCM приведена в документации TCM.

После изменения конфигурации шардированного кластера, например, при добавлении нового набора реплик или изменении веса шардов, начинается балансировка сегментов. При балансировке выполняется миграция сегментов — перенос сегментов с более нагруженных шардов на менее нагруженные.

Начиная с версии Tarantool DataBase 3.1.0 при старте балансировки кластер автоматически включает безопасный режим, чтобы обеспечить согласованность и целостность данных. Производительность кластера в этом режиме снижается (примерно на 15% для операций REPLACE). Безопасный режим включается независимо на каждом хранилище, участвующем в балансировке сегментов. Запросы к спейсам на движке vinyl всегда выполняются в безопасном режиме независимо от текущего статуса безопасного режима.

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

• вызвать метод crud.rebalance_safe_mode_status();
• проверить значение метрики tnt_crud_storage_safe_mode_enabled.

Чтобы вернуть кластер в нормальный режим работы после окончания процесса балансировки, выполните следующие шаги:

1. Дождитесь полного завершения миграции сегментов.

2. Очистите кэш карты маршрутов на каждом роутере:

    
   crud.rebalance.router_cache_clear()

   Проверить время последней очистки кэша можно с помощью метрики tnt_crud_router_cache_clear_ts.

3. Отключите безопасный режим вручную на каждом хранилище — как на мастер-узлах, так и на репликах:

    
   crud.rebalance_safe_mode_disable()

Кроме того, существуют следующие особенности, касающиеся балансировки сегментов:

• Поскольку во время миграции сегмента невозможно выполнять операции с кортежами в этом сегменте, CRUD-операции при балансировке могут завершаться с ошибками. Для исправления ошибок требуется повторно выполнить соответствующие запросы;

• Когда *_many-запрос выполняется над данными из нескольких шардов, на роутере эти данные автоматически разбиваются на пачки по шардам и параллельно отправляются на соответствующие узлы хранилища. Во время балансировки запрос может завершиться с ошибкой на некоторых хранилищах. В этом случае операция будет выполнена частично, а пользователю вернется ошибка с указанием хранилища, где не удалось выполнить запрос. Пользователю нужно быть готовым к тому, что операция может быть выполнена не полностью, и при необходимости повторить соответствующие запросы или выполнить другие необходимые действия;

• При выполнении операций SELECT во время балансировки часть записей в ответе может дублироваться или наоборот отсутствовать. Вероятность такого сценария увеличивается, если запросы на выборку выполняются по большому количеству шардов.

Начиная с версии Tarantool DataBase 3.1.0 работоспособность (здоровье) узлов кластера и репликации можно контролировать с помощью встроенного модуля healthcheck. Подробная информация о модуле и запускаемый Docker-пример работы с ним приведены в разделе Проверка работоспособности кластера.

Модуль позволяет:

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

Встроенные проверки модуля отслеживают:

• текущее состояние экземпляра (значение box.info.status);
• наличие директории для снимков данных snapshot.dir;
• наличие директории журнала упреждающей записи wal.dir;
• наличие upstream-узла, с которого принимаются данные репликации;
• репликационный статус текущего экземпляра (значение box.info.replication[{n}].upstream.status).

Для проверки здоровья узлов используется отдельная технологическая роль roles.healthcheck. Роль задается на экземплярах кластера и позволяет настроить HTTP-адрес обработчика запросов для отправки GET-запросов. Чтобы задать HTTP-сервер для запросов, используется модуль roles.httpd.

Настроить модуль можно в YAML-конфигурации кластера, указав роли roles.healthcheck и roles.httpd в секции roles, а также настройки этих ролей в roles_cfg:

 
roles_cfg:  roles.healthcheck:    http:      - endpoints:        - path: /healthcheck    set_alerts: true    checks:      include: [all]      exclude: ['replication.upstream_absent', 'replication.state_bad']   groups:  routers:    roles: [roles.httpd, roles.healthcheck]    replicasets:      router-msk:        leader: router-msk        instances:          router-msk:            roles_cfg:              roles.httpd:                default:                  listen: tarantool-router-msk:8181                  #...

Здесь:

• roles.healthcheck.http.endpoints.path — адрес обработчика запросов на работоспособность;
• healthcheck.http.set_alerts — включить оповещения в кластере при проблемах со здоровьем узла;
• healthcheck.http.checks.include и exclude — список запускаемых и отключенных проверок соответственно. В примере запускаются все проверки, кроме проверок репликации;
• roles.httpd.default.listen — адрес и порт, на которых запущен HTTP-сервер.

Полный список опций конфигурации для роли roles.healthcheck можно найти в Справочнике по конфигурации.

Начиная с версии Tarantool DataBase 3.1.0 в режиме восстановления после сбоев supervised добавлена поддержка синхронной репликации в спейсах для топологии с хранилищами данных в двух центрах обработки данных (ЦОД).

До версии Tarantool DataBase 3.1.0 координатор отказоустойчивости поддерживал синхронную репликацию для топологий только с тремя и более ЦОД. Если в наборе реплик было N экземпляров, минимальный размер кворума мог составлять N/2 + 1. Топологии с двумя ЦОД не поддерживались, поскольку размер кворума было невозможно динамически уменьшить при потере связи с одним из ЦОД. В минимальном наборе реплик из двух узлов размер кворума по умолчанию равен 2 (рассчитывается как 2/2 + 1 = 2). Если один из узлов вышел из строя, новые транзакции не могут пройти коммит из-за невозможности получить подтверждение от второго экземпляра. Новые транзакции при этом будут утеряны.

Начиная с версии Tarantool DataBase 3.1.0 поддерживается синхронная репликация для топологий с хранилищами данных, расположенными в двух ЦОД. При потере связи со вторым ЦОД координатор отказоустойчивости автоматически уменьшает размер кворума и восстанавливает работоспособность кластера в пределах доступного ЦОД. Когда связь со вторым ЦОД восстановлена, координатор отказоустойчивости автоматически возвращает нормальный размер кворума. Транзакции при этом не теряются.

При этом существуют следующие ограничения: хотя хранилища данных могут быть развернуты всего в двух ЦОД, требуется еще один так называемый кворумный ЦОД для дополнительного хранилища конфигурации на основе etcd или Tarantool. Таким образом, эффективная топология, также известная как топология 2,5 ЦОДа, подразумевает в общей сложности три ЦОД: два центра обработки данных с полным набором компонентов (хранилища данных, роутеры, хранилища конфигурации) и ЦОД с хранилищем конфигурации.

Ниже приведены сценарии, в которых топология с хранилищами данных, развернутыми в двух ЦОД, может выйти из строя. При других сценариях кластер продолжит работать.

Сценарий 1: прерывание обогащения данных после сбоя ЦОД

1. ЦОД #1 выходит из строя, ЦОД #2 при этом работает. Координатор отказоустойчивости уменьшает размер кворума до 1. Кластер продолжает обслуживать клиентов.
2. ЦОД #1 запускается и начинает получать недостающие данные с ЦОД #2. Размер кворума по-прежнему равен 1.
3. Процесс обогащения данных для ЦОД #1 все еще продолжается, но ЦОД #2 отключается. В этом случае кластер становится недоступен.

Сценарий 2: нет множественного уменьшения кворума

1. Отключается ЦОД #1 (2 узла), ЦОД #2 (2 узла) при этом работает.
2. Один из двух экземпляров в ЦОД #2 отключается. В этом случае кластер также становится недоступным.

Сценарий 3: оба ЦОД отключаются — крайний случай, когда кластер становится недоступен.

Начиная с Tarantool DataBase 3.1.0 добавлена поддержка модуля ulid — встроенного модуля платформы Tarantool. Идентификатор ULID — 128-битный универсальный уникальный лексикографически сортируемый идентификатор, который состоит из 48-битной временной метки в миллисекундах от эпохи Unix и 80-битной случайной части.

Идентификаторы ULID:

• лексикографически сортируются по времени создания;
• полностью помещаются в 26 ASCII-символов;
• избегают визуально неоднозначных символов, таких как I, L, O или U;
• имеют 128 бит общей уникальности – как UUID v4.

Строки ULID кодируются с использованием алфавита Crockford Base32. В бинарном виде ULID представлен 16-байтным значением в порядке байт big-endian. Это гарантирует, что лексикографический порядок бинарных ULID совпадает с их хронологическим порядком, как и требует спецификация ULID.

Tarantool использует монотонный генератор ULID. Если в пределах одной миллисекунды созданы несколько ULID, их значения строго возрастают с учетом порядка их создания.

Объекты ULID поддерживают полный набор операторов сравнения Lua: равенство и неравенство (== и ~=), а также лексикографическое сравнение (<, <=, > и >=). Сравнение работает как между объектами ULID, так и между объектом ULID и строкой ULID. Перед сравнением объекта ULID со строкой строка преобразуется в ULID.

 
ulid = require('ulid')tarantool> u1 = ulid.new()tarantool> u2 = ulid.new()tarantool> u1 < u2, u1 <= u2, u1 == u2, u1 ~= u2, u1 > u2, u1 >= u2---- true- true- false- true- false- false

Подробная информация о модуле ulid, справочник методов и примеры использования приведены в документации платформы Tarantool.

Для работы с ULID поддерживаются следующие методы и объекты модуля ulid:

• ulid.NULL — объект c нулевым ULID;
• ulid.new() или ulid.ulid() — создать новый объект ULID;
• ulid.str() и ulid.bin() — создать новый объект ULID и вернуть его строковое или бинарное представление;
• ulid.fromstr() и ulid.frombin() — создать объект ULID из 26-символьной строки или из 16-байтной бинарной строки;
• ulid_object:str() и ulid_object:bin() — вернуть ULID в виде 26-символьной строки или 16-байтной бинарной строки;
• ulid.is_ulid() — проверить, является ли переданное значение объектом ULID;
• ulid_object:isnil() — проверить, является ли ULID нулевым (все 16 байт равны нулю).

Подробная информация об этих методах приведена в справочнике по API.

В Tarantool DataBase 3.1.0 улучшен запускаемый пример traffic_encryption, демонстрирующий шифрование трафика. Теперь в примере поддерживается TLS-шифрование для следующий соединений:

• между узлами кластера Tarantool DataBase;
• между клиентами и узлами Tarantool DataBase;
• между веб-интерфейсом TCM и узлами Tarantool DataBase;
• между TCM и etcd (backend store);
• между узлами Tarantool DataBase и etcd (централизованным хранилищем конфигурации кластера);
• между пользователем и веб-интерфейсом TCM (HTTPS);
• между узлами Tarantool DataBase и системой Prometheus для экспорта метрик по протоколу HTTPS.

В примере также был добавлен мониторинг с экспортом метрик по SSL и информация о настройке поддерживаемых наборов шифров для соединений Tarantool DataBase и TCM.

В Tarantool DataBase 3.1.0 добавлены следующие разделы документации:

• Обновление схемы данных — общая информация и рекомендации по обновлению схемы данных, запускаемый пример обновления схемы данных с помощью утилиты tt CLI;
• Понижение версии схемы данных — рекомендации по понижению версии схемы данных;
• Шардирование — общая информация о механизме шардирования в Tarantool DataBase, архитектура и настройка конфигурации;
• Поиск кортежей в TCM — поиск кортежей по спейсу на вкладке Tuples и через SELECT-запрос с помощью модуля CRUD;
• Работа со словарями через пользователя с ограниченными правами — запускаемый Docker-пример, демонстрирующий запись, чтение, экспорт и импорт данных словарей через пользователя словарей.