Configuration reference (box.cfg)

This topic describes all configuration parameters that can be specified in code using the box.cfg API.

• background
• coredump
• custom_proc_title
• listen
• memtx_dir
• pid_file
• read_only
• sql_cache_size
• vinyl_dir
• vinyl_timeout
• username
• wal_dir
• work_dir
• worker_pool_threads
• strip_core
• memtx_use_mvcc_engine

Since version 1.6.2.

Run the server as a background task. The log and pid_file parameters must be non-null for this to work.

Type: boolean

Default: false

Environment variable: TT_BACKGROUND

Dynamic: no

Create coredump files.

Usually, an administrator needs to call ulimit -c unlimited (or set corresponding options in systemd's unit file) before running a Tarantool process to get core dumps. If coredump is enabled, Tarantool sets the corresponding resource limit by itself and the administrator doesn't need to call ulimit -c unlimited (see man 3 setrlimit).

This option also sets the state of the dumpable attribute, which is enabled by default, but may be dropped in some circumstances (according to man 2 prctl, see PR_SET_DUMPABLE).

Type: boolean

Environment variable: TT_COREDUMP

Default: false

Dynamic: no

Since version 1.6.7.

Add the given string to the server's process title (what's shown in the COMMAND column for ps -ef and top -c commands).

For example, ordinarily ps -ef shows the Tarantool server process thus:

 
$ ps -ef | grep tarantool1000     14939 14188  1 10:53 pts/2    00:00:13 tarantool <running>

But if the configuration parameters include custom_proc_title='sessions' then the output looks like:

 
$ ps -ef | grep tarantool1000     14939 14188  1 10:53 pts/2    00:00:16 tarantool <running>: sessions

Type: string

Default: null

Environment variable: TT_CUSTOM_PROC_TITLE

Dynamic: yes

Since version 1.6.4.

The read/write data port number or URI (Universal Resource Identifier) string. Has no default value, so must be specified if connections occur from the remote clients that don't use the "admin port". Connections made with listen = {URI} are called "binary port" or "binary protocol" connections.

A typical value is 3301.

 
box.cfg { listen = 3301 }box.cfg { listen = "127.0.0.1:3301" }

Starting from version 2.10.0, you can specify several URIs, and the port number is always stored as an integer value.

Type: integer or string

Default: null

Environment variable: TT_LISTEN

Dynamic: yes

Since version 1.7.4.

A directory where memtx stores snapshot (.snap) files. A relative path in this option is interpreted as relative to work_dir.

By default, snapshots and WAL files are stored in the same directory. However, you can set different values for the memtx_dir and wal_dir options to store them on different physical disks for performance matters.

Type: string

Default: "."

Environment variable: TT_MEMTX_DIR

Dynamic: no

Since version 1.4.9.

Store the process id in this file. Can be relative to work_dir. A typical value is "tarantool.pid".

Type: string

Default: null

Environment variable: TT_PID_FILE

Dynamic: no

Since version 1.7.1.

Say box.cfg{read_only=true...} to put the server instance in read-only mode. After this, any requests that try to change persistent data will fail with error ER_READONLY. Read-only mode should be used for master-replica replication. Read-only mode does not affect data-change requests for spaces defined as temporary. Although read-only mode prevents the server from writing to the WAL, it does not prevent writing diagnostics with the log module.

Type: boolean

Default: false

Environment variable: TT_READ_ONLY

Dynamic: yes

Setting read_only == true affects spaces differently depending on the options that were used during box.schema.space.create, as summarized by this chart:

### sql_cache_size {params[anchor=cfg_basic-sql_cache_size]} Since version 2.3.1.

The maximum number of bytes in the cache for SQL prepared statements. (The number of bytes that are actually used can be seen with box.info.sql().cache.size.)

Type: number

Default: 5242880

Environment variable: TT_SQL_CACHE_SIZE

Dynamic: yes

Since version 1.7.1.

A directory where vinyl files or subdirectories will be stored. Can be relative to work_dir. If not specified, defaults to work_dir.

Type: string

Default: "."

Environment variable: TT_VINYL_DIR

Dynamic: no

Since version 1.7.5.

The vinyl storage engine has a scheduler which does compaction. When vinyl is low on available memory, the compaction scheduler may be unable to keep up with incoming update requests. In that situation, queries may time out after vinyl_timeout seconds. This should rarely occur, since normally vinyl would throttle inserts when it is running low on compaction bandwidth. Compaction can also be ordered manually with index_object:compact().

