Tarantool 3.3

Дата выпуска: 29 ноября 2024 г.

Релизы на GitHub: 3.3.1, 3.3.0

В релизе 3.3 Tarantool добавлены следующие основные возможности и улучшения для редакций Community и Enterprise:

• Community Edition (CE)
• Улучшения запросов со смещением.
• Улучшение реализации Raft.
• Сохраняемое состояние репликации.
• Новый C API для отправки задач в TX-поток из пользовательских потоков.
• JSON-схема конфигурации кластера.
• Новая функция обратного вызова on_event в прикладных ролях.
• API для пользовательских оповещений.
• Режим изолированного экземпляра.
• Автоматическое исключение экземпляров.
• Новый параметр конфигурации для размера памяти Lua.
• Enterprise Edition (EE)
• Улучшения, связанные со смещением, в представлениях для чтения.
• Улучшения контролируемого аварийного переключения.

В Tarantool 3.3 добавлен ряд улучшений для запросов со смещением.

• Повышена производительность метода select() древовидного индекса со смещением и метода count(). Ранее сложность алгоритма имела линейную зависимость от заданного смещения (O(offset)) или количества подсчитываемых кортежей. Теперь сложность нового алгоритма составляет O(log(size)), где size –- количество кортежей в индексе. Это изменение также устраняет зависимость от значения смещения или количества подсчитываемых кортежей.

• Сущности index и space получили новый метод offset_of, который возвращает позицию кортежа, соответствующего заданному ключу, относительно заданного направления итератора.

   
  -- index: {{1}, {3}}index:offset_of({3}, {iterator = 'eq'})  -- returns 1: [1, <3>]index:offset_of({3}, {iterator = 'req'}) -- returns 0: [<3>, 1]

• В метод index:pairs() добавлен параметр offset,

: позволяющий пропустить первые кортежи в итераторе.

Аналогичные улучшения добавлены и для представлений для чтения в редакции Enterprise.

• Повышена производительность метода select() для снимков индекса для чтения со смещением.
• Добавлен новый метод offset_of() для снимков индекса для чтения.
• Добавлен новый параметр offset в метод index_read_view:pairs().

Для большего соответствия канонической конструкции алгоритма Raft в Tarantool синхронные транзакции больше не откатываются по тайм-ауту (при достижении replication.synchro_timeout). В новой реализации транзакции могут быть отменены только новым лидером после его выбора. В остальных случаях они могут ожидать кворум бесконечно.

В связи с этим изменением поведения добавлен новый параметр compat –- replication_synchro_timeout. Чтобы попробовать новое поведение, задайте для этого параметра значение new:

• В YAML-конфигурации:

   
  compat:  replication_synchro_timeout: new

• В Lua-коде:

 
tarantool> require('compat').replication_synchro_timeout = 'new'---...

Также добавлен новый параметр конфигурации replication.synchro_queue_max_size, ограничивающий общий размер транзакций в синхронной очереди мастера. Значение по умолчанию –- 16 мегабайт.

Новые публичные функции C API tnt_tx_push() и tnt_tx_flush() позволяют отправлять задачи в TX-поток из любого другого потока:

• tnt_tx_push() планирует выполнение заданной функции обратного вызова с указанными аргументами.
• tnt_tx_flush() отправляет все ожидающие функции обратного вызова на выполнение в TX-поток. Выполнение начинается в том же порядке, в котором функции обратного вызова были добавлены.

Схема конфигурации кластера Tarantool теперь доступна в формате JSON. Схема содержит параметры конфигурации определенной версии Tarantool с описаниями. На дату выпуска Tarantool 3.3 доступны следующие версии:

• 3.0.0
• 3.0.1
• 3.0.2
• 3.1.0
• 3.1.1
• 3.1.2
• 3.2.0
• 3.2.1
• 3.3.0

Кроме того, доступна схема latest, которая отражает последнюю схему конфигурации в разработке (ветка master).

Эти схемы можно использовать для добавления автодополнения в YAML-файлах конфигурации, получения подсказок с описаниями параметров в IDE, а также для валидации конфигурации, например, с помощью check-jsonschema:

 
$ check-jsonschema --schemafile https://download.tarantool.org/tarantool/schema/config.schema.3.3.0.json config.yaml

Также добавлен новый API для генерации JSON-схемы конфигурации в виде Lua-таблицы –- функция config:jsonschema().

Теперь прикладные роли могут содержать функцию обратного вызова on_event. Они выполняются каждый раз при рассылке системного события box.status или при обновлении конфигурации. Функция обратного вызова принимает три аргумента:

• config –- текущая конфигурация.

• key –- событие, инициированный обратный вызов (triggered callback): config.apply или box.status.

• value –- значение системного события box.status. Пример:

 
return {    name = 'my_role',    validate = function() end,    apply = function() end,    stop = function() end,    on_event = function(config, key, value)        local log = require('log')        log.info('on_event is triggered by ' .. key)        log.info('is_ro: ' .. value.is_ro)        log.info('roles_cfg.my_role.foo: ' .. config.foo)    end,}

