Tarantool 3.2

Configuration validation

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)
    end
end

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")
    end
end

Protobuf encoder

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
    }
)

Next and Previous prefix iterators

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.

Tarantool configuration storage: TTL support for keys (EE)

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

Support for all UUID versions

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.

Interactive console

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'

Observability

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