Type: float

Default: 60

Environment variable: TT_VINYL_TIMEOUT

Dynamic: yes

Since version 1.4.9.

UNIX user name to switch to after start.

Type: string

Default: null

Environment variable: TT_USERNAME

Dynamic: no

Since version 1.6.2.

A directory where write-ahead log (.xlog) files are stored. A relative path in this option is interpreted as relative to work_dir.

By default, WAL files and snapshots are stored in the same directory. However, you can set different values for the wal_dir and memtx_dir options to store them on different physical disks for performance matters.

Type: string

Default: "."

Environment variable: TT_WAL_DIR

Dynamic: no

Since version 1.4.9.

A directory where database working files will be stored. The server instance switches to work_dir with chdir(2) after start. Can be relative to the current directory. If not specified, defaults to the current directory. Other directory parameters may be relative to work_dir, for example:

 
box.cfg{    work_dir = '/home/user/A',    wal_dir = 'B',    memtx_dir = 'C'}

will put xlog files in /home/user/A/B, snapshot files in /home/user/A/C, and all other files or subdirectories in /home/user/A.

Type: string

Default: null

Environment variable: TT_WORK_DIR

Dynamic: no

Since version 1.7.5.

The maximum number of threads to use during execution of certain internal processes (currently socket.getaddrinfo() and coio_call()).

Type: integer

Default: 4

Environment variable: TT_WORKER_POOL_THREADS

Dynamic: yes

Since version 2.2.2.

Whether coredump files should include memory allocated for tuples. (This can be large if Tarantool runs under heavy load.) Setting to true means "do not include". In an older version of Tarantool the default value of this parameter was false.

Type: boolean

Default: true

Environment variable: TT_STRIP_CORE

Dynamic: no

Since version 2.6.1.

Enable transactional manager if set to true.

Type: boolean

Default: false

Environment variable: TT_MEMTX_USE_MVCC_ENGINE

Dynamic: no

• memtx_memory
• memtx_max_tuple_size
• memtx_min_tuple_size
• memtx_allocator
• memtx_sort_threads
• slab_alloc_factor
• slab_alloc_granularity
• vinyl_bloom_fpr
• vinyl_cache
• vinyl_max_tuple_size
• vinyl_memory
• vinyl_page_size
• vinyl_range_size
• vinyl_run_count_per_level
• vinyl_run_size_ratio
• vinyl_read_threads
• vinyl_write_threads

Since version 1.7.4.

How much memory Tarantool allocates to store tuples. When the limit is reached, INSERT or UPDATE requests begin failing with error ER_MEMORY_ISSUE. The server does not go beyond the memtx_memory limit to allocate tuples, but there is additional memory used to store indexes and connection information.

Type: float

Default: 256 * 1024 * 1024 = 268435456 bytes

Minimum: 33554432 bytes (32 MB)

Environment variable: TT_MEMTX_MEMORY

Dynamic: yes but it cannot be decreased

Since version 1.7.4.

Size of the largest allocation unit, for the memtx storage engine. It can be increased if it is necessary to store large tuples.

Type: integer

Default: 1024 * 1024 = 1048576 bytes

Environment variable: TT_MEMTX_MAX_TUPLE_SIZE

Dynamic: yes

Since version 1.7.4.

Size of the smallest allocation unit. It can be decreased if most of the tuples are very small.

Type: integer

Default: 16 bytes

Possible values: between 8 and 1048280 inclusive

Environment variable: TT_MEMTX_MIN_TUPLE_SIZE

Dynamic: no

Since version 2.10.0.

Specify the allocator that manages memory for memtx tuples. Possible values:

• system – the memory is allocated as needed, checking that the quota is not exceeded. THe allocator is based on the malloc function.
• small – a slab allocator. The allocator repeatedly uses a memory block to allocate objects of the same type. Note that this allocator is prone to unresolvable fragmentation on specific workloads, so you can switch to system in such cases.

Type: string

Default: 'small'

Environment variable: TT_MEMTX_ALLOCATOR

Dynamic: no

Since: 3.0.0.

The number of threads from the thread pool used to sort keys of secondary indexes on loading a memtx database. The minimum value is 1, the maximum value is 256. The default is to use all available cores.

Type: integer

Default: box.NULL

Environment variable: TT_MEMTX_SORT_THREADS

Dynamic: no

