Tarantool 3.2

Release date: August 26, 2024

Releases on GitHub: 3.2.1, 3.2.0

The 3.2 release of Tarantool adds the following main product features and improvements for the Community and Enterprise editions:

• Community Edition (CE)
  • A new experimental module for validating role configurations.
  • Initial support for encoding structured data using Protobuf.
  • Next and Previous prefix iterators.
  • Support for all UUID versions.
  • Automatic loading of the most often used built-in modules into the console environment.
• Enterprise Edition (EE)
  • Time-to-live (TTL) for keys in a Tarantool-based configuration storage.

Tarantool 3.2 includes a new experimental module for validating role configurations using a declarative schema. For example, you can validate the type of configuration values, provide an array of allowed values, or specify a custom validation function.

Suppose, a sample 'http-api' custom role can accept the host and port configuration values:

 
roles: [ http-api ]roles_cfg:  http-api:    host: '127.0.0.1'    port: 8080

First, you need to load the experimental.config.utils.schema module:

 
local schema = require('experimental.config.utils.schema')

The validate_port() function can be used to check that a port value is between 1 and 65535:

 
local function validate_port(port, w)    if port <= 1 or port >= 65535 then        w.error("'port' should be between 1 and 65535, got %d", port)    endend

Then, you can create a schema used for validation:

• host should be one of the specified string values.
• port should be a number that is checked using the validate_port() function declared above.

 
local listen_address_schema = schema.new('listen_address', schema.record({    host = schema.enum({ '127.0.0.1', '0.0.0.0' }),    port = schema.scalar({        type = 'integer',        validate = validate_port,    }),}))

Finally, you can pass the specified schema to the validate() role's function:

 
local function validate(cfg)    if cfg.host and cfg.port then        listen_address_schema:validate(cfg)    else        error("You need to set both host and port values")    endend

The 3.2 release adds initial support for encoding structured data using Protocol buffers. First, you need to load the protobuf module:

 
local protobuf = require('protobuf')

To encode data, you need to define a protocol:

 
local customer_protocol = protobuf.protocol({    -- Define a message and enum --})

The two main components of the protocol are messages and enums:

• A message specifies the structure of data, in particular, the fields and their types.
• An enum defines a set of enumerated constants within the message.

To create a message and enum, use the message() and enum() functions, respectively:

 
local customer_protocol = protobuf.protocol({    protobuf.message('Customer', {        id = { 'int32', 1 },        firstName = { 'string', 2 },        lastName = { 'string', 3 },        customerType = { 'CustomerType', 4 }    }),    protobuf.enum('CustomerType', {        active = 0,        inactive = 1,    })})

Once the protocol is specified, use the encode() method to encode data:

 
local sample_customer = customer_protocol:encode(    'Customer',    {        id = 3,        firstName = 'Andrew',        lastName = 'Fuller',        customerType = 1    })

This release adds two new iterators for TREE indexes: np (next prefix) and pp (previous prefix). If a key is a string value, a prefix is a common starting substring shared by multiple keys.

Suppose, the products space contains the following values:

 
application:instance001> box.space.products:select()---- - ['clothing_pants']  - ['clothing_shirt']  - ['electronics_laptop']  - ['electronics_phone']  - ['electronics_tv']  - ['furniture_chair']  - ['furniture_sofa']  - ['furniture_table']...

If you use the np iterator type and set the key value to electronics, the output should look as follows:

 
application:instance001> box.space.products:select({ 'electronics' }, { iterator = 'np' })---- - ['furniture_chair']  - ['furniture_sofa']  - ['furniture_table']...

Similarly, you can use the pp iterator:

 
application:instance001> box.space.products:select({ 'electronics' }, { iterator = 'pp' })---- - ['clothing_shirt']  - ['clothing_pants']...

Note that new iterators work only for the memtx engine.

The Enterprise Edition now includes a time-to-live (TTL) for keys in a Tarantool-based configuration storage. You can specify a TTL value in the config.storage.put() call as follows:

 
config.storage.put('/foo/bar', 'v1', { ttl = 60 })

Similarly, you can configure TTL in config.storage.txn():

 
config.storage.txn({    predicates = { { 'revision', '==', revision } },    on_success = { { 'put', '/foo/bar', 'v1', { ttl = 60 } } }})

A new config.storage.info.features.ttl field allows you to check whether the current version of the configuration storage supports requests with TTL. In the example below, the conn:call() method is used to make a remote call to get the ttl field value:

 
local info = conn.call('config.storage.info')if info.features == nil or not info.features.ttl then    error('...')end

Before the 3.2 version, Tarantool supported only UUIDs following the rules for RFC 4122 version 4. With v3.2, UUID values of all versions (including new 6, 7, and 8) can be parsed using the uuid module. This improves interoperability with third-party data sources whose data is processed by Tarantool.

With this release, both the Tarantool and tt interactive consoles automatically add the most often used built-in modules into the environment. This means that you can start using a module without loading it with the require directive.

In the interactive session below, the config module is used to get the instance's configuration state right after connecting to this instance:

 
application:instance001> config:info('v2')---- status: ready  meta:    last: &0     active: *0  alerts: ...

To enable this new behavior, you need to set the console_session_scope_vars compat option value to new:

 
compat:  console_session_scope_vars: 'new'

The 3.2 release adds the following improvements related to observability:

• A new box.info.config field allows you to access an instance's configuration status.
• box.info.synchro.queue now includes the age and confirm_lag fields:
  • age – shows how much time the oldest entry in the queue has spent waiting for the quorum.
  • confirm_lag – shows how much time the latest successfully confirmed entry has waited for the quorum to gather.
• New metrics are added:
  • tnt_memtx_tuples_data_total
  • tnt_memtx_tuples_data_read_view
  • tnt_memtx_tuples_data_garbage
  • tnt_memtx_index_total
  • tnt_memtx_index_read_view
  • tnt_vinyl_memory_tuple
  • tnt_config_alerts
  • tnt_config_status