Tarantool 3.1

Дата выпуска: 16 апреля 2024 г.

Релизы на GitHub: 3.1.2, 3.1.1, 3.1.0

В релизе 3.1 продолжается развитие нового подхода к конфигурации кластера, представленного в версии 3.0, и добавляются следующие основные возможности и улучшения для редакций Community и Enterprise:

• Community Edition (CE)
• Улучшен опыт разработчиков при обработке ошибок с помощью модуля box.error.
• Добавлены числовые типы фиксированного размера: uint8, int8, uint16 и другие.
• Добавлена функциональность RPC для доступа к пользовательским ролям из конфигурации.
• Утилита tt, используемая для управления экземплярами, полностью совместима с последней версией Tarantool.
• Enterprise Edition (EE)
• Добавлен внешний координатор для автоматического и ручного переключения при сбое.

• Повышена стабильность работы с централизованной конфигурацией, хранящейся в etcd. .. 3-1-features-for-developers:

В этом релизе процесс обработки ошибок при разработке стал проще благодаря модулю box.error. Ниже перечислены наиболее значимые возможности и изменения.

В релизе 3.1 появилась возможность добавлять пользовательскую полезную нагрузку к ошибке. Полезная нагрузка передается в виде пар «ключ-значение», где ключ –- строка, а значение –- любой Lua-объект. В примере ниже ключ description используется для хранения пользовательской полезной нагрузки.

 
custom_error = box.error.new({ type = 'CustomInternalError',                               message = 'Internal server error',                               description = 'Some error details'  -- payload})

Получить значение поля полезной нагрузки можно через точечную нотацию:

 
tarantool> custom_error.description---- Some error details...

В релизе 3.1 упрощено создание цепочек ошибок. В более ранних версиях для указания причины ошибки использовался метод set_prev(error_object), например:

 
local ok, err = pcall(my_func)if not ok then    local err2 = box.error.new{type = "MyAppError", message = "my_func failed"}    err2:set_prev(err)    err2:raise()end

При таком подходе требуется создать новую ошибку без её выброса, затем указать её причину с помощью set_prev() и только после этого выбросить. Начиная с версии 3.1 при создании ошибки можно использовать новый аргумент prev:

 
local ok, err = pcall(my_func)if not ok then    box.error{type = "MyAppError", message = "my_func failed", prev = err}end

В релизе 3.1 появилась возможность повысить детализацию сериализации ошибок. До релиза 3.1 сериализованное представление ошибки содержало только сообщение об ошибке:

 
tarantool> box.error.new({ type = 'CustomInternalError', message = 'Internal server error'})---- Internal server error...

Начиная с версии 3.1 сериализованная ошибка также содержит другие поля, которые могут быть полезны при анализе ошибок:

 
tarantool> box.error.new({ type = 'CustomInternalError', message = 'Internal server error'})---- code: 0  base_type: CustomError  type: CustomInternalError  custom_type: CustomInternalError  message: Internal server error  trace:  - file: '[C]'    line: 4294967295...

При логировании ошибки с помощью встроенного модуля логирования выводится сообщение об ошибке, за которым следуют знак табуляции (\t) и все поля полезной нагрузки в виде JSON-объекта, например:

 
main/104/app.lua/tarantool I> Internal server error {"code":0,"base_type":"CustomError","type":"CustomInternalError", ... }

Поскольку это изменение может повлиять на поведение существующего кода, добавлена новая опция compat –- box_error_serialize_verbose. Чтобы попробовать повышенную детализацию сериализации ошибок, установите для этой опции значение new:

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

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

• uint8: целое число в диапазоне [0 .. 255].
• int8: целое число в диапазоне [-128 .. 127].
• uint16: целое число в диапазоне [0 .. 65,535].
• int16: целое число в диапазоне [-32,768 .. 32,767].
• uint32: целое число в диапазоне [0 .. 4,294,967,295].
• int32: целое число в диапазоне [-2,147,483,648 .. 2,147,483,647].
• uint64: целое число в диапазоне [0 .. 18,446,744,073,709,551,615].
• int64: целое число в диапазоне [-9,223,372,036,854,775,808 .. 9,223,372,036,854,775,807].
• float32: 32-битное число с плавающей точкой.
• float64: 64-битное число с плавающей точкой.

Новый модуль experimental.connpool предоставляет набор возможностей для удаленного подключения к любому экземпляру кластера или выполнения удаленных вызовов процедур на экземпляре, удовлетворяющем заданным критериям. Чтобы загрузить модуль experimental.connpool, используйте директиву require():

 
sharded_cluster:router-a-001> connpool = require('experimental.connpool')---...

В версии 3.1 этот модуль предоставляет следующий API:

• Функция connect() принимает имя экземпляра и возвращает активное подключение к этому экземпляру:

   
  sharded_cluster:router-a-001> conn = connpool.connect("storage-b-002")---...

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

   
  sharded_cluster:router-a-001> conn.space.bands:select({}, { limit = 5 })---