The multiplier for computing the sizes of memory chunks that tuples are stored in. A lower value may result in less wasted memory depending on the total amount of memory available and the distribution of item sizes.

See also: slab_alloc_granularity

Type: float

Default: 1.05

Possible values: between 1 and 2 inclusive

Environment variable: TT_SLAB_ALLOC_FACTOR

Dynamic: no

Since version 2.8.1.

Specify the granularity (in bytes) of memory allocation in the small allocator. The memtx.slab_alloc_granularity value should meet the following conditions:

• The value is a power of two.
• The value is greater than or equal to 4.

Below are few recommendations on how to adjust the memtx.slab_alloc_granularity option:

• If the tuples in space are small and have about the same size, set the option to 4 bytes to save memory.
• If the tuples are different-sized, increase the option value to allocate tuples from the same mempool (memory pool).

See also: slab_alloc_factor

Type: number

Default: 8 bytes

Environment variable: TT_SLAB_ALLOC_GRANULARITY

Dynamic: no

Since version 1.7.4.

Bloom filter false positive rate – the suitable probability of the bloom filter to give a wrong result. The vinyl_bloom_fpr setting is a default value for one of the options in the Options for space_object:create_index() chart.

Type: float

Default: 0.05

Environment variable: TT_VINYL_BLOOM_FPR

Dynamic: no

Since version 1.7.4. The cache size for the vinyl storage engine. The cache can be resized dynamically.

Type: integer

Default: 128 * 1024 * 1024 = 134217728 bytes

Environment variable: TT_VINYL_CACHE

Dynamic: yes

Since version 1.7.5.

Size of the largest allocation unit, for the vinyl storage engine. It can be increased if it is necessary to store large tuples. See also: memtx_max_tuple_size.

Type: integer

Default: 1024 * 1024 = 1048576 bytes

Environment variable: TT_VINYL_MAX_TUPLE_SIZE

Dynamic: no

Since version 1.7.4.

The maximum number of in-memory bytes that vinyl uses.

Type: integer

Default: 128 * 1024 * 1024 = 134217728 bytes

Environment variable: TT_VINYL_MEMORY

Dynamic: yes but it cannot be decreased

Since version 1.7.4.

Page size. Page is a read/write unit for vinyl disk operations. The vinyl_page_size setting is a default value for one of the options in the Options for space_object:create_index() chart.

Type: integer

Default: 8 * 1024 = 8192 bytes

Environment variable: TT_VINYL_PAGE_SIZE

Dynamic: no

Since version 1.7.4.

The default maximum range size for a vinyl index, in bytes. The maximum range size affects the decision whether to split a range.

If vinyl_range_size is not nil and not 0, then it is used as the default value for the range_size option in the Options for space_object:create_index() chart.

If vinyl_range_size is nil or 0, and range_size is not specified when the index is created, then Tarantool sets a value later depending on performance considerations. To see the actual value, use index_object:stat().range_size.

In Tarantool versions prior to 1.10.2, vinyl_range_size default value was 1073741824.

Type: integer

Default: nil

Environment variable: TT_VINYL_RANGE_SIZE

Dynamic: no

Since version 1.7.4.

The maximal number of runs per level in vinyl LSM tree. If this number is exceeded, a new level is created. The vinyl_run_count_per_level setting is a default value for one of the options in the Options for space_object:create_index() chart.

Type: integer

Default: 2

Environment variable: TT_VINYL_RUN_COUNT_PER_LEVEL

Dynamic: no

Since version 1.7.4.

Ratio between the sizes of different levels in the LSM tree. The vinyl_run_size_ratio setting is a default value for one of the options in the Options for space_object:create_index() chart.

Type: float

Default: 3.5

Environment variable: TT_VINYL_RUN_SIZE_RATIO

Dynamic: no

Since version 1.7.5.

The maximum number of read threads that vinyl can use for some concurrent operations, such as I/O and compression.

Type: integer

Default: 1

Environment variable: TT_VINYL_READ_THREADS

Dynamic: no

Since version 1.7.5.

The maximum number of write threads that vinyl can use for some concurrent operations, such as I/O and compression.

Type: integer

Default: 4

Environment variable: TT_VINYL_WRITE_THREADS

Dynamic: no

• checkpoint_count
• checkpoint_interval
• checkpoint_wal_threshold

Checkpoint daemon

