Configuration

Basic instance configuration

The example below shows a sample configuration of a single Tarantool instance:

groups:
  group001:
    replicasets:
      replicaset001:
        instances:
          instance001:
            iproto:
              listen:
              - uri: '127.0.0.1:3301'

• The instances section includes only one instance named instance001. The iproto.listen.uri option sets an address used to listen for incoming requests.
• The replicasets section contains one replica set named replicaset001.
• The groups section contains one group named group001.

Configuration scopes

This section shows how to control a scope the specified configuration option is applied to. Most of the configuration options can be applied to a specific instance, replica set, group, or to all instances globally.

• Instance

  To apply specific configuration options to a concrete instance, specify such options for this instance only. In the example below, iproto.listen is applied to instance001 only.

  groups:
    group001:
      replicasets:
        replicaset001:
          instances:
            instance001:
              iproto:
                listen:
                - uri: '127.0.0.1:3301'
  

• Replica set

  In this example, iproto.listen is in effect for all instances in replicaset001.

  groups:
    group001:
      replicasets:
        replicaset001:
          iproto:
            listen:
            - uri: '127.0.0.1:3301'
          instances:
            instance001: { }
  

• Group

  In this example, iproto.listen is in effect for all instances in group001.

  groups:
    group001:
      iproto:
        listen:
        - uri: '127.0.0.1:3301'
      replicasets:
        replicaset001:
          instances:
            instance001: { }
  

• Global

  In this example, iproto.listen is applied to all instances of the cluster.

  iproto:
    listen:
    - uri: '127.0.0.1:3301'
  
  groups:
    group001:
      replicasets:
        replicaset001:
          instances:
            instance001: { }
  

Configuration scopes above are listed in the order of their precedence – from highest to lowest. For example, if the same option is defined at the instance and global level, the instance’s value takes precedence over the global one.

Configuration scopes: Replica set example

The example below shows how specific configuration options work in different configuration scopes for a replica set with a manual failover. You can learn more about configuring replication from Replication tutorials.

credentials:
  users:
    replicator:
      password: 'topsecret'
      roles: [replication]

iproto:
  advertise:
    peer:
      login: replicator

replication:
  failover: manual

groups:
  group001:
    replicasets:
      replicaset001:
        leader: instance001
        instances:
          instance001:
            iproto:
              listen:
              - uri: '127.0.0.1:3301'
          instance002:
            iproto:
              listen:
              - uri: '127.0.0.1:3302'
          instance003:
            iproto:
              listen:
              - uri: '127.0.0.1:3303'

• credentials (global)

  This section is used to create the replicator user and assign it the specified role. These options are applied globally to all instances.

• iproto (global, instance)

  The iproto section is specified on both global and instance levels. The iproto.advertise.peer option specifies the parameters used by an instance to connect to another instance as a replica, for example, a URI, a login and password, or SSL parameters . In the example above, the option includes login only. An URI is taken from iproto.listen that is set on the instance level.

• replication (global)

  The replication.failover global option sets a manual failover for all replica sets.

• leader (replica set)

  The <replicaset-name>.leader option sets a master instance for replicaset001.

Enabling and configuring roles

An application role is a Lua module that implements specific functions or logic. You can turn on or off a particular role for certain instances in a configuration without restarting these instances.

There can be built-in Tarantool roles, roles provided by third-party Lua modules, or custom roles that are developed as a part of a cluster application. This section describes how to enable and configure roles. To learn how to develop custom roles, see Application roles.

roles: [ roles.crud-router ]

roles: [ roles.crud-storage ]

roles: [ roles.crud-router ]
roles_cfg:
  roles.crud-router:
    stats: true
    stats_driver: metrics
    stats_quantiles: false
    stats_quantile_tolerated_error: 0.001
    stats_quantile_age_buckets_count: 5
    stats_quantile_max_age_time: 180

Predefined variables

In a configuration file, you can use the following predefined variables that are replaced with actual values at runtime:

• instance_name
• replicaset_name
• group_name

To reference these variables in a configuration file, enclose them in double curly braces with whitespaces. In the example below, {{ instance_name }} is replaced with instance001.

groups:
  group001:
    replicasets:
      replicaset001:
        instances:
          instance001:
            snapshot:
              dir: ./var/{{ instance_name }}/snapshots
            wal:
              dir: ./var/{{ instance_name }}/wals

As a result, the paths to snapshots and write-ahead logs differ for different instances.

String

In this example, TT_LOG_LEVEL is used to set a logging level to CRITICAL:

$ export TT_LOG_LEVEL='crit'

Number

In this example, a logging level is set to CRITICAL using a corresponding numeric value:

$ export TT_LOG_LEVEL=3

Array

The examples below show how to set the TT_SHARDING_ROLES variable that accepts an array value. Arrays can be passed in two ways: using a simple …

$ export TT_SHARDING_ROLES=router,storage

… or JSON format:

$ export TT_SHARDING_ROLES='["router", "storage"]'

The simple format is applicable only to arrays containing scalar values.

Map

To assign map values to environment variables, you can also use simple or JSON formats. In the example below, TT_LOG_MODULES sets different logging levels for different modules using a simple format:

$ export TT_LOG_MODULES=module1=info,module2=error

In the next example, TT_ROLES_CFG is used to specify the value of a custom configuration for a role using a JSON format:

$ export TT_ROLES_CFG='{"greeter":{"greeting":"Hello"}}'

The simple format is applicable only to maps containing scalar values.

Array of maps

In the example below, TT_IPROTO_LISTEN is used to specify a listening host and port values:

$ export TT_IPROTO_LISTEN=['{"uri":"127.0.0.1:3311"}']

You can also pass several listening addresses:

$ export TT_IPROTO_LISTEN=['{"uri":"127.0.0.1:3311"}','{"uri":"127.0.0.1:3312"}']