• • [3, 804, 'Ace of Base', 1987]

• [7, 693, 'The Doors', 1965]

• [9, 644, 'Led Zeppelin', 1968]

• [10, 569, 'Queen', 1970]

• Функция filter() возвращает имена экземпляров, удовлетворяющих заданным условиям. В примере ниже функция возвращает список экземпляров с ролью storage и указанным значением метки:

   
  sharded_cluster:router-a-001> connpool.filter({ roles = { 'storage' }, labels = { dc = 'east' }})---

• • storage-b-002

• storage-a-002

• Функция call() может использоваться для выполнения функции на удаленном экземпляре. В примере ниже указаны следующие условия для выбора экземпляра, на котором будет выполнена функция vshard.storage.buckets_count:

• Экземпляр имеет роль storage.

• Экземпляр имеет метку dc со значением west.

• Экземпляр доступен для записи. .. code-block:: tarantoolsession

  sharded_cluster:router-a-001> connpool.call('vshard.storage.buckets_count', nil, { roles = { 'storage' }, labels = { dc = 'west' }, mode = 'rw' }) sharded_cluster:router-a-001> connpool.call('vshard.storage.buckets_count', nil, { roles = { 'storage' }, labels = { dc = 'west' }, mode = 'rw' }) –-

  • 500 ...

Подробнее см. в описании модуля experimental.connpool.

В Tarantool 3.0 модуль config предоставляет возможность работать только с конфигурацией текущего экземпляра. Начиная с версии 3.1 можно получить список всех экземпляров, составляющих кластер, и конфигурацию любого экземпляра этого кластера.

Функция config:instances() выводит список всех экземпляров кластера:

 
sharded_cluster:router-a-001> require('config'):instances()---- storage-a-001:    group_name: storages    instance_name: storage-a-001    replicaset_name: storage-a  storage-b-002:    group_name: storages    instance_name: storage-b-002    replicaset_name: storage-b  router-a-001:    group_name: routers    instance_name: router-a-001    replicaset_name: router-a  storage-a-002:    group_name: storages    instance_name: storage-a-002    replicaset_name: storage-a  storage-b-001:    group_name: storages    instance_name: storage-b-001    replicaset_name: storage-b...

Чтобы получить указанное значение конфигурации для определенного экземпляра, передайте имя экземпляра в качестве аргумента в config:get():

 
sharded_cluster:router-a-001> require('config'):get('iproto', {instance = 'storage-b-001'})---- readahead: 16320  net_msg_max: 768  listen:  - uri: 127.0.0.1:3304  threads: 1  advertise:    peer:      login: replicator    client: null    sharding:      login: storage...

В Tarantool Enterprise Edition 3.1 добавлен внешний координатор аварийного переключения (failover coordinator), который отслеживает состояние кластера Tarantool и выполняет автоматическую смену лидера, если текущий лидер набора реплик недоступен.

Для работы координатора аварийного переключения параметр replication.failover должен быть установлен в значение supervised:

 
replication:  failover: supervised# ...

Чтобы запустить координатор аварийного переключения, выполните команду tarantool с опцией failover и передайте путь к YAML-файлу конфигурации:

 
$ tarantool --failover --config /path/to/config

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

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

 
failover:  call_timeout: 1  lease_interval: 15  renew_interval: 5  stateboard:    renew_interval: 1    keepalive_interval: 5

В релиз 3.1 добавлены новые опции шардирования, обеспечивающие дополнительную гибкость при настройке шардированного кластера. Новый параметр sharding.weight задает относительный объем данных, который может хранить набор реплик. В примере ниже набор реплик storage-a может хранить в два раза больше данных, чем storage-b:

 
# ...replicasets:  storage-a:    sharding:      weight: 2    # ...  storage-b:    sharding:      weight: 1    # ...

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

• auto (по умолчанию): если нет наборов реплик с ролью шардирования rebalancer (sharding.roles), набор реплик с ребалансировщиком будет выбран автоматически среди всех наборов реплик.
• manual: один из наборов реплик должен иметь роль шардирования rebalancer. Ребалансировщик будет находиться в этом наборе реплик.
• off: ребалансировка отключена независимо от того, существует ли набор реплик с ролью шардирования rebalancer или нет.

В этом релизе утилита tarantoolctl, используемая для администрирования экземпляров Tarantool, полностью удалена из пакетов Tarantool. Последняя версия утилиты tt полностью совместима с Tarantool 3.1 и покрывает весь необходимый функционал:

• Настройка среды разработки: инициализация среды и установка различных версий Tarantool.
• Различные возможности для разработки кластерных приложений: создание приложений на основе шаблонов, управление модулями, сборка и упаковка приложений.
• Управление экземплярами кластера: запуск и остановка экземпляров, подключение к удаленным экземплярам для администрирования и т. д.

• Импорт и экспорт данных (только для Enterprise Edition). Информация о том, как выполнить миграцию с tarantoolctl на tt, приведена в разделе tarantoolctl-migration-to-tt.