The checkpoint daemon (snapshot daemon) is a constantly running fiber. The checkpoint daemon creates a schedule for the periodic snapshot creation based on the configuration options and the speed of file size growth. If enabled, the daemon makes new snapshot (.snap) files according to this schedule.

The work of the checkpoint daemon is based on the following configuration options:

• checkpoint_interval – a new snapshot is taken once in a given period.
• checkpoint_wal_threshold – a new snapshot is taken once the size of all WAL files created since the last snapshot exceeds a given limit.

If necessary, the checkpoint daemon also activates the Tarantool garbage collector that deletes old snapshots and WAL files.

Tarantool garbage collector

Tarantool garbage collector can be activated by the checkpoint daemon. The garbage collector tracks the snapshots that are to be relayed to a replica or needed by other consumers. When the files are no longer needed, Tarantool garbage collector deletes them.

This garbage collector is called as follows:

• When the number of snapshots reaches the limit of checkpoint_count size. After a new snapshot is taken, Tarantool garbage collector deletes the oldest snapshot file and any associated WAL files.
• When the size of all WAL files created since the last snapshot reaches the limit of checkpoint_wal_threshold. Once this size is exceeded, the checkpoint daemon takes a snapshot, then the garbage collector deletes the old WAL files.

If an old snapshot file is deleted, the Tarantool garbage collector also deletes any write-ahead log (.xlog) files that meet the following conditions:

• The WAL files are older than the snapshot file.
• The WAL files contain information present in the snapshot file.

Tarantool garbage collector also deletes obsolete vinyl .run files.

Tarantool garbage collector doesn't delete a file in the following cases:

• A backup is running, and the file has not been backed up (see Hot backup).
• Replication is running, and the file has not been relayed to a replica (see Replication architecture),
• A replica is connecting.
• A replica has fallen behind. The progress of each replica is tracked; if a replica's position is far from being up to date, then the server stops to give it a chance to catch up. If an administrator concludes that a replica is permanently down, then the correct procedure is to restart the server, or (preferably) remove the replica from the cluster.

Since version 1.7.4.

The interval in seconds between actions by the checkpoint daemon. If the option is set to a value greater than zero, and there is activity that causes change to a database, then the checkpoint daemon calls box.snapshot() every checkpoint_interval seconds, creating a new snapshot file each time. If the option is set to zero, the checkpoint daemon is disabled.

Example

 
box.cfg{ checkpoint_interval = 7200 }

In the example, the checkpoint daemon creates a new database snapshot every two hours, if there is activity.

Type: integer

Default: 3600 (one hour)

Environment variable: TT_CHECKPOINT_INTERVAL

Dynamic: yes

Since version 1.7.4.

The maximum number of snapshots that are stored in the memtx_dir directory. If the number of snapshots after creating a new one exceeds this value, the Tarantool garbage collector deletes old snapshots. If the option is set to zero, the garbage collector does not delete old snapshots.

Example

 
box.cfg{    checkpoint_interval = 7200,    checkpoint_count  = 3}

In the example, the checkpoint daemon creates a new snapshot every two hours until it has created three snapshots. After creating a new snapshot (the fourth one), the oldest snapshot and any associated write-ahead-log files are deleted.

Type: integer

Default: 2

Environment variable: TT_CHECKPOINT_COUNT

Dynamic: yes

Since version 2.1.2.

The threshold for the total size in bytes for all WAL files created since the last checkpoint. Once the configured threshold is exceeded, the WAL thread notifies the checkpoint daemon that it must make a new checkpoint and delete old WAL files.

This parameter enables administrators to handle a problem that could occur with calculating how much disk space to allocate for a partition containing WAL files.

Type: integer

Default: 10\^18 (a large number so in effect there is no limit by default) Environment variable: TT_CHECKPOINT_WAL_THRESHOLD

Dynamic: yes

• force_recovery
• wal_max_size
• snap_io_rate_limit
• wal_mode
• wal_dir_rescan_delay
• wal_queue_max_size
• wal_cleanup_delay
• wal_ext
• secure_erasing

Since version 1.7.4.

If force_recovery equals true, Tarantool tries to continue if there is an error while reading a snapshot file (at server instance start) or a write-ahead log file (at server instance start or when applying an update at a replica): skips invalid records, reads as much data as possible and lets the process finish with a warning. Users can prevent the error from recurring by writing to the database and executing box.snapshot().

Otherwise, Tarantool aborts recovery if there is an error while reading.

Type: boolean

Default: false