Теперь разработчики могут создавать собственные оповещения из приложений или прикладных ролей. Для этого в модуль config добавлен новый API.

Функция config:new_alerts_namespace() создает новое пространство имен оповещений –- именованный контейнер для пользовательских оповещений:

 
local config = require('config')local alerts = config:new_alerts_namespace('my_alerts')

Пространства имен оповещений предоставляют методы для управления оповещениями внутри них. Все пользовательские оповещения, созданные во всех пространствах имен, отображаются в box.info.config.alerts.

Для создания оповещения используйте методы пространства имен add() или set(): Разница между ними в том, что set() принимает ключ для последующей ссылки на оповещение: чтобы перезаписать или удалить его. Оповещение представляет собой таблицу с одним обязательным полем message (его значение записывается в лог) и произвольными пользовательскими полями.

 
-- Raise a new alert.alerts:add({    message = 'Test alert',    my_field = 'my_value',})-- Raise a new alert with a key.alerts:set("my_alert", {    message = 'Test alert',    my_field = 'my_value',})

Удалить оповещения можно по отдельности по ключам с помощью метода unset() или все сразу с помощью clear():

 
alerts:unset("my_alert")alerts:clear()

Начиная с версии 3.3, Tarantool разрешает операции DDL до вызова box.schema.upgrade() при обновлении, если версия исходной схемы –- 2.11.1 или выше. Это позволяет, например, предоставлять права на выполнение пользовательских функций в конфигурации кластера до обновления схемы.

Новый параметр конфигурации на уровне экземпляра isolated переводит экземпляр в изолированный режим. В этом режиме экземпляр не принимает обновления от других участников набора реплик и другие iproto-запросы. Он также не выполняет фоновые изменения данных и остается в режиме только для чтения.

 
groups:  group-001:    replicasets:      replicaset-001:        instances:          instance-001: {}          instance-002: {}          instance-003:            isolated: true

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

Новый раздел конфигурации replication.autoexpel позволяет автоматически исключать экземпляры после их удаления из YAML-конфигурации.

 
replication:  autoexpel:    enabled: true    by: prefix    prefix: '{{ replicaset_name }}'

Раздел включает три параметра:

• enabled: включает ли логику автоматического исключения в кластере.
• by: критерий выбора экземпляров, которые могут быть исключены автоматически. В версии 3.3 единственный доступный критерий –- prefix.
• prefix: префикс, с которого должно начинаться имя экземпляра для возможности автоматического исключения.

Новый параметр конфигурации lua.memory задает максимальный объем памяти для выполнения Lua-скриптов в байтах. Например, эта конфигурация устанавливает лимит памяти Lua в 4 ГБ:

 
lua:  memory: 4294967296

Лимит по умолчанию –- 2 ГБ.

В Tarantool 3.3 добавлен ряд улучшений контролируемого аварийного переключения:

• Поддержка табло (stateboard) на базе Tarantool в качестве альтернативы etcd.

• Конфигурация приоритета экземпляров: новый раздел конфигурации failover.priority. Этот раздел задает относительный порядок назначения экземпляров координатором: большие значения означают более высокий приоритет.

   
  failover:  replicasets:    replicaset-001:      priority:        instance-001: 5        instance-002: -5        instance-003: 4

  Кроме того, добавлен раздел failover.learners, в котором перечислены экземпляры, которые никогда не должны назначаться лидерами набора реплик:

   
  failover:  replicasets:    replicaset-001:      learners:

• instance-004

• instance-005

• Автоматическое обновление конфигурации аварийного переключения.

• Конфигурация журналирования аварийного переключения с новыми параметрами конфигурации failover.log.to

: и failover.log.file:

 
``` yamlfailover:  log:    to: file # or stderr    file: var/log/tarantool/failover.log```

Подробнее о контролируемом аварийном переключении см. в repl_supervised_failover.

Механизм сохранения Tarantool использует два типа файлов: снимки и файлы журнала предзаписи (WAL). Эти файлы также используются для репликации: реплики только для чтения получают изменения данных от лидера набора реплик, читая эти файлы.

Сборщик мусора очищает устаревшие снимки и WAL-файлы, но не удаляет файлы, пока они используются для репликации. Чтобы сделать такую проверку возможной, лидеры набора реплик хранят состояние репликации в связке с файлами. Однако эта информация не сохранялась на диске, что могло приводить к проблемам при перезапуске лидера. Сборщик мусора мог удалить WAL-файлы после перезапуска, даже если были реплики, которые все еще читали эти файлы. Для предотвращения таких ситуаций использовался параметр конфигурации wal.cleanup_delay.

Начиная с версии 3.3, экземпляры-лидеры сохраняют информацию об используемых WAL-файлах в новом системном спейсе _gc_consumers. После перезапуска состояние репликации восстанавливается, и WAL-файлы, необходимые для репликации, защищаются от сборки мусора. Это устраняет необходимость сохранения всех WAL-файлов после перезапуска, поэтому параметр wal.cleanup_delay теперь считается устаревшим.