Environment variable: TT_FORCE_RECOVERY

Dynamic: no

Since version 1.7.4.

The maximum number of bytes in a single write-ahead log file. When a request would cause an .xlog file to become larger than wal_max_size, Tarantool creates a new WAL file.

Type: integer

Default: 268435456 (256 * 1024 * 1024) bytes

Environment variable: TT_WAL_MAX_SIZE

Dynamic: no

Since version 1.4.9.

Reduce the throttling effect of box.snapshot() on INSERT/UPDATE/DELETE performance by setting a limit on how many megabytes per second it can write to disk. The same can be achieved by splitting wal_dir and memtx_dir locations and moving snapshots to a separate disk. The limit also affects what box.stat.vinyl().regulator may show for the write rate of dumps to .run and .index files.

Type: float

Default: null

Environment variable: TT_SNAP_IO_RATE_LIMIT

Dynamic: yes

Since version 1.6.2.

Specify fiber-WAL-disk synchronization mode as:

• none: write-ahead log is not maintained. A node with wal_mode set to none can't be a replication master.
• write: fibers wait for their data to be written to the write-ahead log (no fsync(2)).
• fsync: fibers wait for their data, fsync(2) follows each write(2).

Type: string

Default: "write"

Environment variable: TT_WAL_MODE

Dynamic: no

Since version 1.6.2.

The time interval in seconds between periodic scans of the write-ahead-log file directory, when checking for changes to write-ahead-log files for the sake of replication or hot standby.

Type: float

Default: 2

Environment variable: TT_WAL_DIR_RESCAN_DELAY

Dynamic: no

Since version 2.8.1.

The size of the queue (in bytes) used by a replica to submit new transactions to a write-ahead log (WAL). This option helps limit the rate at which a replica submits transactions to the WAL. Limiting the queue size might be useful when a replica is trying to sync with a master and reads new transactions faster than writing them to the WAL.

Type: number

Default: 16777216 bytes

Environment variable: TT_WAL_QUEUE_MAX_SIZE

Dynamic: yes

Since version 2.6.3.

The delay in seconds used to prevent the Tarantool garbage collector from immediately removing write-ahead log files after a node restart. This delay eliminates possible erroneous situations when the master deletes WALs needed by replicas after restart. As a consequence, replicas sync with the master faster after its restart and don't need to download all the data again. Once all the nodes in the replica set are up and running, a scheduled garbage collection is started again even if wal_cleanup_delay has not expired.

Type: number

Default: 14400 seconds

Environment variable: TT_WAL_CLEANUP_DELAY

Dynamic: yes

Since version 2.11.0.

(Enterprise Edition only) Allows you to add auxiliary information to each write-ahead log record. For example, you can enable storing an old and new tuple for each CRUD operation performed. This information might be helpful for implementing a CDC (Change Data Capture) utility that transforms a data replication stream.

You can enable storing old and new tuples as follows:

• Set the old and new options to true to store old and new tuples in a write-ahead log for all spaces.

   
  box.cfg {    wal_ext = { old = true, new = true }}

• To adjust these options for specific spaces, use the spaces option.

   
  box.cfg {    wal_ext = {        old = true, new = true,        spaces = {            space1 = { old = false },            space2 = { new = false }        }    }}

  The configuration for specific spaces has priority over the global configuration, so only new tuples are added to the log for space1 and only old tuples for space2.

Note that records with additional fields are replicated as follows:

• If a replica doesn't support the extended format configured on a master, auxiliary fields are skipped.
• If a replica and master have different configurations for WAL records, the master's configuration is ignored.

Type: map

Default: nil

Environment variable: TT_WAL_EXT

Dynamic: yes

Since version 3.0.0.

(Enterprise Edition only) If true, forces Tarantool to overwrite a data file a few times before deletion to render recovery of a deleted file impossible. The option applies to both .xlog and .snap files as well as Vinyl data files.

Type: boolean

Default: false

Environment variable: TT_SECURE_ERASING

Dynamic: yes

Since version 1.7.4.

Whether to start the server in hot standby mode.

Hot standby is a feature which provides a simple form of failover without replication.

The expectation is that there will be two instances of the server using the same configuration. The first one to start will be the "primary" instance. The second one to start will be the "standby" instance.

To initiate the standby instance, start a second instance of the Tarantool server on the same computer with the same box.cfg configuration settings – including the same directories and same non-null URIs – and with the additional configuration setting hot_standby = true. Expect to see a notification ending with the words I> Entering hot standby mode. This is fine. It means that the standby instance is ready to take over if the primary instance goes down.

The standby instance will initialize and will try to take a lock on wal_dir, but will fail because the primary instance has made a lock on wal_dir. So the standby instance goes into a loop, reading the write ahead log which the primary instance is writing (so the two instances are always in sync), and trying to take the lock. If the primary instance goes down for any reason, the lock will be released. In this case, the standby instance will succeed in taking the lock, will connect on the listen address and will become the primary instance. Expect to see a notification ending with the words I> ready to accept requests.

Thus there is no noticeable downtime if the primary instance goes down.

Hot standby feature has no effect:

• if wal_dir_rescan_delay = a large number (on Mac OS and FreeBSD); on these platforms, it is designed so that the loop repeats every wal_dir_rescan_delay seconds.
• if wal_mode = 'none'; it is designed to work with wal_mode = 'write' or wal_mode = 'fsync'.
• for spaces created with engine = 'vinyl'; it is designed to work for spaces created with engine = 'memtx'.

Type: boolean

Default: false

Environment variable: TT_HOT_STANDBY

Dynamic: no

• replication
• replication_anon
• bootstrap_leader
• bootstrap_strategy
• replication_connect_timeout
• replication_connect_quorum
• replication_skip_conflict
• replication_sync_lag
• replication_sync_timeout
• replication_timeout
• replicaset_uuid
• instance_uuid
• replication_synchro_quorum
• replication_synchro_timeout
• replication_threads
• election_mode
• election_timeout
• election_fencing_mode
• instance_name
• replicaset_name
• cluster_name

Since version 1.7.4.

If replication is not an empty string, the instance is considered to be a Tarantool replica. The replica will try to connect to the master specified in replication with a URI (Universal Resource Identifier), for example:

{konstantin}:{secret_password}@{tarantool.org}:{3301}

If there is more than one replication source in a replica set, specify an array of URIs, for example (replace 'uri' and 'uri2' in this example with valid URIs):

box.cfg{ replication = { {*{'uri1'}*}, {*{'uri2'}*} } }

If one of the URIs is "self" – that is, if one of the URIs is for the instance where box.cfg{} is being executed – then it is ignored. Thus, it is possible to use the same replication specification on multiple server instances, as shown in these examples.

The default user name is 'guest'.

A read-only replica does not accept data-change requests on the listen port.

The replication parameter is dynamic, that is, to enter master mode, simply set replication to an empty string and issue:

box.cfg{ replication = {*{new-value}*} }

Type: string

Default: null

Environment variable: TT_REPLICATION

Dynamic: yes

Since version 2.3.1.

A Tarantool replica can be anonymous. This type of replica is read-only (but you still can write to temporary and replica-local spaces), and it isn't present in the _cluster space.

Since an anonymous replica isn't registered in the _cluster table, there is no limitation for anonymous replicas count in a replica set: you can have as many of them as you want.

In order to make a replica anonymous, pass the option replication_anon=true to box.cfg and set read_only to true.

Let's go through anonymous replica bootstrap. Suppose we have got a master configured with

 
box.cfg{listen=3301}

and created a local space called "loc":

 
box.schema.space.create('loc', {is_local=true})box.space.loc:create_index("pk")

Now, to configure an anonymous replica, we need to issue box.cfg, as usual.

 
box.cfg{replication_anon=true, read_only=true, replication=3301}

As mentioned above, replication_anon may be set to true only together with read_only. The instance will fetch the master's snapshot and start following its changes. It will receive no id, so its id value will remain zero.

 
tarantool> box.info.id---- 0...tarantool> box.info.replication---- 1:    id: 1    uuid: 3c84f8d9-e34d-4651-969c-3d0ed214c60f    lsn: 4    upstream:    status: follow    idle: 0.6912029999985    peer:    lag: 0.00014615058898926...

Now we can use the replica. For example, we can do inserts into the local space:

 
tarantool> for i = 1,10 do    > box.space.loc:insert{i}    > end---...

Note that while the instance is anonymous, it will increase the 0-th component of its vclock:

 
tarantool> box.info.vclock---- {0: 10, 1: 4}...

Let's now promote the anonymous replica to a regular one:

 
tarantool> box.cfg{replication_anon=false}2019-12-13 20:34:37.423 [71329] main I> assigned id 2 to replica 6a9c2ed2-b9e1-4c57-a0e8-51a46def76612019-12-13 20:34:37.424 [71329] main/102/interactive I> set 'replication_anon' configuration option to false---...tarantool> 2019-12-13 20:34:37.424 [71329] main/117/applier/ I> subscribed2019-12-13 20:34:37.424 [71329] main/117/applier/ I> remote vclock {1: 5} local vclock {0: 10, 1: 5}2019-12-13 20:34:37.425 [71329] main/118/applierw/ C> leaving orphan mode

The replica has just received an id equal to 2. We can make it read-write now.

 
tarantool> box.cfg{read_only=false}2019-12-13 20:35:46.392 [71329] main/102/interactive I> set 'read_only' configuration option to false---...tarantool> box.schema.space.create('test')---- engine: memtxbefore_replace: 'function: 0x01109f9dc8'on_replace: 'function: 0x01109f9d90'ck_constraint: field_count: 0temporary: falseindex: is_local: falseenabled: falsename: testid: 513- created...tarantool> box.info.vclock---- {0: 10, 1: 5, 2: 2}...

Now the replica tracks its changes in the 2nd vclock component, as expected. It can also become a replication master from now on.

Notes:

• You cannot replicate from an anonymous instance.
• To promote an anonymous instance to a regular one, first start it as anonymous, and only then issue box.cfg{replication_anon=false}
• In order for the deanonymization to succeed, the instance must replicate from some read-write instance, otherwise it cannot be added to the _cluster table.

Type: boolean

Default: false

Environment variable: TT_REPLICATION_ANON

Dynamic: yes

Since 3.0.0.

A bootstrap leader for a replica set. You can pass a bootstrap leader's URI, UUID, or name.

To specify a bootstrap leader manually, you need to set bootstrap_strategy to config, for example:

 
box.cfg{    bootstrap_strategy = 'config',    bootstrap_leader = '127.0.0.1:3301',    replication = {'127.0.0.1:3301'},}

Type: string

Default: null

Environment variable: TT_BOOTSTRAP_LEADER

Dynamic: yes

Since 2.11.0.

Specify a strategy used to bootstrap a replica set. The following strategies are available:

• auto: a node doesn't boot if a half or more of other nodes in a replica set are not connected. For example, if the replication parameter contains 2 or 3 nodes, a node requires 2 connected instances. In the case of 4 or 5 nodes, at least 3 connected instances are required. Moreover, a bootstrap leader fails to boot unless every connected node has chosen it as a bootstrap leader.
• config: use the specified node to bootstrap a replica set. To specify the bootstrap leader, use the bootstrap_leader option.
• supervised: a bootstrap leader isn't chosen automatically but should be appointed using box.ctl.make_bootstrap_leader() on the desired node.
• legacy (deprecated since 2.11.0): a node requires the replication_connect_quorum number of other nodes to be connected. This option is added to keep the compatibility with the current versions of Cartridge and might be removed in the future.

Type: string

Default: auto

Environment variable: TT_BOOTSTRAP_STRATEGY

Dynamic: yes

Since version 1.9.0.

The number of seconds that a replica will wait when trying to connect to a master in a cluster. See orphan status for details.

This parameter is different from replication_timeout, which a master uses to disconnect a replica when the master receives no acknowledgments of heartbeat messages.

Type: float

Default: 30

Environment variable: TT_REPLICATION_CONNECT_TIMEOUT

Dynamic: yes

Deprecated since 2.11.0.

This option is in effect if bootstrap_strategy is set to legacy.

Specify the number of nodes to be up and running to start a replica set. This parameter has effect during bootstrap or configuration update. Setting replication_connect_quorum to 0 makes Tarantool require no immediate reconnect only in case of recovery. See Orphan status for details.

Example:

 
box.cfg { replication_connect_quorum = 2 }

Type: integer

Default: null

Environment variable: TT_REPLICATION_CONNECT_QUORUM

Dynamic: yes

Since version 1.10.1.

By default, if a replica adds a unique key that another replica has added, replication stops with error = ER_TUPLE_FOUND.

However, by specifying replication_skip_conflict = true, users can state that such errors may be ignored. So instead of saving the broken transaction to the xlog, it will be written there as NOP (No operation).

Example:

 
box.cfg{replication_skip_conflict=true}

Type: boolean

Default: false

Environment variable: TT_REPLICATION_SKIP_CONFLICT

Dynamic: yes