Configuration reference (box.cfg)
Примечание
Starting with the 3.0 version, the recommended way of configuring Tarantool is using a configuration file. Configuring Tarantool in code is considered a legacy approach.
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
-
background
¶
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.
Важно
Do not enable the background mode for applications intended to run by the
tt
utility. For more information, see the tt start reference.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_BACKGROUND
Динамический: нет
-
coredump
¶
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).
Тип: логический
Environment variable: TT_COREDUMP
По умолчанию: false (ложь)
Динамический: нет
-
custom_proc_title
¶
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).
Например, как правило, ps -ef
показывает процесс Tarantool-сервера так:
$ ps -ef | grep tarantool
1000 14939 14188 1 10:53 pts/2 00:00:13 tarantool <running>
Но если указан конфигурационный параметр custom_proc_title='sessions'
, вывод выглядит так:
$ ps -ef | grep tarantool
1000 14939 14188 1 10:53 pts/2 00:00:16 tarantool <running>: sessions
Тип: строка
По умолчанию: null
Environment variable: TT_CUSTOM_PROC_TITLE
Динамический: да
-
listen
¶
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.
Как правило, используется значение 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.
Тип: целое число или строка
По умолчанию: null
Environment variable: TT_LISTEN
Динамический: да
-
memtx_dir
¶
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.
Тип: строка
По умолчанию: «.»
Environment variable: TT_MEMTX_DIR
Динамический: нет
-
pid_file
¶
Since version 1.4.9.
Store the process id in this file. Can be relative to work_dir. A typical value is “tarantool.pid
”.
Тип: строка
По умолчанию: null
Environment variable: TT_PID_FILE
Динамический: нет
-
read_only
¶
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.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_READ_ONLY
Динамический: да
Setting read_only == true
affects spaces differently depending on the
options that were used during
box.schema.space.create,
as summarized by this chart:
Характеристика
Можно создать?
Допускает запись?
Реплицируется?
Сохраняется?
(по умолчанию)
нет
нет
да
да
temporary
нет
да
нет
нет
is_local
нет
да
нет
да
-
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.)
Тип: число
По умолчанию: 5242880
Environment variable: TT_SQL_CACHE_SIZE
Динамический: да
-
vinyl_dir
¶
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
.
Тип: строка
По умолчанию: «.»
Environment variable: TT_VINYL_DIR
Динамический: нет
-
vinyl_timeout
¶
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().
Тип: число с плавающей запятой
По умолчанию: 60
Environment variable: TT_VINYL_TIMEOUT
Динамический: да
-
username
¶
Since version 1.4.9.
UNIX user name to switch to after start.
Тип: строка
По умолчанию: null
Environment variable: TT_USERNAME
Динамический: нет
-
wal_dir
¶
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.
Тип: строка
По умолчанию: «.»
Environment variable: TT_WAL_DIR
Динамический: нет
-
work_dir
¶
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'
}
поместит xlog-файлы в /home/user/A/B
, файлы снимков в /home/user/A/C
, а все остальные файлы или поддиректории в /home/user/A
.
Тип: строка
По умолчанию: null
Environment variable: TT_WORK_DIR
Динамический: нет
-
worker_pool_threads
¶
Since version 1.7.5.
The maximum number of threads to use during execution
of certain internal processes (currently
socket.getaddrinfo() and
coio_call()).
Тип: целое число
По умолчанию: 4
Environment variable: TT_WORKER_POOL_THREADS
Динамический: да
-
strip_core
¶
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
.
Тип: логический
По умолчанию: true
Environment variable: TT_STRIP_CORE
Динамический: нет
-
memtx_use_mvcc_engine
¶
Since version 2.6.1.
Enable transactional manager if set to true
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_MEMTX_USE_MVCC_ENGINE
Динамический: нет
Настройка хранения
- 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
-
memtx_memory
¶
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.
Тип: число с плавающей запятой
По умолчанию: 256 * 1024 * 1024 = 268435456 байтов
Minimum: 33554432 bytes (32 MB)
Environment variable: TT_MEMTX_MEMORY
Dynamic: yes but it cannot be decreased
-
memtx_max_tuple_size
¶
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.
Тип: целое число
По умолчанию: 1024 * 1024 = 1048576 байтов
Environment variable: TT_MEMTX_MAX_TUPLE_SIZE
Динамический: да
-
memtx_min_tuple_size
¶
Since version 1.7.4.
Size of the smallest allocation unit. It can be decreased if most
of the tuples are very small.
Тип: целое число
По умолчанию: 16 байтов
Possible values: between 8 and 1048280 inclusive
Environment variable: TT_MEMTX_MIN_TUPLE_SIZE
Динамический: нет
-
memtx_allocator
¶
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.
Тип: строка
Default: „small“
Environment variable: TT_MEMTX_ALLOCATOR
Динамический: нет
-
memtx_sort_threads
¶
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.
Примечание
Since 3.0.0, this option replaces the approach when OpenMP threads are used to parallelize sorting.
For backward compatibility, the OMP_NUM_THREADS
environment variable is taken into account to
set the number of sorting threads.
Тип: целое число
Default: box.NULL
Environment variable: TT_MEMTX_SORT_THREADS
Динамический: нет
-
slab_alloc_factor
¶
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
Тип: число с плавающей запятой
Default: 1.05
Possible values: between 1 and 2 inclusive
Environment variable: TT_SLAB_ALLOC_FACTOR
Динамический: нет
-
slab_alloc_granularity
¶
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
Тип: число
Default: 8 bytes
Environment variable: TT_SLAB_ALLOC_GRANULARITY
Динамический: нет
-
vinyl_bloom_fpr
¶
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.
Тип: число с плавающей запятой
По умолчанию: 0.05
Environment variable: TT_VINYL_BLOOM_FPR
Динамический: нет
-
vinyl_cache
¶
Для версий от 1.7.4. и выше. Размер кэша для движка базы данных vinyl. Размер кэша можно изменить динамически.
Тип: целое число
По умолчанию: 128 * 1024 * 1024 = 134217728 байтов
Environment variable: TT_VINYL_CACHE
Динамический: да
-
vinyl_max_tuple_size
¶
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.
Тип: целое число
По умолчанию: 1024 * 1024 = 1048576 байтов
Environment variable: TT_VINYL_MAX_TUPLE_SIZE
Динамический: нет
-
vinyl_memory
¶
Since version 1.7.4.
The maximum number of in-memory bytes that vinyl uses.
Тип: целое число
По умолчанию: 128 * 1024 * 1024 = 134217728 байтов
Environment variable: TT_VINYL_MEMORY
Dynamic: yes but it cannot be decreased
-
vinyl_page_size
¶
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.
Тип: целое число
По умолчанию: 8 * 1024 = 8192 байтов
Environment variable: TT_VINYL_PAGE_SIZE
Динамический: нет
-
vinyl_range_size
¶
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.
Если vinyl_range_size
содержит не нулевое значение nil и не 0, это значение используется в качестве значения по умолчанию для параметра range_size
в таблице Параметры space_object:create_index().
Если vinyl_range_size
содержит нулевое значение nil или 0, а параметр range_size
не задан при создании индекса, то Tarantool сам задает это значение позднее в результате оценки производительности. Чтобы узнать текущее значение, используйте index_object:stat().range_size.
До версии Tarantool 1.10.2 значение vinyl_range_size
по умолчанию было 1073741824.
Тип: целое число
По умолчанию: nil
Environment variable: TT_VINYL_RANGE_SIZE
Динамический: нет
-
vinyl_run_count_per_level
¶
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.
Тип: целое число
По умолчанию: 2
Environment variable: TT_VINYL_RUN_COUNT_PER_LEVEL
Динамический: нет
-
vinyl_run_size_ratio
¶
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.
Тип: число с плавающей запятой
По умолчанию: 3.5
Environment variable: TT_VINYL_RUN_SIZE_RATIO
Динамический: нет
-
vinyl_read_threads
¶
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.
Тип: целое число
По умолчанию: 1
Environment variable: TT_VINYL_READ_THREADS
Динамический: нет
-
vinyl_write_threads
¶
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.
Тип: целое число
По умолчанию: 4
Environment variable: TT_VINYL_WRITE_THREADS
Динамический: нет
Демон создания контрольных точек
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
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.
Примечание
The garbage collector called by the checkpoint daemon is distinct from the Lua garbage collector
which is for Lua objects, and distinct from the Tarantool garbage collector that specializes in handling shard buckets.
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.
-
checkpoint_interval
¶
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.
Тип: целое число
По умолчанию: 3600 (один час)
Environment variable: TT_CHECKPOINT_INTERVAL
Динамический: да
-
checkpoint_count
¶
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.
Примечание
Snapshots will not be deleted if replication is ongoing and the file has not been relayed to a replica.
Therefore, checkpoint_count
has no effect unless all replicas are alive.
Тип: целое число
По умолчанию: 2
Environment variable: TT_CHECKPOINT_COUNT
Динамический: да
-
checkpoint_wal_threshold
¶
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.
Этот параметр позволяет администраторам справиться с проблемой, которая может возникнуть при вычислении объема дискового пространства для раздела, содержащего файлы WAL.
Тип: целое число
По умолчанию: 10^18 (большое число: можно считать, что предела нет)
Environment variable: TT_CHECKPOINT_WAL_THRESHOLD
Динамический: да
Записи в бинарный журнал и создание снимков
- 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
-
force_recovery
¶
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().
В остальных случаях Tarantool прерывает восстановление на ошибке чтения.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FORCE_RECOVERY
Динамический: нет
-
wal_max_size
¶
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.
Тип: целое число
По умолчанию: 268435456 (256 * 1024 * 1024) байтов
Environment variable: TT_WAL_MAX_SIZE
Динамический: нет
-
snap_io_rate_limit
¶
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.
Тип: число с плавающей запятой
По умолчанию: null
Environment variable: TT_SNAP_IO_RATE_LIMIT
Динамический: да
-
wal_mode
¶
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).
Тип: строка
По умолчанию: «write»
Environment variable: TT_WAL_MODE
Динамический: нет
-
wal_dir_rescan_delay
¶
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.
Тип: число с плавающей запятой
По умолчанию: 2
Environment variable: TT_WAL_DIR_RESCAN_DELAY
Динамический: нет
-
wal_queue_max_size
¶
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.
Примечание
You might consider increasing the wal_queue_max_size
value in case of
large tuples (approximately one megabyte or larger).
Тип: число
Default: 16777216 bytes
Environment variable: TT_WAL_QUEUE_MAX_SIZE
Динамический: да
-
wal_cleanup_delay
¶
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.
Примечание
The wal_cleanup_delay
option has no effect on nodes running as
anonymous replicas.
Тип: число
Default: 14400 seconds
Environment variable: TT_WAL_CLEANUP_DELAY
Динамический: да
-
wal_ext
¶
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
По умолчанию: nil
Environment variable: TT_WAL_EXT
Динамический: да
-
secure_erasing
¶
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.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_SECURE_ERASING
Динамический: да
Горячее резервирование
-
hot_standby
¶
Since version 1.7.4.
Whether to start the server in hot standby mode.
Горячее резервирование – это функция, которая обеспечивает простое восстановление после отказа без репликации.
Предполагается, что есть два экземпляра сервера, использующих одну и ту же конфигурацию. Первый из них станет «основным» экземпляром. Тот, который запускается вторым, станет «резервным» экземпляром.
Чтобы создать резервный экземпляр, запустите второй экземпляр Tarantool-сервера на том же компьютере с теми же настройками конфигурации box.cfg – включая одинаковые директории и ненулевые URI – и с дополнительной настройкой конфигурации hot_standby = true
. В ближайшее время вы увидите уведомление, которое заканчивается словами I> Entering hot standby mode
(вход в режим горячего резервирования). Всё в порядке – это означает, что резервный экземпляр готов взять работу на себя, если основной экземпляр прекратит работу.
Резервный экземпляр начнет инициализацию и попытается заблокировать wal_dir, но не сможет, поскольку директория wal_dir
заблокирована основным экземпляром. Поэтому резервный экземпляр входит в цикл, выполняя чтение журнала упреждающей записи, в который записывает данные основной экземпляр (поэтому два экземпляра всегда синхронизированы), и пытаясь произвести блокировку. Если основной экземпляр по какой-либо причине прекращает работу, блокировка снимается. В таком случае резервный экземпляр сможет заблокировать директорию на себя, подключится по адресу для прослушивания и станет основным экземпляром. В ближайшее время вы увидите уведомление, которое заканчивается словами I> ready to accept requests
(готов принимать запросы).
Таким образом, если основной экземпляр прекращает работу, время простоя отсутствует.
Функция горячего резервирования не работает:
- если wal_dir_rescan_delay = большое число (в Mac OS и FreeBSD); на этих платформах цикл запрограммирован на повторение каждые
wal_dir_rescan_delay
секунд.
- если wal_mode = „none“; будет работать только при
wal_mode = 'write'
или wal_mode = 'fsync'
.
- со спейсами, созданными на движке vinyl engine = „vinyl“; работает с движком memtx
engine = 'memtx'
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_HOT_STANDBY
Динамический: нет
Репликация
- 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
-
replication
¶
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
Если в наборе реплик более одного источника репликации, укажите массив URI, например (замените „uri“ и „uri2“ в данном примере на рабочие URI):
box.cfg{ replication = { 'uri1', 'uri2' } }
Примечание
Starting from version 2.10.0, there is a number of other ways for specifying several URIs. See syntax examples.
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.
По умолчанию, пользователем считается „guest“.
Реплика в режиме только для чтения не принимает запросы по изменению данных по порту для прослушивания.
Параметр replication
является динамическим, то есть для входа в режим мастера необходимо просто присвоить параметру replication
пустую строку и выполнить следующее:
box.cfg{ replication = новое-значение }
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICATION
Динамический: да
-
replication_anon
¶
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.
Так как анонимная реплика не зарегистрирована в таблице _cluster
, нет никаких ограничений для количества анонимных реплик в наборе: можно создавать их сколько угодно.
Чтобы сделать реплику анонимной, передайте опцию replication_anon=true
в box.cfg
и установите значение read_only
равным true
.
Попробуем создать анонимную реплику. Предположим, что у нас есть мастер с такой настройкой:
box.cfg{listen=3301}
и создан локальный спейс «loc»:
box.schema.space.create('loc', {is_local=true})
box.space.loc:create_index("pk")
Теперь, чтобы настроить анонимную реплику, нам нужно обратиться к box.cfg
, как обычно.
box.cfg{replication_anon=true, read_only=true, replication=3301}
Как было сказано выше, replication_anon
может быть true
только вместе с read_only
. Этот экземпляр получит снимок мастера и начнет следить за его изменениями. Он не получит id, поэтому его значение останется нулевым.
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
...
Теперь можно использовать реплику. Например, можно сделать вставку в локальный спейс:
tarantool> for i = 1,10 do
> box.space.loc:insert{i}
> end
---
...
Заметьте, что пока экземпляр анонимный, увеличится нулевая компонента его vclock
:
tarantool> box.info.vclock
---
- {0: 10, 1: 4}
...
А теперь давайте сделаем анонимную реплику снова обычной:
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-51a46def7661
2019-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> subscribed
2019-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
Эта реплика получила id равный 2. Мы можем снова сделать ее открытой на запись:
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: memtx
before_replace: 'function: 0x01109f9dc8'
on_replace: 'function: 0x01109f9d90'
ck_constraint: []
field_count: 0
temporary: false
index: []
is_local: false
enabled: false
name: test
id: 513
- created
...
tarantool> box.info.vclock
---
- {0: 10, 1: 5, 2: 2}
...
Теперь, как и ожидалось, реплика отслеживает свои изменения во 2-й компоненте vclock. С этого момента она также может стать мастером репликации.
Замечания:
- Нельзя реплицироваться от анонимной реплики.
- Чтобы вернуть анонимный экземпляр к обычному состоянию, сначала запустите его как анонимный, а потом вызовите
box.cfg{replication_anon=false}
- Чтобы деанонимизация прошла успешно, экземпляр должен быть скопирован с какого-то экземпляра, открытого на запись, иначе он не может быть добавлен в таблицу
_cluster
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_ANON
Динамический: да
-
bootstrap_leader
¶
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'},
}
Тип: строка
По умолчанию: null
Environment variable: TT_BOOTSTRAP_LEADER
Динамический: да
-
bootstrap_strategy
¶
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.
Тип: строка
Default: auto
Environment variable: TT_BOOTSTRAP_STRATEGY
Динамический: да
-
replication_connect_timeout
¶
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.
Тип: число с плавающей запятой
По умолчанию: 30
Environment variable: TT_REPLICATION_CONNECT_TIMEOUT
Динамический: да
-
replication_connect_quorum
¶
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.
Пример:
box.cfg { replication_connect_quorum = 2 }
Тип: целое число
По умолчанию: null
Environment variable: TT_REPLICATION_CONNECT_QUORUM
Динамический: да
-
replication_skip_conflict
¶
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.
Однако если указать replication_skip_conflict = true
, пользователи могут задать пропуск таких ошибок. Так, вместо сохранения сломанной транзакции в xlog, там будет записано NOP
(No operation).
Пример:
box.cfg{replication_skip_conflict=true}
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_SKIP_CONFLICT
Динамический: да
Примечание
replication_skip_conflict = true
рекомендуется использовать только для ручного восстановления репликации.
-
replication_sync_lag
¶
Since version 1.9.0.
The maximum lag allowed for a replica.
When a replica syncs
(gets updates from a master), it may not catch up completely.
The number of seconds that the replica is behind the master is called the «lag».
Syncing is considered to be complete when the replica’s lag is less than
or equal to replication_sync_lag
.
Если пользователь задает значение replication_sync_lag
, равное nil или 365 * 100 * 86400 (TIMEOUT_INFINITY), то отставание не имеет значения – реплика всегда будет синхронизирована. Кроме того, отставание не учитывается (считается бесконечным), если мастер работает на версии Tarantool старше 1.7.7, которая не отправляет сообщения контрольного сигнала.
Этот параметр не учитывается во время настройки. Для получения подробной информации, см. статус orphan.
Тип: число с плавающей запятой
По умолчанию: 10
Environment variable: TT_REPLICATION_SYNC_LAG
Динамический: да
-
replication_sync_timeout
¶
Since version 1.10.2.
The number of seconds that a node waits when trying to sync with
other nodes in a replica set (see bootstrap_strategy),
after connecting or during configuration update.
This could fail indefinitely if replication_sync_lag
is smaller
than network latency, or if the replica cannot keep pace with master
updates. If replication_sync_timeout
expires, the replica
enters orphan status.
Тип: число с плавающей запятой
По умолчанию: 300
Environment variable: TT_REPLICATION_SYNC_TIMEOUT
Динамический: да
Примечание
The default replication_sync_timeout
value is going to be changed in future versions from 300
to 0
.
You can learn the reasoning behind this decision from the Default value for replication_sync_timeout topic, which also describes how to try the new behavior in the current version.
-
replication_timeout
¶
Since version 1.7.5.
If the master has no updates to send to the replicas, it sends heartbeat messages
every replication_timeout
seconds, and each replica sends an ACK packet back.
И мастер, и реплики запрограммированы разорвать соединение при отсутствии сообщений в течение четырех промежутков времени, указанного в параметре replication_timeout
. После разрыва соединения реплика пытается снова подключиться к мастеру.
См. дополнительную информацию в разделе Мониторинг набора реплик.
Тип: целое число
По умолчанию: 1
Environment variable: TT_REPLICATION_TIMEOUT
Динамический: да
-
replicaset_uuid
¶
Since version 1.9.0.
As described in section
«Replication architecture»,
each replica set is identified by a
universally unique identifier
called replica set UUID, and each instance is identified by an
instance UUID.
Как правило, достаточно позволить системе сгенерировать и форматировать строки, содержащие UUID, которые будут храниться постоянно.
Однако, некоторые администраторы предпочитают сохранять конфигурацию Tarantool в центральном репозитории, например, Apache ZooKeeper. Они могут самостоятельно присвоить значения экземплярам (instance_uuid) и набору реплик (replicaset_uuid
) при первом запуске.
Общие правила:
- Значения должны быть действительно уникальными; они не должны одновременно принадлежать другим экземплярам или наборам реплик в той же инфраструктуре.
- Значения должны использоваться постоянно, неизменно с первого запуска (первоначальные значения хранятся в файлах снимков и проверяются при каждом перезапуске системы).
- Значения должны соответствовать требованиям RFC 4122. Нулевой UUID не допускается.
Формат UUID включает в себя шестнадцать октетов, представленных в виде 32 шестнадцатеричных чисел (с основанием 16) в пяти группах, разделенных дефисами в форме 8-4-4-4-12
– 36 символов (32 буквенно-цифровых символа и четыре дефиса).
Пример:
box.cfg{replicaset_uuid='7b853d13-508b-4b8e-82e6-806f088ea6e9'}
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_UUID
Динамический: нет
-
instance_uuid
¶
Since version 1.9.0.
For replication administration purposes, it is possible to set the
universally unique identifiers
of the instance (instance_uuid
) and the replica set
(replicaset_uuid
), instead of having the system generate the values.
Для получения подробной информации см. описание параметра replicaset_uuid.
Пример:
box.cfg{instance_uuid='037fec43-18a9-4e12-a684-a42b716fcd02'}
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_UUID
Динамический: нет
-
replication_synchro_quorum
¶
Since version 2.5.1.
For synchronous replication only.
This option tells how many replicas should confirm the receipt of a
synchronous transaction before it can finish its commit.
Since version 2.5.3,
the option supports dynamic evaluation of the quorum number.
That is, the number of quorum can be specified not as a constant number, but as a function instead.
In this case, the option returns the formula evaluated.
The result is treated as an integer number.
Once any replicas are added or removed, the expression is re-evaluated automatically.
For example,
box.cfg{replication_synchro_quorum = "N / 2 + 1"}
Where N
is a current number of registered replicas in a cluster.
Keep in mind that the example above represents a canonical quorum definition.
The formula at least 50% of the cluster size + 1
guarantees data reliability.
Using a value less than the canonical one might lead to unexpected results,
including a split-brain.
Since version 2.10.0, this option
does not account for anonymous replicas.
По умолчанию значение параметра равно N / 2 + 1
.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Если значение параметра равно 1
, синхронные транзакции работают как асинхронные, пока они не настроены. 1
означает, что для коммита достаточно успешной записи в WAL на мастере.
Тип: число
Default: N / 2 + 1 (before version 2.10.0, the default value was 1)
Environment variable: TT_REPLICATION_SYNCHRO_QUORUM
Динамический: да
-
replication_synchro_timeout
¶
Since version 2.5.1.
For synchronous replication only.
Tells how many seconds to wait for a synchronous transaction quorum
replication until it is declared failed and is rolled back.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Тип: число
По умолчанию: 5
Environment variable: TT_REPLICATION_SYNCHRO_TIMEOUT
Динамический: да
-
replication_threads
¶
Since version 2.10.0.
The number of threads spawned to decode the incoming replication data.
The default value is 1
.
It means that a single separate thread handles all the incoming replication streams.
In most cases, one thread is enough for all incoming data.
Therefore, it is likely that the user will not need to set this configuration option.
Possible values range from 1 to 1000.
If there are multiple replication threads, connections to serve are distributed evenly between the threads.
Тип: число
По умолчанию: 1
Possible values: from 1 to 1000
Environment variable: TT_REPLICATION_THREADS
Dynamic: no
-
election_mode
¶
Since version 2.6.1.
Specify the role of a replica set node in the
leader election process.
Possible values:
- off
- voter
- candidate
- manual.
Participation of a replica set node in the automated leader election can be
turned on and off by this option.
The default value is off
. All nodes that have values other than off
run the Raft state machine internally talking to other nodes according
to the Raft leader election protocol. When the option is off
, the node
accepts Raft messages
from other nodes, but it doesn’t participate in the election activities,
and this doesn’t affect the node’s state. So, for example, if a node is not
a leader but it has election_mode = 'off'
, it is writable anyway.
You can control which nodes can become a leader. If you want a node
to participate in the election process but don’t want that it becomes
a leaders, set the election_mode
option to voter
. In this case,
the election works as usual, this particular node will vote for other nodes,
but won’t become a leader.
If the node should be able to become a leader, use election_mode = 'candidate'
.
Since version 2.8.2, the manual election mode is introduced.
It may be used when a user wants to control which instance is the leader explicitly instead of relying on
the Raft election algorithm.
When an instance is configured with the election_mode='manual'
, it behaves as follows:
- By default, the instance acts like a voter – it is read-only and may vote for other instances that are candidates.
- Once box.ctl.promote() is called, the instance becomes a candidate and starts a new election round.
If the instance wins the elections, it becomes a leader, but won’t participate in any new elections.
Тип: строка
Default: „off“
Environment variable: TT_ELECTION_MODE
Динамический: да
-
election_timeout
¶
Since version 2.6.1.
Specify the timeout between election rounds in the
leader election process if the previous round
ended up with a split-vote.
In the leader election process, there
can be an election timeout for the case of a split-vote.
The timeout can be configured using this option; the default value is
5 seconds.
It is quite big, and for most of the cases it can be freely lowered to
300-400 ms. It can be a floating point value (300 ms would be
box.cfg{election_timeout = 0.3}
).
To avoid the split vote repeat, the timeout is randomized on each node
during every new election, from 100% to 110% of the original timeout value.
For example, if the timeout is 300 ms and there are 3 nodes started
the election simultaneously in the same term,
they can set their election timeouts to 300, 310, and 320 respectively,
or to 305, 302, and 324, and so on. In that way, the votes will never be split
because the election on different nodes won’t be restarted simultaneously.
Тип: число
По умолчанию: 5
Environment variable: TT_ELECTION_TIMEOUT
Динамический: да
-
election_fencing_mode
¶
Since version 2.11.0.
In earlier Tarantool versions, use election_fencing_enabled instead.
Specify the leader fencing mode that
affects the leader election process. When the parameter is set to soft
or strict
, the leader resigns its leadership if it has less than
replication_synchro_quorum
of alive connections to the cluster nodes.
The resigning leader receives the status of a
follower in the current election term and becomes
read-only.
- In
soft
mode, a connection is considered dead if there are no responses for
4*replication_timeout seconds both on the current leader and the followers.
- In
strict
mode, a connection is considered dead if there are no responses
for 2*replication_timeout seconds on the
current leader and
4*replication_timeout seconds on the
followers. This improves chances that there is only one leader at any time.
Fencing applies to the instances that have the
election_mode set to candidate
or manual
.
To turn off leader fencing, set election_fencing_mode
to off
.
Тип: строка
Default: „soft“
Environment variable: TT_ELECTION_FENCING_MODE
Динамический: да
-
instance_name
¶
Since version 3.0.0.
Specify the instance name.
This value must be unique in a replica set.
The following rules are applied to instance names:
- The maximum number of symbols is 63.
- Should start with a letter.
- Can contain lowercase letters (a-z). If uppercase letters are used, they are converted to lowercase.
- Can contain digits (0-9).
- Can contain the following characters:
-
, _
.
To change or remove the specified name, you should temporarily set the box.cfg.force_recovery configuration option to true
.
When all the names are updated and all the instances synced, box.cfg.force_recovery
can be set back to false
.
Примечание
The instance name is persisted in the box.space._cluster system space.
See also: box.info.name
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_NAME
Динамический: нет
-
replicaset_name
¶
Since version 3.0.0.
Specify the name of a replica set to which this instance belongs.
This value must be the same for all instances of the replica set.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The replica set name is persisted in the box.space._schema system space.
See also: box.info.replicaset
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_NAME
Динамический: нет
-
cluster_name
¶
Since version 3.0.0.
Specify the name of a cluster to which this instance belongs.
This value must be the same for all instances of the cluster.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The cluster name is persisted in the box.space._schema system space.
See also: box.info.cluster
Тип: строка
По умолчанию: null
Environment variable: TT_CLUSTER_NAME
Динамический: нет
Работа с сетями
-
io_collect_interval
¶
Since version 1.4.9.
The instance will sleep for io_collect_interval seconds between iterations
of the event loop. Can be used to reduce CPU load in deployments in which
the number of client connections is large, but requests are not so frequent
(for example, each connection issues just a handful of requests per second).
Тип: число с плавающей запятой
По умолчанию: null
Environment variable: TT_IO_COLLECT_INTERVAL
Динамический: да
-
net_msg_max
¶
Since version 1.10.1.
To handle messages, Tarantool allocates fibers.
To prevent fiber overhead from affecting the whole system,
Tarantool restricts how many messages the fibers handle,
so that some pending requests are blocked.
В мощных системах увеличьте значение net_msg_max
, и планировщик немедленно приступит к обработке отложенных запросов.
В более слабых системах уменьшите значение net_msg_max
, чтобы снизить загрузку, хотя это и займет некоторое время, поскольку планировщик будет ожидать завершения уже запущенных запросов.
When net_msg_max
is reached,
Tarantool suspends processing of incoming packages until it
has processed earlier messages. This is not a direct restriction of
the number of fibers that handle network messages, rather it
is a system-wide restriction of channel bandwidth.
This in turn causes restriction of the number of incoming
network messages that the
transaction processor thread
handles, and therefore indirectly affects the fibers that handle
network messages.
(The number of fibers is smaller than the number of messages because
messages can be released as soon as they are delivered, while
incoming requests might not be processed until some time after delivery.)
Для стандартных систем подойдет значение, используемое по умолчанию (768).
Тип: целое число
По умолчанию: 768
Environment variable: TT_NET_MSG_MAX
Динамический: да
-
readahead
¶
Since version 1.6.2.
The size of the read-ahead buffer associated with a client connection. The
larger the buffer, the more memory an active connection consumes and the
more requests can be read from the operating system buffer in a single
system call. The rule of thumb is to make sure the buffer can contain at
least a few dozen requests. Therefore, if a typical tuple in a request is
large, e.g. a few kilobytes or even megabytes, the read-ahead buffer size
should be increased. If batched request processing is not used, it’s prudent
to leave this setting at its default.
Тип: целое число
По умолчанию: 16320
Environment variable: TT_READAHEAD
Динамический: да
-
iproto_threads
¶
Since version 2.8.1.
The number of network threads.
There can be unusual workloads where the network thread
is 100% loaded and the transaction processor thread is not, so the network
thread is a bottleneck. In that case set iproto_threads
to 2 or more.
The operating system kernel will determine which connection goes to
which thread.
On typical systems, the default value (1) is correct.
Тип: целое число
По умолчанию: 1
Environment variable: TT_IPROTO_THREADS
Динамический: нет
Запись в журнал
This section provides information on how to configure options related to logging.
You can also use the log module to configure logging in your
application.
-
log_level
¶
Since version 1.6.2.
Specify the level of detail the log has. There are the following levels:
- 0 –
fatal
- 1 –
syserror
- 2 –
error
- 3 –
crit
- 4 –
warn
- 5 –
info
- 6 –
verbose
- 7 –
debug
By setting log_level
, you can enable logging of all events with severities above
or equal to the given level. Tarantool prints logs to the standard
error stream by default. This can be changed with the
log configuration parameter.
Type: integer, string
По умолчанию: 5
Environment variable: TT_LOG_LEVEL
Динамический: да
Примечание
Prior to Tarantool 1.7.5 there were only six levels and DEBUG
was
level 6. Starting with Tarantool 1.7.5, VERBOSE
is level 6 and DEBUG
is level 7.
VERBOSE
is a new level for monitoring repetitive events which would cause
too much log writing if INFO
were used instead.
-
log
¶
Since version 1.7.4.
By default, Tarantool sends the log to the standard error stream
(stderr
). If log
is specified, Tarantool can send the log to a:
- file
- pipe
- system logger
Example 1: sending the log to the tarantool.log
file.
box.cfg{log = 'tarantool.log'}
-- или
box.cfg{log = 'file:tarantool.log'}
This opens the file tarantool.log
for output on the server’s default
directory. If the log
string has no prefix or has the prefix «file:»,
then the string is interpreted as a file path.
Example 2: sending the log to a pipe.
box.cfg{log = '| cronolog tarantool.log'}
-- or
box.cfg{log = 'pipe: cronolog tarantool.log'}
This starts the program cronolog when the server starts, and
sends all log messages to the standard input (stdin
) of cronolog
.
If the log
string begins with „|“ or has the prefix «pipe:»,
then the string is interpreted as a Unix
pipeline.
Example 3: sending the log to syslog.
box.cfg{log = 'syslog:identity=tarantool'}
-- или
box.cfg{log = 'syslog:facility=user'}
-- или
box.cfg{log = 'syslog:identity=tarantool,facility=user'}
-- или
box.cfg{log = 'syslog:server=unix:/dev/log'}
If the log
string begins with «syslog:», then it is
interpreted as a message for the
syslogd program, which normally
is running in the background on any Unix-like platform.
The setting can be syslog:
, syslog:facility=...
, syslog:identity=...
,
syslog:server=...
, or a combination.
- The
syslog:identity
setting is an arbitrary string, which is placed at
the beginning of all messages. The default value is «tarantool».
- В настоящий момент настройка
syslog:facility
не учитывается, но будет использоваться в дальнейшем. Ее значением должно быть одно из ключевых слов syslog, которые сообщают программе syslogd, куда отправлять сообщение. Возможные значения: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7. По умолчанию: user.
- The
syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path beginning with «unix:», or an ipv4 port number.
The default socket value is: dev/log
(on Linux) or /var/run/syslog
(on macOS).
The default port value is: 514, the UDP port.
When logging to a file, Tarantool reopens the log on SIGHUP.
When log is a program, its PID is saved in the log.pid
variable. You need to send it a signal to rotate logs.
Тип: строка
По умолчанию: null
Environment variable: TT_LOG
Динамический: нет
-
log_nonblock
¶
Since version 1.7.4.
If log_nonblock
equals true, Tarantool does not block during logging
when the system is not ready for writing, and drops the message
instead. If log_level is high, and many
messages go to the log, setting log_nonblock
to true may improve
logging performance at the cost of some log messages getting lost.
This parameter has effect only if log is
configured to send logs to a pipe or system logger.
The default log_nonblock
value is nil, which means that
blocking behavior corresponds to the logger type:
- false for
stderr
and file loggers.
- true for a pipe and system logger.
This is a behavior change: in earlier versions of the Tarantool
server, the default value was true.
Тип: логический
По умолчанию: nil
Environment variable: TT_LOG_NONBLOCK
Динамический: нет
-
too_long_threshold
¶
Since version 1.6.2.
If processing a request takes longer than the given value (in seconds),
warn about it in the log. Has effect only if log_level is greater than or equal to 4 (WARNING).
Тип: число с плавающей запятой
По умолчанию: 0.5
Environment variable: TT_TOO_LONG_THRESHOLD
Динамический: да
-
log_format
¶
Since version 1.7.6.
Log entries have two possible formats:
- „plain“ (по умолчанию) или
- „json“ (более детально с JSON-метками).
Here is what a log entry looks like if box.cfg{log_format='plain'}
:
2017-10-16 11:36:01.508 [18081] main/101/interactive I> set 'log_format' configuration option to "plain"
Here is what a log entry looks like if box.cfg{log_format='json'}
:
{"time": "2017-10-16T11:36:17.996-0600",
"level": "INFO",
"message": "set 'log_format' configuration option to \"json\"",
"pid": 18081,|
"cord_name": "main",
"fiber_id": 101,
"fiber_name": "interactive",
"file": "builtin\/box\/load_cfg.lua",
"line": 317}
The log_format='plain'
entry has a time value, process ID,
cord name, fiber_id,
fiber_name,
log level, and message.
The log_format='json'
entry has the same fields along with their labels,
and in addition has the file name and line number of the Tarantool source.
Тип: строка
По умолчанию: „plain“
Environment variable: TT_LOG_FORMAT
Динамический: да
-
log_modules
¶
Since version 2.11.0.
Configure the specified log levels (log_level) for different modules.
You can specify a logging level for the following module types:
- Modules (files) that use the default logger.
Example: Set log levels for files that use the default logger.
- Modules that use custom loggers created using the log.new() function.
Example: Set log levels for modules that use custom loggers.
- The
tarantool
module that enables you to configure the logging level for Tarantool core messages. Specifically, it configures the logging level for messages logged from non-Lua code, including C modules.
Example: Set a log level for C modules.
Type: table
Default: blank
Environment variable: TT_LOG_MODULES
Динамический: да
Example 1: Set log levels for files that use the default logger
Suppose you have two identical modules placed by the following paths: test/logging/module1.lua
and test/logging/module2.lua
.
These modules use the default logger and look as follows:
return {
say_hello = function()
local log = require('log')
log.info('Info message from module1')
end
}
To load these modules in your application, you need to add the corresponding require
directives:
module1 = require('test.logging.module1')
module2 = require('test.logging.module2')
To configure logging levels, you need to provide module names corresponding to paths to these modules.
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function:
box_cfg = { log_modules = {
['test.logging.module1'] = 'verbose',
['test.logging.module2'] = 'error' }
}
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1.say_hello()
shows a message but module2.say_hello()
is swallowed:
-- Prints 'info' messages --
module1.say_hello()
--[[
[92617] main/103/interactive/test.logging.module1 I> Info message from module1
---
...
--]]
-- Swallows 'info' messages --
module2.say_hello()
--[[
---
...
--]]
Example 2: Set log levels for modules that use custom loggers
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the verbose
level for module1
and the error
level for module2
:
box_cfg = { log_level = 'warn',
log_modules = {
module1 = 'verbose',
module2 = 'error' }
}
To create custom loggers, call the log.new() function:
-- Creates new loggers --
module1_log = require('log').new('module1')
module2_log = require('log').new('module2')
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1_log.info()
shows a message but module2_log.info()
is swallowed:
-- Prints 'info' messages --
module1_log.info('Info message from module1')
--[[
[16300] main/103/interactive/module1 I> Info message from module1
---
...
--]]
-- Swallows 'debug' messages --
module1_log.debug('Debug message from module1')
--[[
---
...
--]]
-- Swallows 'info' messages --
module2_log.info('Info message from module2')
--[[
---
...
--]]
Example 3: Set a log level for C modules
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the info
level for the tarantool
module:
box_cfg = { log_level = 'warn',
log_modules = { tarantool = 'info' } }
The specified level affects messages logged from C modules:
ffi = require('ffi')
-- Prints 'info' messages --
ffi.C._say(ffi.C.S_INFO, nil, 0, nil, 'Info message from C module')
--[[
[6024] main/103/interactive I> Info message from C module
---
...
--]]
-- Swallows 'debug' messages --
ffi.C._say(ffi.C.S_DEBUG, nil, 0, nil, 'Debug message from C module')
--[[
---
...
--]]
The example above uses the LuaJIT ffi library to call C functions provided by the say
module.
This example illustrates how «rotation» works, that is, what happens when the server
instance is writing to a log and signals are used when archiving it.
Start with two terminal shells: Terminal #1 and Terminal #2.
In Terminal #1, start an interactive Tarantool session.
Then, use the log
property to send logs to Log_file
and
call log.info
to put a message in the log file.
box.cfg{log='Log_file'}
log = require('log')
log.info('Log Line #1')
In Terminal #2, use the mv
command to rename the log file to Log_file.bak
.
mv Log_file Log_file.bak
As a result, the next log message will go to Log_file.bak
.
Go back to Terminal #1 and put a message «Log Line #2» in the log file.
log.info('Log Line #2')
In Terminal #2, use ps
to find the process ID of the Tarantool instance.
ps -A | grep tarantool
In Terminal #2, execute kill -HUP
to send a SIGHUP signal to the Tarantool instance.
Tarantool will open Log_file
again, and the next log message will go to Log_file
.
kill -HUP process_id
The same effect could be accomplished by calling log.rotate.
In Terminal #1, put a message «Log Line #3» in the log file.
log.info('Log Line #3')
In Terminal #2, use less
to examine files.
Log_file.bak
will have the following lines …
2015-11-30 15:13:06.373 [27469] main/101/interactive I> Log Line #1`
2015-11-30 15:14:25.973 [27469] main/101/interactive I> Log Line #2`
… and Log_file
will look like this:
log file has been reopened
2015-11-30 15:15:32.629 [27469] main/101/interactive I> Log Line #3
Audit log
Enterprise Edition
Audit log features are available in the Enterprise Edition only.
The audit_*
parameters define configuration related to audit logging.
-
audit_extract_key
¶
Since: 3.0.0.
If set to true
, the audit subsystem extracts and prints only the primary key instead of full
tuples in DML events (space_insert
, space_replace
, space_delete
).
Otherwise, full tuples are logged.
The option may be useful in case tuples are big.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_AUDIT_EXTRACT_KEY
-
audit_filter
¶
Enable logging for a specified subset of audit events.
This option accepts the following values:
- Event names (for example,
password_change
). For details, see Audit log events.
- Event groups (for example,
audit
). For details, see Event groups.
The option contains either one value from Possible values
section (see below) or a combination of them.
To enable custom audit log events, specify the custom
value in this option.
The default value is compatibility
, which enables logging of all events available before 2.10.0.
Example
box.cfg{
audit_log = 'audit.log',
audit_filter = 'audit,auth,priv,password_change,access_denied'
}
Type: array
Possible values: „all“, „audit“, „auth“, „priv“, „ddl“, „dml“, „data_operations“, „compatibility“,
„audit_enable“, „auth_ok“, „auth_fail“, „disconnect“, „user_create“, „user_drop“, „role_create“, „role_drop“,
„user_disable“, „user_enable“, „user_grant_rights“, „role_grant_rights“, „role_revoke_rights“, „password_change“,
„access_denied“, „eval“, „call“, „space_select“, „space_create“, „space_alter“, „space_drop“, „space_insert“,
„space_replace“, „space_delete“, „custom“
Default: „compatibility“
Environment variable: TT_AUDIT_FILTER
-
audit_format
¶
Specify the format that is used for the audit log events – plain text, CSV or JSON format.
Plain text is used by default. This human-readable format can be efficiently compressed.
box.cfg{audit_log = 'audit.log', audit_format = 'plain'}
Example
remote: session_type:background module:common.admin.auth user: type:custom_tdg_audit tag:tdg_severity_INFO description:[5e35b406-4274-4903-857b-c80115275940] subj: "anonymous", msg: "Access granted to anonymous user"
The JSON format is more convenient to receive log events, analyze them and integrate them with other systems if needed.
box.cfg{audit_log = 'audit.log', audit_format = 'json'}
Example
{"time": "2022-11-17T21:55:49.880+0300", "remote": "", "session_type": "background", "module": "common.admin.auth", "user": "", "type": "custom_tdg_audit", "tag": "tdg_severity_INFO", "description": "[c26cd11a-3342-4ce6-8f0b-a4b222268b9d] subj: \"anonymous\", msg: \"Access granted to anonymous user\""}
Using the CSV format allows you to view audit log events in tabular form.
box.cfg{audit_log = 'audit.log', audit_format = 'csv'}
Example
2022-11-17T21:58:03.131+0300,,background,common.admin.auth,,,custom_tdg_audit,tdg_severity_INFO,"[b3dfe2a3-ec29-4e61-b747-eb2332c83b2e] subj: ""anonymous"", msg: ""Access granted to anonymous user"""
Тип: строка
Possible values: „json“, „csv“, „plain“
Default: „json“
Environment variable: TT_AUDIT_FORMAT
-
audit_log
¶
Enable audit logging and define the log location.
This option accepts a string value that allows you to define the log location.
The following locations are supported:
- File: to write audit logs to a file, specify a path to a file (with an optional
file
prefix)
- Pipeline: to start a program and write audit logs to it, specify a program name (with
|
or pipe
prefix)
- System log: to write audit logs to a system log, specify a message for
syslogd
(with syslog
prefix)
See the examples below.
By default, audit logging is disabled.
Example: Writing to a file
box.cfg{audit_log = 'audit_tarantool.log'}
-- or
box.cfg{audit_log = 'file:audit_tarantool.log'}
This opens the audit_tarantool.log
file for output in the server’s default directory.
If the audit_log
string has no prefix or the prefix file:
, the string is interpreted as a file path.
If you log to a file, Tarantool will reopen the audit log at SIGHUP.
Example: Sending to a pipeline
box.cfg{audit_log = '| cronolog audit_tarantool.log'}
-- or
box.cfg{audit_log = 'pipe: cronolog audit_tarantool.log'}'
This starts the cronolog program when the server starts
and sends all audit_log
messages to cronolog’s standard input (stdin
).
If the audit_log
string starts with „|“ or contains the prefix pipe:
,
the string is interpreted as a Unix pipeline.
If log is a program, check out its pid and send it a signal to rotate logs.
Example: Writing to a system log
Предупреждение
Below is an example of writing audit logs to a directory shared with the system logs.
Tarantool allows this option, but it is not recommended to do this to avoid difficulties
when working with audit logs. System and audit logs should be written separately.
To do this, create separate paths and specify them.
This sample configuration sends the audit log to syslog:
box.cfg{audit_log = 'syslog:identity=tarantool'}
-- or
box.cfg{audit_log = 'syslog:facility=user'}
-- or
box.cfg{audit_log = 'syslog:identity=tarantool,facility=user'}
-- or
box.cfg{audit_log = 'syslog:server=unix:/dev/log'}
If the audit_log
string starts with «syslog:»,
it is interpreted as a message for the syslogd program,
which normally runs in the background of any Unix-like platform.
The setting can be „syslog:“, „syslog:facility=…“, „syslog:identity=…“, „syslog:server=…“ or a combination.
The syslog:identity
setting is an arbitrary string that is placed at the beginning of all messages.
The default value is tarantool
.
The syslog:facility
setting is currently ignored, but will be used in the future.
The value must be one of the syslog keywords
that tell syslogd
where to send the message.
The possible values are auth
, authpriv
, cron
, daemon
, ftp
,
kern
, lpr
, mail
, news
, security
, syslog
, user
, uucp
,
local0
, local1
, local2
, local3
, local4
, local5
, local6
, local7
.
The default value is local7
.
The syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path starting with «unix:» or an ipv4 port number.
The default socket value is /dev/log
(on Linux) or /var/run/syslog
(on Mac OS).
The default port value is 514, which is the UDP port.
An example of a Tarantool audit log entry in the syslog:
09:32:52 tarantool_audit: {"time": "2024-02-08T09:32:52.190+0300", "uuid": "94454e46-9a0e-493a-bb9f-d59e44a43581", "severity": "INFO", "remote": "unix/:(socket)", "session_type": "console", "module": "tarantool", "user": "admin", "type": "space_create", "tag": "", "description": "Create space bands"}
Тип: строка
Possible values: see the string format above
Default: „nill“
Environment variable: TT_AUDIT_LOG
-
audit_nonblock
¶
Specify the logging behavior if the system is not ready to write.
If set to true
, Tarantool does not block during logging if the system is non-writable and writes a message instead.
Using this value may improve logging performance at the cost of losing some log messages.
Примечание
The option only has an effect if the audit_log is set to syslog
or pipe
.
Setting audit_nonblock
to true
is not allowed if the output is to a file.
In this case, set audit_nonblock
to false
.
Тип: логический
По умолчанию: true
Environment variable: TT_AUDIT_NONBLOCK
-
audit_spaces
¶
Since: 3.0.0.
The array of space names for which data operation events (space_select
, space_insert
, space_replace
,
space_delete
) should be logged. The array accepts string values.
If set to box.NULL, the data operation events are logged for all spaces.
Example
In the example, only the events of bands
and singers
spaces are logged:
box.cfg{
audit_spaces = 'bands,singers'
}
Type: array
Default: box.NULL
Environment variable: TT_AUDIT_SPACES
Authentication
Enterprise Edition
Authentication features are supported by the Enterprise Edition only.
- auth_delay
- auth_retries
- auth_type
- disable_guest
- password_min_length
- password_enforce_uppercase
- password_enforce_lowercase
- password_enforce_digits
- password_enforce_specialchars
- password_lifetime_days
- password_history_length
-
auth_delay
¶
Since 2.11.0.
Specify a period of time (in seconds) that a specific user should wait
for the next attempt after failed authentication.
With the configuration below, Tarantool refuses the authentication attempt if the previous
attempt was less than 5 seconds ago.
box.cfg{ auth_delay = 5 }
Тип: число
Default: 0
Environment variable: TT_AUTH_DELAY
Динамический: да
-
auth_retries
¶
Since 3.0.0.
Specify the maximum number of authentication retries allowed before auth_delay
is enforced.
The default value is 0, which means auth_delay
is enforced after the first failed authentication attempt.
The retry counter is reset after auth_delay
seconds since the first failed attempt.
For example, if a client tries to authenticate fewer than auth_retries
times within auth_delay
seconds, no authentication delay is enforced.
The retry counter is also reset after any successful authentication attempt.
Тип: число
Default: 0
Environment variable: TT_AUTH_RETRIES
Динамический: да
-
auth_type
¶
Since 2.11.0.
Specify an authentication protocol:
- „chap-sha1“: use the CHAP protocol to authenticate users with
SHA-1
hashing applied to passwords.
- „pap-sha256“: use PAP authentication with the
SHA256
hashing algorithm.
For new users, the box.schema.user.create method
will generate authentication data using PAP-SHA256
.
For existing users, you need to reset a password using
box.schema.user.passwd
to use the new authentication protocol.
Тип: строка
Default value: „chap-sha1“
Environment variable: TT_AUTH_TYPE
Динамический: да
-
disable_guest
¶
Since 2.11.0.
If true, disables access over remote connections
from unauthenticated or guest access users.
This option affects both
net.box and
replication connections.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_DISABLE_GUEST
Динамический: да
-
password_min_length
¶
Since 2.11.0.
Specify the minimum number of characters for a password.
The following example shows how to set the minimum password length to 10.
box.cfg{ password_min_length = 10 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_MIN_LENGTH
Динамический: да
-
password_enforce_uppercase
¶
Since 2.11.0.
If true, a password should contain uppercase letters (A-Z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_UPPERCASE
Динамический: да
-
password_enforce_lowercase
¶
Since 2.11.0.
If true, a password should contain lowercase letters (a-z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_LOWERCASE
Динамический: да
-
password_enforce_digits
¶
Since 2.11.0.
If true, a password should contain digits (0-9).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_DIGITS
Динамический: да
-
password_enforce_specialchars
¶
Since 2.11.0.
If true, a password should contain at least one special character (such as &|?!@$
).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARS
Динамический: да
-
password_lifetime_days
¶
Since 2.11.0.
Specify the maximum period of time (in days) a user can use the same password.
When this period ends, a user gets the «Password expired» error on a login attempt.
To restore access for such users, use box.schema.user.passwd.
Примечание
The default 0 value means that a password never expires.
The example below shows how to set a maximum password age to 365 days.
box.cfg{ password_lifetime_days = 365 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_LIFETIME_DAYS
Динамический: да
-
password_history_length
¶
Since 2.11.0.
Specify the number of unique new user passwords before an old password can be reused.
In the example below, a new password should differ from the last three passwords.
box.cfg{ password_history_length = 3 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_HISTORY_LENGTH
Динамический: да
Примечание
Tarantool uses the auth_history
field in the
box.space._user
system space to store user passwords.
Flight recorder
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶
Since 2.11.0.
Enable the flight recorder.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FLIGHTREC_ENABLED
Динамический: да
-
flightrec_logs_size
¶
Since 2.11.0.
Specify the size (in bytes) of the log storage.
You can set this option to 0
to disable the log storage.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_LOGS_SIZE
Динамический: да
-
flightrec_logs_max_msg_size
¶
Since 2.11.0.
Specify the maximum size (in bytes) of the log message.
The log message is truncated if its size exceeds this limit.
Тип: целое число
Default: 4096
Maximum: 16384
Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZE
Динамический: да
-
flightrec_logs_log_level
¶
Since 2.11.0.
Specify the level of detail the log has.
You can learn more about log levels from the log_level
option description.
Note that the flightrec_logs_log_level
value might differ from log_level
.
Тип: целое число
Default: 6
Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVEL
Динамический: да
-
flightrec_metrics_period
¶
Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump.
So, this value defines how much historical metrics data is collected up to the moment of crash.
The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое число
Default: 180
Environment variable: TT_FLIGHTREC_METRICS_PERIOD
Динамический: да
-
flightrec_metrics_interval
¶
Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics.
This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB,
you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: число
По умолчанию: 1.0
Minimum: 0.001
Environment variable: TT_FLIGHTREC_METRICS_INTERVAL
Динамический: да
-
flightrec_requests_size
¶
Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data.
You can set this parameter to 0
to disable a storage of requests and responses.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_REQUESTS_SIZE
Динамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
- 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
-
background
¶ 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.
Важно
Do not enable the background mode for applications intended to run by the
tt
utility. For more information, see the tt start reference.Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_BACKGROUNDДинамический: нет
-
coredump
¶ 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. Ifcoredump
is enabled, Tarantool sets the corresponding resource limit by itself and the administrator doesn’t need to callulimit -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).Тип: логическийEnvironment variable: TT_COREDUMPПо умолчанию: false (ложь)Динамический: нет
-
custom_proc_title
¶ 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
andtop -c
commands).Например, как правило,
ps -ef
показывает процесс Tarantool-сервера так:$ ps -ef | grep tarantool 1000 14939 14188 1 10:53 pts/2 00:00:13 tarantool <running>
Но если указан конфигурационный параметр
custom_proc_title='sessions'
, вывод выглядит так:$ ps -ef | grep tarantool 1000 14939 14188 1 10:53 pts/2 00:00:16 tarantool <running>: sessions
Тип: строкаПо умолчанию: nullEnvironment variable: TT_CUSTOM_PROC_TITLEДинамический: да
-
listen
¶ 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.Как правило, используется значение 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.
Тип: целое число или строкаПо умолчанию: nullEnvironment variable: TT_LISTENДинамический: да
-
memtx_dir
¶ 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.Тип: строкаПо умолчанию: «.»Environment variable: TT_MEMTX_DIRДинамический: нет
-
pid_file
¶ Since version 1.4.9.
Store the process id in this file. Can be relative to work_dir. A typical value is “
tarantool.pid
”.Тип: строкаПо умолчанию: nullEnvironment variable: TT_PID_FILEДинамический: нет
-
read_only
¶ 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 errorER_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.Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_READ_ONLYДинамический: даSetting
read_only == true
affects spaces differently depending on the options that were used during box.schema.space.create, as summarized by this chart:Характеристика Можно создать? Допускает запись? Реплицируется? Сохраняется? (по умолчанию) нет нет да да temporary нет да нет нет is_local нет да нет да
-
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.)
Тип: числоПо умолчанию: 5242880Environment variable: TT_SQL_CACHE_SIZEДинамический: да
-
vinyl_dir
¶ 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
.Тип: строкаПо умолчанию: «.»Environment variable: TT_VINYL_DIRДинамический: нет
-
vinyl_timeout
¶ 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().Тип: число с плавающей запятойПо умолчанию: 60Environment variable: TT_VINYL_TIMEOUTДинамический: да
-
username
¶ Since version 1.4.9.
UNIX user name to switch to after start.
Тип: строкаПо умолчанию: nullEnvironment variable: TT_USERNAMEДинамический: нет
-
wal_dir
¶ 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.Тип: строкаПо умолчанию: «.»Environment variable: TT_WAL_DIRДинамический: нет
-
work_dir
¶ 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 towork_dir
, for example:box.cfg{ work_dir = '/home/user/A', wal_dir = 'B', memtx_dir = 'C' }
поместит xlog-файлы в
/home/user/A/B
, файлы снимков в/home/user/A/C
, а все остальные файлы или поддиректории в/home/user/A
.Тип: строкаПо умолчанию: nullEnvironment variable: TT_WORK_DIRДинамический: нет
-
worker_pool_threads
¶ Since version 1.7.5.
The maximum number of threads to use during execution of certain internal processes (currently socket.getaddrinfo() and coio_call()).
Тип: целое числоПо умолчанию: 4Environment variable: TT_WORKER_POOL_THREADSДинамический: да
-
strip_core
¶ 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 wasfalse
.Тип: логическийПо умолчанию: trueEnvironment variable: TT_STRIP_COREДинамический: нет
-
memtx_use_mvcc_engine
¶ Since version 2.6.1.
Enable transactional manager if set to
true
.Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_MEMTX_USE_MVCC_ENGINEДинамический: нет
Настройка хранения
- 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
-
memtx_memory
¶
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.
Тип: число с плавающей запятой
По умолчанию: 256 * 1024 * 1024 = 268435456 байтов
Minimum: 33554432 bytes (32 MB)
Environment variable: TT_MEMTX_MEMORY
Dynamic: yes but it cannot be decreased
-
memtx_max_tuple_size
¶
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.
Тип: целое число
По умолчанию: 1024 * 1024 = 1048576 байтов
Environment variable: TT_MEMTX_MAX_TUPLE_SIZE
Динамический: да
-
memtx_min_tuple_size
¶
Since version 1.7.4.
Size of the smallest allocation unit. It can be decreased if most
of the tuples are very small.
Тип: целое число
По умолчанию: 16 байтов
Possible values: between 8 and 1048280 inclusive
Environment variable: TT_MEMTX_MIN_TUPLE_SIZE
Динамический: нет
-
memtx_allocator
¶
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.
Тип: строка
Default: „small“
Environment variable: TT_MEMTX_ALLOCATOR
Динамический: нет
-
memtx_sort_threads
¶
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.
Примечание
Since 3.0.0, this option replaces the approach when OpenMP threads are used to parallelize sorting.
For backward compatibility, the OMP_NUM_THREADS
environment variable is taken into account to
set the number of sorting threads.
Тип: целое число
Default: box.NULL
Environment variable: TT_MEMTX_SORT_THREADS
Динамический: нет
-
slab_alloc_factor
¶
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
Тип: число с плавающей запятой
Default: 1.05
Possible values: between 1 and 2 inclusive
Environment variable: TT_SLAB_ALLOC_FACTOR
Динамический: нет
-
slab_alloc_granularity
¶
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
Тип: число
Default: 8 bytes
Environment variable: TT_SLAB_ALLOC_GRANULARITY
Динамический: нет
-
vinyl_bloom_fpr
¶
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.
Тип: число с плавающей запятой
По умолчанию: 0.05
Environment variable: TT_VINYL_BLOOM_FPR
Динамический: нет
-
vinyl_cache
¶
Для версий от 1.7.4. и выше. Размер кэша для движка базы данных vinyl. Размер кэша можно изменить динамически.
Тип: целое число
По умолчанию: 128 * 1024 * 1024 = 134217728 байтов
Environment variable: TT_VINYL_CACHE
Динамический: да
-
vinyl_max_tuple_size
¶
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.
Тип: целое число
По умолчанию: 1024 * 1024 = 1048576 байтов
Environment variable: TT_VINYL_MAX_TUPLE_SIZE
Динамический: нет
-
vinyl_memory
¶
Since version 1.7.4.
The maximum number of in-memory bytes that vinyl uses.
Тип: целое число
По умолчанию: 128 * 1024 * 1024 = 134217728 байтов
Environment variable: TT_VINYL_MEMORY
Dynamic: yes but it cannot be decreased
-
vinyl_page_size
¶
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.
Тип: целое число
По умолчанию: 8 * 1024 = 8192 байтов
Environment variable: TT_VINYL_PAGE_SIZE
Динамический: нет
-
vinyl_range_size
¶
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.
Если vinyl_range_size
содержит не нулевое значение nil и не 0, это значение используется в качестве значения по умолчанию для параметра range_size
в таблице Параметры space_object:create_index().
Если vinyl_range_size
содержит нулевое значение nil или 0, а параметр range_size
не задан при создании индекса, то Tarantool сам задает это значение позднее в результате оценки производительности. Чтобы узнать текущее значение, используйте index_object:stat().range_size.
До версии Tarantool 1.10.2 значение vinyl_range_size
по умолчанию было 1073741824.
Тип: целое число
По умолчанию: nil
Environment variable: TT_VINYL_RANGE_SIZE
Динамический: нет
-
vinyl_run_count_per_level
¶
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.
Тип: целое число
По умолчанию: 2
Environment variable: TT_VINYL_RUN_COUNT_PER_LEVEL
Динамический: нет
-
vinyl_run_size_ratio
¶
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.
Тип: число с плавающей запятой
По умолчанию: 3.5
Environment variable: TT_VINYL_RUN_SIZE_RATIO
Динамический: нет
-
vinyl_read_threads
¶
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.
Тип: целое число
По умолчанию: 1
Environment variable: TT_VINYL_READ_THREADS
Динамический: нет
-
vinyl_write_threads
¶
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.
Тип: целое число
По умолчанию: 4
Environment variable: TT_VINYL_WRITE_THREADS
Динамический: нет
Демон создания контрольных точек
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
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.
Примечание
The garbage collector called by the checkpoint daemon is distinct from the Lua garbage collector
which is for Lua objects, and distinct from the Tarantool garbage collector that specializes in handling shard buckets.
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.
-
checkpoint_interval
¶
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.
Тип: целое число
По умолчанию: 3600 (один час)
Environment variable: TT_CHECKPOINT_INTERVAL
Динамический: да
-
checkpoint_count
¶
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.
Примечание
Snapshots will not be deleted if replication is ongoing and the file has not been relayed to a replica.
Therefore, checkpoint_count
has no effect unless all replicas are alive.
Тип: целое число
По умолчанию: 2
Environment variable: TT_CHECKPOINT_COUNT
Динамический: да
-
checkpoint_wal_threshold
¶
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.
Этот параметр позволяет администраторам справиться с проблемой, которая может возникнуть при вычислении объема дискового пространства для раздела, содержащего файлы WAL.
Тип: целое число
По умолчанию: 10^18 (большое число: можно считать, что предела нет)
Environment variable: TT_CHECKPOINT_WAL_THRESHOLD
Динамический: да
Записи в бинарный журнал и создание снимков
- 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
-
force_recovery
¶
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().
В остальных случаях Tarantool прерывает восстановление на ошибке чтения.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FORCE_RECOVERY
Динамический: нет
-
wal_max_size
¶
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.
Тип: целое число
По умолчанию: 268435456 (256 * 1024 * 1024) байтов
Environment variable: TT_WAL_MAX_SIZE
Динамический: нет
-
snap_io_rate_limit
¶
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.
Тип: число с плавающей запятой
По умолчанию: null
Environment variable: TT_SNAP_IO_RATE_LIMIT
Динамический: да
-
wal_mode
¶
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).
Тип: строка
По умолчанию: «write»
Environment variable: TT_WAL_MODE
Динамический: нет
-
wal_dir_rescan_delay
¶
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.
Тип: число с плавающей запятой
По умолчанию: 2
Environment variable: TT_WAL_DIR_RESCAN_DELAY
Динамический: нет
-
wal_queue_max_size
¶
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.
Примечание
You might consider increasing the wal_queue_max_size
value in case of
large tuples (approximately one megabyte or larger).
Тип: число
Default: 16777216 bytes
Environment variable: TT_WAL_QUEUE_MAX_SIZE
Динамический: да
-
wal_cleanup_delay
¶
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.
Примечание
The wal_cleanup_delay
option has no effect on nodes running as
anonymous replicas.
Тип: число
Default: 14400 seconds
Environment variable: TT_WAL_CLEANUP_DELAY
Динамический: да
-
wal_ext
¶
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
По умолчанию: nil
Environment variable: TT_WAL_EXT
Динамический: да
-
secure_erasing
¶
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.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_SECURE_ERASING
Динамический: да
Горячее резервирование
-
hot_standby
¶
Since version 1.7.4.
Whether to start the server in hot standby mode.
Горячее резервирование – это функция, которая обеспечивает простое восстановление после отказа без репликации.
Предполагается, что есть два экземпляра сервера, использующих одну и ту же конфигурацию. Первый из них станет «основным» экземпляром. Тот, который запускается вторым, станет «резервным» экземпляром.
Чтобы создать резервный экземпляр, запустите второй экземпляр Tarantool-сервера на том же компьютере с теми же настройками конфигурации box.cfg – включая одинаковые директории и ненулевые URI – и с дополнительной настройкой конфигурации hot_standby = true
. В ближайшее время вы увидите уведомление, которое заканчивается словами I> Entering hot standby mode
(вход в режим горячего резервирования). Всё в порядке – это означает, что резервный экземпляр готов взять работу на себя, если основной экземпляр прекратит работу.
Резервный экземпляр начнет инициализацию и попытается заблокировать wal_dir, но не сможет, поскольку директория wal_dir
заблокирована основным экземпляром. Поэтому резервный экземпляр входит в цикл, выполняя чтение журнала упреждающей записи, в который записывает данные основной экземпляр (поэтому два экземпляра всегда синхронизированы), и пытаясь произвести блокировку. Если основной экземпляр по какой-либо причине прекращает работу, блокировка снимается. В таком случае резервный экземпляр сможет заблокировать директорию на себя, подключится по адресу для прослушивания и станет основным экземпляром. В ближайшее время вы увидите уведомление, которое заканчивается словами I> ready to accept requests
(готов принимать запросы).
Таким образом, если основной экземпляр прекращает работу, время простоя отсутствует.
Функция горячего резервирования не работает:
- если wal_dir_rescan_delay = большое число (в Mac OS и FreeBSD); на этих платформах цикл запрограммирован на повторение каждые
wal_dir_rescan_delay
секунд.
- если wal_mode = „none“; будет работать только при
wal_mode = 'write'
или wal_mode = 'fsync'
.
- со спейсами, созданными на движке vinyl engine = „vinyl“; работает с движком memtx
engine = 'memtx'
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_HOT_STANDBY
Динамический: нет
Репликация
- 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
-
replication
¶
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
Если в наборе реплик более одного источника репликации, укажите массив URI, например (замените „uri“ и „uri2“ в данном примере на рабочие URI):
box.cfg{ replication = { 'uri1', 'uri2' } }
Примечание
Starting from version 2.10.0, there is a number of other ways for specifying several URIs. See syntax examples.
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.
По умолчанию, пользователем считается „guest“.
Реплика в режиме только для чтения не принимает запросы по изменению данных по порту для прослушивания.
Параметр replication
является динамическим, то есть для входа в режим мастера необходимо просто присвоить параметру replication
пустую строку и выполнить следующее:
box.cfg{ replication = новое-значение }
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICATION
Динамический: да
-
replication_anon
¶
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.
Так как анонимная реплика не зарегистрирована в таблице _cluster
, нет никаких ограничений для количества анонимных реплик в наборе: можно создавать их сколько угодно.
Чтобы сделать реплику анонимной, передайте опцию replication_anon=true
в box.cfg
и установите значение read_only
равным true
.
Попробуем создать анонимную реплику. Предположим, что у нас есть мастер с такой настройкой:
box.cfg{listen=3301}
и создан локальный спейс «loc»:
box.schema.space.create('loc', {is_local=true})
box.space.loc:create_index("pk")
Теперь, чтобы настроить анонимную реплику, нам нужно обратиться к box.cfg
, как обычно.
box.cfg{replication_anon=true, read_only=true, replication=3301}
Как было сказано выше, replication_anon
может быть true
только вместе с read_only
. Этот экземпляр получит снимок мастера и начнет следить за его изменениями. Он не получит id, поэтому его значение останется нулевым.
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
...
Теперь можно использовать реплику. Например, можно сделать вставку в локальный спейс:
tarantool> for i = 1,10 do
> box.space.loc:insert{i}
> end
---
...
Заметьте, что пока экземпляр анонимный, увеличится нулевая компонента его vclock
:
tarantool> box.info.vclock
---
- {0: 10, 1: 4}
...
А теперь давайте сделаем анонимную реплику снова обычной:
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-51a46def7661
2019-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> subscribed
2019-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
Эта реплика получила id равный 2. Мы можем снова сделать ее открытой на запись:
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: memtx
before_replace: 'function: 0x01109f9dc8'
on_replace: 'function: 0x01109f9d90'
ck_constraint: []
field_count: 0
temporary: false
index: []
is_local: false
enabled: false
name: test
id: 513
- created
...
tarantool> box.info.vclock
---
- {0: 10, 1: 5, 2: 2}
...
Теперь, как и ожидалось, реплика отслеживает свои изменения во 2-й компоненте vclock. С этого момента она также может стать мастером репликации.
Замечания:
- Нельзя реплицироваться от анонимной реплики.
- Чтобы вернуть анонимный экземпляр к обычному состоянию, сначала запустите его как анонимный, а потом вызовите
box.cfg{replication_anon=false}
- Чтобы деанонимизация прошла успешно, экземпляр должен быть скопирован с какого-то экземпляра, открытого на запись, иначе он не может быть добавлен в таблицу
_cluster
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_ANON
Динамический: да
-
bootstrap_leader
¶
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'},
}
Тип: строка
По умолчанию: null
Environment variable: TT_BOOTSTRAP_LEADER
Динамический: да
-
bootstrap_strategy
¶
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.
Тип: строка
Default: auto
Environment variable: TT_BOOTSTRAP_STRATEGY
Динамический: да
-
replication_connect_timeout
¶
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.
Тип: число с плавающей запятой
По умолчанию: 30
Environment variable: TT_REPLICATION_CONNECT_TIMEOUT
Динамический: да
-
replication_connect_quorum
¶
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.
Пример:
box.cfg { replication_connect_quorum = 2 }
Тип: целое число
По умолчанию: null
Environment variable: TT_REPLICATION_CONNECT_QUORUM
Динамический: да
-
replication_skip_conflict
¶
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.
Однако если указать replication_skip_conflict = true
, пользователи могут задать пропуск таких ошибок. Так, вместо сохранения сломанной транзакции в xlog, там будет записано NOP
(No operation).
Пример:
box.cfg{replication_skip_conflict=true}
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_SKIP_CONFLICT
Динамический: да
Примечание
replication_skip_conflict = true
рекомендуется использовать только для ручного восстановления репликации.
-
replication_sync_lag
¶
Since version 1.9.0.
The maximum lag allowed for a replica.
When a replica syncs
(gets updates from a master), it may not catch up completely.
The number of seconds that the replica is behind the master is called the «lag».
Syncing is considered to be complete when the replica’s lag is less than
or equal to replication_sync_lag
.
Если пользователь задает значение replication_sync_lag
, равное nil или 365 * 100 * 86400 (TIMEOUT_INFINITY), то отставание не имеет значения – реплика всегда будет синхронизирована. Кроме того, отставание не учитывается (считается бесконечным), если мастер работает на версии Tarantool старше 1.7.7, которая не отправляет сообщения контрольного сигнала.
Этот параметр не учитывается во время настройки. Для получения подробной информации, см. статус orphan.
Тип: число с плавающей запятой
По умолчанию: 10
Environment variable: TT_REPLICATION_SYNC_LAG
Динамический: да
-
replication_sync_timeout
¶
Since version 1.10.2.
The number of seconds that a node waits when trying to sync with
other nodes in a replica set (see bootstrap_strategy),
after connecting or during configuration update.
This could fail indefinitely if replication_sync_lag
is smaller
than network latency, or if the replica cannot keep pace with master
updates. If replication_sync_timeout
expires, the replica
enters orphan status.
Тип: число с плавающей запятой
По умолчанию: 300
Environment variable: TT_REPLICATION_SYNC_TIMEOUT
Динамический: да
Примечание
The default replication_sync_timeout
value is going to be changed in future versions from 300
to 0
.
You can learn the reasoning behind this decision from the Default value for replication_sync_timeout topic, which also describes how to try the new behavior in the current version.
-
replication_timeout
¶
Since version 1.7.5.
If the master has no updates to send to the replicas, it sends heartbeat messages
every replication_timeout
seconds, and each replica sends an ACK packet back.
И мастер, и реплики запрограммированы разорвать соединение при отсутствии сообщений в течение четырех промежутков времени, указанного в параметре replication_timeout
. После разрыва соединения реплика пытается снова подключиться к мастеру.
См. дополнительную информацию в разделе Мониторинг набора реплик.
Тип: целое число
По умолчанию: 1
Environment variable: TT_REPLICATION_TIMEOUT
Динамический: да
-
replicaset_uuid
¶
Since version 1.9.0.
As described in section
«Replication architecture»,
each replica set is identified by a
universally unique identifier
called replica set UUID, and each instance is identified by an
instance UUID.
Как правило, достаточно позволить системе сгенерировать и форматировать строки, содержащие UUID, которые будут храниться постоянно.
Однако, некоторые администраторы предпочитают сохранять конфигурацию Tarantool в центральном репозитории, например, Apache ZooKeeper. Они могут самостоятельно присвоить значения экземплярам (instance_uuid) и набору реплик (replicaset_uuid
) при первом запуске.
Общие правила:
- Значения должны быть действительно уникальными; они не должны одновременно принадлежать другим экземплярам или наборам реплик в той же инфраструктуре.
- Значения должны использоваться постоянно, неизменно с первого запуска (первоначальные значения хранятся в файлах снимков и проверяются при каждом перезапуске системы).
- Значения должны соответствовать требованиям RFC 4122. Нулевой UUID не допускается.
Формат UUID включает в себя шестнадцать октетов, представленных в виде 32 шестнадцатеричных чисел (с основанием 16) в пяти группах, разделенных дефисами в форме 8-4-4-4-12
– 36 символов (32 буквенно-цифровых символа и четыре дефиса).
Пример:
box.cfg{replicaset_uuid='7b853d13-508b-4b8e-82e6-806f088ea6e9'}
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_UUID
Динамический: нет
-
instance_uuid
¶
Since version 1.9.0.
For replication administration purposes, it is possible to set the
universally unique identifiers
of the instance (instance_uuid
) and the replica set
(replicaset_uuid
), instead of having the system generate the values.
Для получения подробной информации см. описание параметра replicaset_uuid.
Пример:
box.cfg{instance_uuid='037fec43-18a9-4e12-a684-a42b716fcd02'}
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_UUID
Динамический: нет
-
replication_synchro_quorum
¶
Since version 2.5.1.
For synchronous replication only.
This option tells how many replicas should confirm the receipt of a
synchronous transaction before it can finish its commit.
Since version 2.5.3,
the option supports dynamic evaluation of the quorum number.
That is, the number of quorum can be specified not as a constant number, but as a function instead.
In this case, the option returns the formula evaluated.
The result is treated as an integer number.
Once any replicas are added or removed, the expression is re-evaluated automatically.
For example,
box.cfg{replication_synchro_quorum = "N / 2 + 1"}
Where N
is a current number of registered replicas in a cluster.
Keep in mind that the example above represents a canonical quorum definition.
The formula at least 50% of the cluster size + 1
guarantees data reliability.
Using a value less than the canonical one might lead to unexpected results,
including a split-brain.
Since version 2.10.0, this option
does not account for anonymous replicas.
По умолчанию значение параметра равно N / 2 + 1
.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Если значение параметра равно 1
, синхронные транзакции работают как асинхронные, пока они не настроены. 1
означает, что для коммита достаточно успешной записи в WAL на мастере.
Тип: число
Default: N / 2 + 1 (before version 2.10.0, the default value was 1)
Environment variable: TT_REPLICATION_SYNCHRO_QUORUM
Динамический: да
-
replication_synchro_timeout
¶
Since version 2.5.1.
For synchronous replication only.
Tells how many seconds to wait for a synchronous transaction quorum
replication until it is declared failed and is rolled back.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Тип: число
По умолчанию: 5
Environment variable: TT_REPLICATION_SYNCHRO_TIMEOUT
Динамический: да
-
replication_threads
¶
Since version 2.10.0.
The number of threads spawned to decode the incoming replication data.
The default value is 1
.
It means that a single separate thread handles all the incoming replication streams.
In most cases, one thread is enough for all incoming data.
Therefore, it is likely that the user will not need to set this configuration option.
Possible values range from 1 to 1000.
If there are multiple replication threads, connections to serve are distributed evenly between the threads.
Тип: число
По умолчанию: 1
Possible values: from 1 to 1000
Environment variable: TT_REPLICATION_THREADS
Dynamic: no
-
election_mode
¶
Since version 2.6.1.
Specify the role of a replica set node in the
leader election process.
Possible values:
- off
- voter
- candidate
- manual.
Participation of a replica set node in the automated leader election can be
turned on and off by this option.
The default value is off
. All nodes that have values other than off
run the Raft state machine internally talking to other nodes according
to the Raft leader election protocol. When the option is off
, the node
accepts Raft messages
from other nodes, but it doesn’t participate in the election activities,
and this doesn’t affect the node’s state. So, for example, if a node is not
a leader but it has election_mode = 'off'
, it is writable anyway.
You can control which nodes can become a leader. If you want a node
to participate in the election process but don’t want that it becomes
a leaders, set the election_mode
option to voter
. In this case,
the election works as usual, this particular node will vote for other nodes,
but won’t become a leader.
If the node should be able to become a leader, use election_mode = 'candidate'
.
Since version 2.8.2, the manual election mode is introduced.
It may be used when a user wants to control which instance is the leader explicitly instead of relying on
the Raft election algorithm.
When an instance is configured with the election_mode='manual'
, it behaves as follows:
- By default, the instance acts like a voter – it is read-only and may vote for other instances that are candidates.
- Once box.ctl.promote() is called, the instance becomes a candidate and starts a new election round.
If the instance wins the elections, it becomes a leader, but won’t participate in any new elections.
Тип: строка
Default: „off“
Environment variable: TT_ELECTION_MODE
Динамический: да
-
election_timeout
¶
Since version 2.6.1.
Specify the timeout between election rounds in the
leader election process if the previous round
ended up with a split-vote.
In the leader election process, there
can be an election timeout for the case of a split-vote.
The timeout can be configured using this option; the default value is
5 seconds.
It is quite big, and for most of the cases it can be freely lowered to
300-400 ms. It can be a floating point value (300 ms would be
box.cfg{election_timeout = 0.3}
).
To avoid the split vote repeat, the timeout is randomized on each node
during every new election, from 100% to 110% of the original timeout value.
For example, if the timeout is 300 ms and there are 3 nodes started
the election simultaneously in the same term,
they can set their election timeouts to 300, 310, and 320 respectively,
or to 305, 302, and 324, and so on. In that way, the votes will never be split
because the election on different nodes won’t be restarted simultaneously.
Тип: число
По умолчанию: 5
Environment variable: TT_ELECTION_TIMEOUT
Динамический: да
-
election_fencing_mode
¶
Since version 2.11.0.
In earlier Tarantool versions, use election_fencing_enabled instead.
Specify the leader fencing mode that
affects the leader election process. When the parameter is set to soft
or strict
, the leader resigns its leadership if it has less than
replication_synchro_quorum
of alive connections to the cluster nodes.
The resigning leader receives the status of a
follower in the current election term and becomes
read-only.
- In
soft
mode, a connection is considered dead if there are no responses for
4*replication_timeout seconds both on the current leader and the followers.
- In
strict
mode, a connection is considered dead if there are no responses
for 2*replication_timeout seconds on the
current leader and
4*replication_timeout seconds on the
followers. This improves chances that there is only one leader at any time.
Fencing applies to the instances that have the
election_mode set to candidate
or manual
.
To turn off leader fencing, set election_fencing_mode
to off
.
Тип: строка
Default: „soft“
Environment variable: TT_ELECTION_FENCING_MODE
Динамический: да
-
instance_name
¶
Since version 3.0.0.
Specify the instance name.
This value must be unique in a replica set.
The following rules are applied to instance names:
- The maximum number of symbols is 63.
- Should start with a letter.
- Can contain lowercase letters (a-z). If uppercase letters are used, they are converted to lowercase.
- Can contain digits (0-9).
- Can contain the following characters:
-
, _
.
To change or remove the specified name, you should temporarily set the box.cfg.force_recovery configuration option to true
.
When all the names are updated and all the instances synced, box.cfg.force_recovery
can be set back to false
.
Примечание
The instance name is persisted in the box.space._cluster system space.
See also: box.info.name
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_NAME
Динамический: нет
-
replicaset_name
¶
Since version 3.0.0.
Specify the name of a replica set to which this instance belongs.
This value must be the same for all instances of the replica set.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The replica set name is persisted in the box.space._schema system space.
See also: box.info.replicaset
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_NAME
Динамический: нет
-
cluster_name
¶
Since version 3.0.0.
Specify the name of a cluster to which this instance belongs.
This value must be the same for all instances of the cluster.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The cluster name is persisted in the box.space._schema system space.
See also: box.info.cluster
Тип: строка
По умолчанию: null
Environment variable: TT_CLUSTER_NAME
Динамический: нет
Работа с сетями
-
io_collect_interval
¶
Since version 1.4.9.
The instance will sleep for io_collect_interval seconds between iterations
of the event loop. Can be used to reduce CPU load in deployments in which
the number of client connections is large, but requests are not so frequent
(for example, each connection issues just a handful of requests per second).
Тип: число с плавающей запятой
По умолчанию: null
Environment variable: TT_IO_COLLECT_INTERVAL
Динамический: да
-
net_msg_max
¶
Since version 1.10.1.
To handle messages, Tarantool allocates fibers.
To prevent fiber overhead from affecting the whole system,
Tarantool restricts how many messages the fibers handle,
so that some pending requests are blocked.
В мощных системах увеличьте значение net_msg_max
, и планировщик немедленно приступит к обработке отложенных запросов.
В более слабых системах уменьшите значение net_msg_max
, чтобы снизить загрузку, хотя это и займет некоторое время, поскольку планировщик будет ожидать завершения уже запущенных запросов.
When net_msg_max
is reached,
Tarantool suspends processing of incoming packages until it
has processed earlier messages. This is not a direct restriction of
the number of fibers that handle network messages, rather it
is a system-wide restriction of channel bandwidth.
This in turn causes restriction of the number of incoming
network messages that the
transaction processor thread
handles, and therefore indirectly affects the fibers that handle
network messages.
(The number of fibers is smaller than the number of messages because
messages can be released as soon as they are delivered, while
incoming requests might not be processed until some time after delivery.)
Для стандартных систем подойдет значение, используемое по умолчанию (768).
Тип: целое число
По умолчанию: 768
Environment variable: TT_NET_MSG_MAX
Динамический: да
-
readahead
¶
Since version 1.6.2.
The size of the read-ahead buffer associated with a client connection. The
larger the buffer, the more memory an active connection consumes and the
more requests can be read from the operating system buffer in a single
system call. The rule of thumb is to make sure the buffer can contain at
least a few dozen requests. Therefore, if a typical tuple in a request is
large, e.g. a few kilobytes or even megabytes, the read-ahead buffer size
should be increased. If batched request processing is not used, it’s prudent
to leave this setting at its default.
Тип: целое число
По умолчанию: 16320
Environment variable: TT_READAHEAD
Динамический: да
-
iproto_threads
¶
Since version 2.8.1.
The number of network threads.
There can be unusual workloads where the network thread
is 100% loaded and the transaction processor thread is not, so the network
thread is a bottleneck. In that case set iproto_threads
to 2 or more.
The operating system kernel will determine which connection goes to
which thread.
On typical systems, the default value (1) is correct.
Тип: целое число
По умолчанию: 1
Environment variable: TT_IPROTO_THREADS
Динамический: нет
Запись в журнал
This section provides information on how to configure options related to logging.
You can also use the log module to configure logging in your
application.
-
log_level
¶
Since version 1.6.2.
Specify the level of detail the log has. There are the following levels:
- 0 –
fatal
- 1 –
syserror
- 2 –
error
- 3 –
crit
- 4 –
warn
- 5 –
info
- 6 –
verbose
- 7 –
debug
By setting log_level
, you can enable logging of all events with severities above
or equal to the given level. Tarantool prints logs to the standard
error stream by default. This can be changed with the
log configuration parameter.
Type: integer, string
По умолчанию: 5
Environment variable: TT_LOG_LEVEL
Динамический: да
Примечание
Prior to Tarantool 1.7.5 there were only six levels and DEBUG
was
level 6. Starting with Tarantool 1.7.5, VERBOSE
is level 6 and DEBUG
is level 7.
VERBOSE
is a new level for monitoring repetitive events which would cause
too much log writing if INFO
were used instead.
-
log
¶
Since version 1.7.4.
By default, Tarantool sends the log to the standard error stream
(stderr
). If log
is specified, Tarantool can send the log to a:
- file
- pipe
- system logger
Example 1: sending the log to the tarantool.log
file.
box.cfg{log = 'tarantool.log'}
-- или
box.cfg{log = 'file:tarantool.log'}
This opens the file tarantool.log
for output on the server’s default
directory. If the log
string has no prefix or has the prefix «file:»,
then the string is interpreted as a file path.
Example 2: sending the log to a pipe.
box.cfg{log = '| cronolog tarantool.log'}
-- or
box.cfg{log = 'pipe: cronolog tarantool.log'}
This starts the program cronolog when the server starts, and
sends all log messages to the standard input (stdin
) of cronolog
.
If the log
string begins with „|“ or has the prefix «pipe:»,
then the string is interpreted as a Unix
pipeline.
Example 3: sending the log to syslog.
box.cfg{log = 'syslog:identity=tarantool'}
-- или
box.cfg{log = 'syslog:facility=user'}
-- или
box.cfg{log = 'syslog:identity=tarantool,facility=user'}
-- или
box.cfg{log = 'syslog:server=unix:/dev/log'}
If the log
string begins with «syslog:», then it is
interpreted as a message for the
syslogd program, which normally
is running in the background on any Unix-like platform.
The setting can be syslog:
, syslog:facility=...
, syslog:identity=...
,
syslog:server=...
, or a combination.
- The
syslog:identity
setting is an arbitrary string, which is placed at
the beginning of all messages. The default value is «tarantool».
- В настоящий момент настройка
syslog:facility
не учитывается, но будет использоваться в дальнейшем. Ее значением должно быть одно из ключевых слов syslog, которые сообщают программе syslogd, куда отправлять сообщение. Возможные значения: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7. По умолчанию: user.
- The
syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path beginning with «unix:», or an ipv4 port number.
The default socket value is: dev/log
(on Linux) or /var/run/syslog
(on macOS).
The default port value is: 514, the UDP port.
When logging to a file, Tarantool reopens the log on SIGHUP.
When log is a program, its PID is saved in the log.pid
variable. You need to send it a signal to rotate logs.
Тип: строка
По умолчанию: null
Environment variable: TT_LOG
Динамический: нет
-
log_nonblock
¶
Since version 1.7.4.
If log_nonblock
equals true, Tarantool does not block during logging
when the system is not ready for writing, and drops the message
instead. If log_level is high, and many
messages go to the log, setting log_nonblock
to true may improve
logging performance at the cost of some log messages getting lost.
This parameter has effect only if log is
configured to send logs to a pipe or system logger.
The default log_nonblock
value is nil, which means that
blocking behavior corresponds to the logger type:
- false for
stderr
and file loggers.
- true for a pipe and system logger.
This is a behavior change: in earlier versions of the Tarantool
server, the default value was true.
Тип: логический
По умолчанию: nil
Environment variable: TT_LOG_NONBLOCK
Динамический: нет
-
too_long_threshold
¶
Since version 1.6.2.
If processing a request takes longer than the given value (in seconds),
warn about it in the log. Has effect only if log_level is greater than or equal to 4 (WARNING).
Тип: число с плавающей запятой
По умолчанию: 0.5
Environment variable: TT_TOO_LONG_THRESHOLD
Динамический: да
-
log_format
¶
Since version 1.7.6.
Log entries have two possible formats:
- „plain“ (по умолчанию) или
- „json“ (более детально с JSON-метками).
Here is what a log entry looks like if box.cfg{log_format='plain'}
:
2017-10-16 11:36:01.508 [18081] main/101/interactive I> set 'log_format' configuration option to "plain"
Here is what a log entry looks like if box.cfg{log_format='json'}
:
{"time": "2017-10-16T11:36:17.996-0600",
"level": "INFO",
"message": "set 'log_format' configuration option to \"json\"",
"pid": 18081,|
"cord_name": "main",
"fiber_id": 101,
"fiber_name": "interactive",
"file": "builtin\/box\/load_cfg.lua",
"line": 317}
The log_format='plain'
entry has a time value, process ID,
cord name, fiber_id,
fiber_name,
log level, and message.
The log_format='json'
entry has the same fields along with their labels,
and in addition has the file name and line number of the Tarantool source.
Тип: строка
По умолчанию: „plain“
Environment variable: TT_LOG_FORMAT
Динамический: да
-
log_modules
¶
Since version 2.11.0.
Configure the specified log levels (log_level) for different modules.
You can specify a logging level for the following module types:
- Modules (files) that use the default logger.
Example: Set log levels for files that use the default logger.
- Modules that use custom loggers created using the log.new() function.
Example: Set log levels for modules that use custom loggers.
- The
tarantool
module that enables you to configure the logging level for Tarantool core messages. Specifically, it configures the logging level for messages logged from non-Lua code, including C modules.
Example: Set a log level for C modules.
Type: table
Default: blank
Environment variable: TT_LOG_MODULES
Динамический: да
Example 1: Set log levels for files that use the default logger
Suppose you have two identical modules placed by the following paths: test/logging/module1.lua
and test/logging/module2.lua
.
These modules use the default logger and look as follows:
return {
say_hello = function()
local log = require('log')
log.info('Info message from module1')
end
}
To load these modules in your application, you need to add the corresponding require
directives:
module1 = require('test.logging.module1')
module2 = require('test.logging.module2')
To configure logging levels, you need to provide module names corresponding to paths to these modules.
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function:
box_cfg = { log_modules = {
['test.logging.module1'] = 'verbose',
['test.logging.module2'] = 'error' }
}
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1.say_hello()
shows a message but module2.say_hello()
is swallowed:
-- Prints 'info' messages --
module1.say_hello()
--[[
[92617] main/103/interactive/test.logging.module1 I> Info message from module1
---
...
--]]
-- Swallows 'info' messages --
module2.say_hello()
--[[
---
...
--]]
Example 2: Set log levels for modules that use custom loggers
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the verbose
level for module1
and the error
level for module2
:
box_cfg = { log_level = 'warn',
log_modules = {
module1 = 'verbose',
module2 = 'error' }
}
To create custom loggers, call the log.new() function:
-- Creates new loggers --
module1_log = require('log').new('module1')
module2_log = require('log').new('module2')
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1_log.info()
shows a message but module2_log.info()
is swallowed:
-- Prints 'info' messages --
module1_log.info('Info message from module1')
--[[
[16300] main/103/interactive/module1 I> Info message from module1
---
...
--]]
-- Swallows 'debug' messages --
module1_log.debug('Debug message from module1')
--[[
---
...
--]]
-- Swallows 'info' messages --
module2_log.info('Info message from module2')
--[[
---
...
--]]
Example 3: Set a log level for C modules
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the info
level for the tarantool
module:
box_cfg = { log_level = 'warn',
log_modules = { tarantool = 'info' } }
The specified level affects messages logged from C modules:
ffi = require('ffi')
-- Prints 'info' messages --
ffi.C._say(ffi.C.S_INFO, nil, 0, nil, 'Info message from C module')
--[[
[6024] main/103/interactive I> Info message from C module
---
...
--]]
-- Swallows 'debug' messages --
ffi.C._say(ffi.C.S_DEBUG, nil, 0, nil, 'Debug message from C module')
--[[
---
...
--]]
The example above uses the LuaJIT ffi library to call C functions provided by the say
module.
This example illustrates how «rotation» works, that is, what happens when the server
instance is writing to a log and signals are used when archiving it.
Start with two terminal shells: Terminal #1 and Terminal #2.
In Terminal #1, start an interactive Tarantool session.
Then, use the log
property to send logs to Log_file
and
call log.info
to put a message in the log file.
box.cfg{log='Log_file'}
log = require('log')
log.info('Log Line #1')
In Terminal #2, use the mv
command to rename the log file to Log_file.bak
.
mv Log_file Log_file.bak
As a result, the next log message will go to Log_file.bak
.
Go back to Terminal #1 and put a message «Log Line #2» in the log file.
log.info('Log Line #2')
In Terminal #2, use ps
to find the process ID of the Tarantool instance.
ps -A | grep tarantool
In Terminal #2, execute kill -HUP
to send a SIGHUP signal to the Tarantool instance.
Tarantool will open Log_file
again, and the next log message will go to Log_file
.
kill -HUP process_id
The same effect could be accomplished by calling log.rotate.
In Terminal #1, put a message «Log Line #3» in the log file.
log.info('Log Line #3')
In Terminal #2, use less
to examine files.
Log_file.bak
will have the following lines …
2015-11-30 15:13:06.373 [27469] main/101/interactive I> Log Line #1`
2015-11-30 15:14:25.973 [27469] main/101/interactive I> Log Line #2`
… and Log_file
will look like this:
log file has been reopened
2015-11-30 15:15:32.629 [27469] main/101/interactive I> Log Line #3
Audit log
Enterprise Edition
Audit log features are available in the Enterprise Edition only.
The audit_*
parameters define configuration related to audit logging.
-
audit_extract_key
¶
Since: 3.0.0.
If set to true
, the audit subsystem extracts and prints only the primary key instead of full
tuples in DML events (space_insert
, space_replace
, space_delete
).
Otherwise, full tuples are logged.
The option may be useful in case tuples are big.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_AUDIT_EXTRACT_KEY
-
audit_filter
¶
Enable logging for a specified subset of audit events.
This option accepts the following values:
- Event names (for example,
password_change
). For details, see Audit log events.
- Event groups (for example,
audit
). For details, see Event groups.
The option contains either one value from Possible values
section (see below) or a combination of them.
To enable custom audit log events, specify the custom
value in this option.
The default value is compatibility
, which enables logging of all events available before 2.10.0.
Example
box.cfg{
audit_log = 'audit.log',
audit_filter = 'audit,auth,priv,password_change,access_denied'
}
Type: array
Possible values: „all“, „audit“, „auth“, „priv“, „ddl“, „dml“, „data_operations“, „compatibility“,
„audit_enable“, „auth_ok“, „auth_fail“, „disconnect“, „user_create“, „user_drop“, „role_create“, „role_drop“,
„user_disable“, „user_enable“, „user_grant_rights“, „role_grant_rights“, „role_revoke_rights“, „password_change“,
„access_denied“, „eval“, „call“, „space_select“, „space_create“, „space_alter“, „space_drop“, „space_insert“,
„space_replace“, „space_delete“, „custom“
Default: „compatibility“
Environment variable: TT_AUDIT_FILTER
-
audit_format
¶
Specify the format that is used for the audit log events – plain text, CSV or JSON format.
Plain text is used by default. This human-readable format can be efficiently compressed.
box.cfg{audit_log = 'audit.log', audit_format = 'plain'}
Example
remote: session_type:background module:common.admin.auth user: type:custom_tdg_audit tag:tdg_severity_INFO description:[5e35b406-4274-4903-857b-c80115275940] subj: "anonymous", msg: "Access granted to anonymous user"
The JSON format is more convenient to receive log events, analyze them and integrate them with other systems if needed.
box.cfg{audit_log = 'audit.log', audit_format = 'json'}
Example
{"time": "2022-11-17T21:55:49.880+0300", "remote": "", "session_type": "background", "module": "common.admin.auth", "user": "", "type": "custom_tdg_audit", "tag": "tdg_severity_INFO", "description": "[c26cd11a-3342-4ce6-8f0b-a4b222268b9d] subj: \"anonymous\", msg: \"Access granted to anonymous user\""}
Using the CSV format allows you to view audit log events in tabular form.
box.cfg{audit_log = 'audit.log', audit_format = 'csv'}
Example
2022-11-17T21:58:03.131+0300,,background,common.admin.auth,,,custom_tdg_audit,tdg_severity_INFO,"[b3dfe2a3-ec29-4e61-b747-eb2332c83b2e] subj: ""anonymous"", msg: ""Access granted to anonymous user"""
Тип: строка
Possible values: „json“, „csv“, „plain“
Default: „json“
Environment variable: TT_AUDIT_FORMAT
-
audit_log
¶
Enable audit logging and define the log location.
This option accepts a string value that allows you to define the log location.
The following locations are supported:
- File: to write audit logs to a file, specify a path to a file (with an optional
file
prefix)
- Pipeline: to start a program and write audit logs to it, specify a program name (with
|
or pipe
prefix)
- System log: to write audit logs to a system log, specify a message for
syslogd
(with syslog
prefix)
See the examples below.
By default, audit logging is disabled.
Example: Writing to a file
box.cfg{audit_log = 'audit_tarantool.log'}
-- or
box.cfg{audit_log = 'file:audit_tarantool.log'}
This opens the audit_tarantool.log
file for output in the server’s default directory.
If the audit_log
string has no prefix or the prefix file:
, the string is interpreted as a file path.
If you log to a file, Tarantool will reopen the audit log at SIGHUP.
Example: Sending to a pipeline
box.cfg{audit_log = '| cronolog audit_tarantool.log'}
-- or
box.cfg{audit_log = 'pipe: cronolog audit_tarantool.log'}'
This starts the cronolog program when the server starts
and sends all audit_log
messages to cronolog’s standard input (stdin
).
If the audit_log
string starts with „|“ or contains the prefix pipe:
,
the string is interpreted as a Unix pipeline.
If log is a program, check out its pid and send it a signal to rotate logs.
Example: Writing to a system log
Предупреждение
Below is an example of writing audit logs to a directory shared with the system logs.
Tarantool allows this option, but it is not recommended to do this to avoid difficulties
when working with audit logs. System and audit logs should be written separately.
To do this, create separate paths and specify them.
This sample configuration sends the audit log to syslog:
box.cfg{audit_log = 'syslog:identity=tarantool'}
-- or
box.cfg{audit_log = 'syslog:facility=user'}
-- or
box.cfg{audit_log = 'syslog:identity=tarantool,facility=user'}
-- or
box.cfg{audit_log = 'syslog:server=unix:/dev/log'}
If the audit_log
string starts with «syslog:»,
it is interpreted as a message for the syslogd program,
which normally runs in the background of any Unix-like platform.
The setting can be „syslog:“, „syslog:facility=…“, „syslog:identity=…“, „syslog:server=…“ or a combination.
The syslog:identity
setting is an arbitrary string that is placed at the beginning of all messages.
The default value is tarantool
.
The syslog:facility
setting is currently ignored, but will be used in the future.
The value must be one of the syslog keywords
that tell syslogd
where to send the message.
The possible values are auth
, authpriv
, cron
, daemon
, ftp
,
kern
, lpr
, mail
, news
, security
, syslog
, user
, uucp
,
local0
, local1
, local2
, local3
, local4
, local5
, local6
, local7
.
The default value is local7
.
The syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path starting with «unix:» or an ipv4 port number.
The default socket value is /dev/log
(on Linux) or /var/run/syslog
(on Mac OS).
The default port value is 514, which is the UDP port.
An example of a Tarantool audit log entry in the syslog:
09:32:52 tarantool_audit: {"time": "2024-02-08T09:32:52.190+0300", "uuid": "94454e46-9a0e-493a-bb9f-d59e44a43581", "severity": "INFO", "remote": "unix/:(socket)", "session_type": "console", "module": "tarantool", "user": "admin", "type": "space_create", "tag": "", "description": "Create space bands"}
Тип: строка
Possible values: see the string format above
Default: „nill“
Environment variable: TT_AUDIT_LOG
-
audit_nonblock
¶
Specify the logging behavior if the system is not ready to write.
If set to true
, Tarantool does not block during logging if the system is non-writable and writes a message instead.
Using this value may improve logging performance at the cost of losing some log messages.
Примечание
The option only has an effect if the audit_log is set to syslog
or pipe
.
Setting audit_nonblock
to true
is not allowed if the output is to a file.
In this case, set audit_nonblock
to false
.
Тип: логический
По умолчанию: true
Environment variable: TT_AUDIT_NONBLOCK
-
audit_spaces
¶
Since: 3.0.0.
The array of space names for which data operation events (space_select
, space_insert
, space_replace
,
space_delete
) should be logged. The array accepts string values.
If set to box.NULL, the data operation events are logged for all spaces.
Example
In the example, only the events of bands
and singers
spaces are logged:
box.cfg{
audit_spaces = 'bands,singers'
}
Type: array
Default: box.NULL
Environment variable: TT_AUDIT_SPACES
Authentication
Enterprise Edition
Authentication features are supported by the Enterprise Edition only.
- auth_delay
- auth_retries
- auth_type
- disable_guest
- password_min_length
- password_enforce_uppercase
- password_enforce_lowercase
- password_enforce_digits
- password_enforce_specialchars
- password_lifetime_days
- password_history_length
-
auth_delay
¶
Since 2.11.0.
Specify a period of time (in seconds) that a specific user should wait
for the next attempt after failed authentication.
With the configuration below, Tarantool refuses the authentication attempt if the previous
attempt was less than 5 seconds ago.
box.cfg{ auth_delay = 5 }
Тип: число
Default: 0
Environment variable: TT_AUTH_DELAY
Динамический: да
-
auth_retries
¶
Since 3.0.0.
Specify the maximum number of authentication retries allowed before auth_delay
is enforced.
The default value is 0, which means auth_delay
is enforced after the first failed authentication attempt.
The retry counter is reset after auth_delay
seconds since the first failed attempt.
For example, if a client tries to authenticate fewer than auth_retries
times within auth_delay
seconds, no authentication delay is enforced.
The retry counter is also reset after any successful authentication attempt.
Тип: число
Default: 0
Environment variable: TT_AUTH_RETRIES
Динамический: да
-
auth_type
¶
Since 2.11.0.
Specify an authentication protocol:
- „chap-sha1“: use the CHAP protocol to authenticate users with
SHA-1
hashing applied to passwords.
- „pap-sha256“: use PAP authentication with the
SHA256
hashing algorithm.
For new users, the box.schema.user.create method
will generate authentication data using PAP-SHA256
.
For existing users, you need to reset a password using
box.schema.user.passwd
to use the new authentication protocol.
Тип: строка
Default value: „chap-sha1“
Environment variable: TT_AUTH_TYPE
Динамический: да
-
disable_guest
¶
Since 2.11.0.
If true, disables access over remote connections
from unauthenticated or guest access users.
This option affects both
net.box and
replication connections.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_DISABLE_GUEST
Динамический: да
-
password_min_length
¶
Since 2.11.0.
Specify the minimum number of characters for a password.
The following example shows how to set the minimum password length to 10.
box.cfg{ password_min_length = 10 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_MIN_LENGTH
Динамический: да
-
password_enforce_uppercase
¶
Since 2.11.0.
If true, a password should contain uppercase letters (A-Z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_UPPERCASE
Динамический: да
-
password_enforce_lowercase
¶
Since 2.11.0.
If true, a password should contain lowercase letters (a-z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_LOWERCASE
Динамический: да
-
password_enforce_digits
¶
Since 2.11.0.
If true, a password should contain digits (0-9).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_DIGITS
Динамический: да
-
password_enforce_specialchars
¶
Since 2.11.0.
If true, a password should contain at least one special character (such as &|?!@$
).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARS
Динамический: да
-
password_lifetime_days
¶
Since 2.11.0.
Specify the maximum period of time (in days) a user can use the same password.
When this period ends, a user gets the «Password expired» error on a login attempt.
To restore access for such users, use box.schema.user.passwd.
Примечание
The default 0 value means that a password never expires.
The example below shows how to set a maximum password age to 365 days.
box.cfg{ password_lifetime_days = 365 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_LIFETIME_DAYS
Динамический: да
-
password_history_length
¶
Since 2.11.0.
Specify the number of unique new user passwords before an old password can be reused.
In the example below, a new password should differ from the last three passwords.
box.cfg{ password_history_length = 3 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_HISTORY_LENGTH
Динамический: да
Примечание
Tarantool uses the auth_history
field in the
box.space._user
system space to store user passwords.
Flight recorder
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶
Since 2.11.0.
Enable the flight recorder.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FLIGHTREC_ENABLED
Динамический: да
-
flightrec_logs_size
¶
Since 2.11.0.
Specify the size (in bytes) of the log storage.
You can set this option to 0
to disable the log storage.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_LOGS_SIZE
Динамический: да
-
flightrec_logs_max_msg_size
¶
Since 2.11.0.
Specify the maximum size (in bytes) of the log message.
The log message is truncated if its size exceeds this limit.
Тип: целое число
Default: 4096
Maximum: 16384
Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZE
Динамический: да
-
flightrec_logs_log_level
¶
Since 2.11.0.
Specify the level of detail the log has.
You can learn more about log levels from the log_level
option description.
Note that the flightrec_logs_log_level
value might differ from log_level
.
Тип: целое число
Default: 6
Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVEL
Динамический: да
-
flightrec_metrics_period
¶
Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump.
So, this value defines how much historical metrics data is collected up to the moment of crash.
The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое число
Default: 180
Environment variable: TT_FLIGHTREC_METRICS_PERIOD
Динамический: да
-
flightrec_metrics_interval
¶
Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics.
This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB,
you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: число
По умолчанию: 1.0
Minimum: 0.001
Environment variable: TT_FLIGHTREC_METRICS_INTERVAL
Динамический: да
-
flightrec_requests_size
¶
Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data.
You can set this parameter to 0
to disable a storage of requests and responses.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_REQUESTS_SIZE
Динамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
- 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
-
memtx_memory
¶ 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 thememtx_memory
limit to allocate tuples, but there is additional memory used to store indexes and connection information.Тип: число с плавающей запятойПо умолчанию: 256 * 1024 * 1024 = 268435456 байтовMinimum: 33554432 bytes (32 MB)Environment variable: TT_MEMTX_MEMORYDynamic: yes but it cannot be decreased
-
memtx_max_tuple_size
¶ 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.
Тип: целое числоПо умолчанию: 1024 * 1024 = 1048576 байтовEnvironment variable: TT_MEMTX_MAX_TUPLE_SIZEДинамический: да
-
memtx_min_tuple_size
¶ Since version 1.7.4.
Size of the smallest allocation unit. It can be decreased if most of the tuples are very small.
Тип: целое числоПо умолчанию: 16 байтовPossible values: between 8 and 1048280 inclusiveEnvironment variable: TT_MEMTX_MIN_TUPLE_SIZEДинамический: нет
-
memtx_allocator
¶ 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 themalloc
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 tosystem
in such cases.
Тип: строкаDefault: „small“Environment variable: TT_MEMTX_ALLOCATORДинамический: нет
-
memtx_sort_threads
¶ 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.Примечание
Since 3.0.0, this option replaces the approach when OpenMP threads are used to parallelize sorting. For backward compatibility, the
OMP_NUM_THREADS
environment variable is taken into account to set the number of sorting threads.Тип: целое числоDefault: box.NULLEnvironment variable: TT_MEMTX_SORT_THREADSДинамический: нет
-
slab_alloc_factor
¶ 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
Тип: число с плавающей запятойDefault: 1.05Possible values: between 1 and 2 inclusiveEnvironment variable: TT_SLAB_ALLOC_FACTORДинамический: нет
-
slab_alloc_granularity
¶ 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
Тип: числоDefault: 8 bytesEnvironment variable: TT_SLAB_ALLOC_GRANULARITYДинамический: нет
-
vinyl_bloom_fpr
¶ 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.Тип: число с плавающей запятойПо умолчанию: 0.05Environment variable: TT_VINYL_BLOOM_FPRДинамический: нет
-
vinyl_cache
¶ Для версий от 1.7.4. и выше. Размер кэша для движка базы данных vinyl. Размер кэша можно изменить динамически.
Тип: целое числоПо умолчанию: 128 * 1024 * 1024 = 134217728 байтовEnvironment variable: TT_VINYL_CACHEДинамический: да
-
vinyl_max_tuple_size
¶ 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.
Тип: целое числоПо умолчанию: 1024 * 1024 = 1048576 байтовEnvironment variable: TT_VINYL_MAX_TUPLE_SIZEДинамический: нет
-
vinyl_memory
¶ Since version 1.7.4.
The maximum number of in-memory bytes that vinyl uses.
Тип: целое числоПо умолчанию: 128 * 1024 * 1024 = 134217728 байтовEnvironment variable: TT_VINYL_MEMORYDynamic: yes but it cannot be decreased
-
vinyl_page_size
¶ 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.Тип: целое числоПо умолчанию: 8 * 1024 = 8192 байтовEnvironment variable: TT_VINYL_PAGE_SIZEДинамический: нет
-
vinyl_range_size
¶ 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.
Если
vinyl_range_size
содержит не нулевое значение nil и не 0, это значение используется в качестве значения по умолчанию для параметраrange_size
в таблице Параметры space_object:create_index().Если
vinyl_range_size
содержит нулевое значение nil или 0, а параметрrange_size
не задан при создании индекса, то Tarantool сам задает это значение позднее в результате оценки производительности. Чтобы узнать текущее значение, используйте index_object:stat().range_size.До версии Tarantool 1.10.2 значение
vinyl_range_size
по умолчанию было 1073741824.Тип: целое числоПо умолчанию: nilEnvironment variable: TT_VINYL_RANGE_SIZEДинамический: нет
-
vinyl_run_count_per_level
¶ 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.Тип: целое числоПо умолчанию: 2Environment variable: TT_VINYL_RUN_COUNT_PER_LEVELДинамический: нет
-
vinyl_run_size_ratio
¶ 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.Тип: число с плавающей запятойПо умолчанию: 3.5Environment variable: TT_VINYL_RUN_SIZE_RATIOДинамический: нет
-
vinyl_read_threads
¶ 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.
Тип: целое числоПо умолчанию: 1Environment variable: TT_VINYL_READ_THREADSДинамический: нет
-
vinyl_write_threads
¶ 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.
Тип: целое числоПо умолчанию: 4Environment variable: TT_VINYL_WRITE_THREADSДинамический: нет
Демон создания контрольных точек
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
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.
Примечание
The garbage collector called by the checkpoint daemon is distinct from the Lua garbage collector
which is for Lua objects, and distinct from the Tarantool garbage collector that specializes in handling shard buckets.
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.
-
checkpoint_interval
¶
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.
Тип: целое число
По умолчанию: 3600 (один час)
Environment variable: TT_CHECKPOINT_INTERVAL
Динамический: да
-
checkpoint_count
¶
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.
Примечание
Snapshots will not be deleted if replication is ongoing and the file has not been relayed to a replica.
Therefore, checkpoint_count
has no effect unless all replicas are alive.
Тип: целое число
По умолчанию: 2
Environment variable: TT_CHECKPOINT_COUNT
Динамический: да
-
checkpoint_wal_threshold
¶
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.
Этот параметр позволяет администраторам справиться с проблемой, которая может возникнуть при вычислении объема дискового пространства для раздела, содержащего файлы WAL.
Тип: целое число
По умолчанию: 10^18 (большое число: можно считать, что предела нет)
Environment variable: TT_CHECKPOINT_WAL_THRESHOLD
Динамический: да
Записи в бинарный журнал и создание снимков
- 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
-
force_recovery
¶
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().
В остальных случаях Tarantool прерывает восстановление на ошибке чтения.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FORCE_RECOVERY
Динамический: нет
-
wal_max_size
¶
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.
Тип: целое число
По умолчанию: 268435456 (256 * 1024 * 1024) байтов
Environment variable: TT_WAL_MAX_SIZE
Динамический: нет
-
snap_io_rate_limit
¶
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.
Тип: число с плавающей запятой
По умолчанию: null
Environment variable: TT_SNAP_IO_RATE_LIMIT
Динамический: да
-
wal_mode
¶
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).
Тип: строка
По умолчанию: «write»
Environment variable: TT_WAL_MODE
Динамический: нет
-
wal_dir_rescan_delay
¶
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.
Тип: число с плавающей запятой
По умолчанию: 2
Environment variable: TT_WAL_DIR_RESCAN_DELAY
Динамический: нет
-
wal_queue_max_size
¶
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.
Примечание
You might consider increasing the wal_queue_max_size
value in case of
large tuples (approximately one megabyte or larger).
Тип: число
Default: 16777216 bytes
Environment variable: TT_WAL_QUEUE_MAX_SIZE
Динамический: да
-
wal_cleanup_delay
¶
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.
Примечание
The wal_cleanup_delay
option has no effect on nodes running as
anonymous replicas.
Тип: число
Default: 14400 seconds
Environment variable: TT_WAL_CLEANUP_DELAY
Динамический: да
-
wal_ext
¶
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
По умолчанию: nil
Environment variable: TT_WAL_EXT
Динамический: да
-
secure_erasing
¶
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.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_SECURE_ERASING
Динамический: да
Горячее резервирование
-
hot_standby
¶
Since version 1.7.4.
Whether to start the server in hot standby mode.
Горячее резервирование – это функция, которая обеспечивает простое восстановление после отказа без репликации.
Предполагается, что есть два экземпляра сервера, использующих одну и ту же конфигурацию. Первый из них станет «основным» экземпляром. Тот, который запускается вторым, станет «резервным» экземпляром.
Чтобы создать резервный экземпляр, запустите второй экземпляр Tarantool-сервера на том же компьютере с теми же настройками конфигурации box.cfg – включая одинаковые директории и ненулевые URI – и с дополнительной настройкой конфигурации hot_standby = true
. В ближайшее время вы увидите уведомление, которое заканчивается словами I> Entering hot standby mode
(вход в режим горячего резервирования). Всё в порядке – это означает, что резервный экземпляр готов взять работу на себя, если основной экземпляр прекратит работу.
Резервный экземпляр начнет инициализацию и попытается заблокировать wal_dir, но не сможет, поскольку директория wal_dir
заблокирована основным экземпляром. Поэтому резервный экземпляр входит в цикл, выполняя чтение журнала упреждающей записи, в который записывает данные основной экземпляр (поэтому два экземпляра всегда синхронизированы), и пытаясь произвести блокировку. Если основной экземпляр по какой-либо причине прекращает работу, блокировка снимается. В таком случае резервный экземпляр сможет заблокировать директорию на себя, подключится по адресу для прослушивания и станет основным экземпляром. В ближайшее время вы увидите уведомление, которое заканчивается словами I> ready to accept requests
(готов принимать запросы).
Таким образом, если основной экземпляр прекращает работу, время простоя отсутствует.
Функция горячего резервирования не работает:
- если wal_dir_rescan_delay = большое число (в Mac OS и FreeBSD); на этих платформах цикл запрограммирован на повторение каждые
wal_dir_rescan_delay
секунд.
- если wal_mode = „none“; будет работать только при
wal_mode = 'write'
или wal_mode = 'fsync'
.
- со спейсами, созданными на движке vinyl engine = „vinyl“; работает с движком memtx
engine = 'memtx'
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_HOT_STANDBY
Динамический: нет
Репликация
- 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
-
replication
¶
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
Если в наборе реплик более одного источника репликации, укажите массив URI, например (замените „uri“ и „uri2“ в данном примере на рабочие URI):
box.cfg{ replication = { 'uri1', 'uri2' } }
Примечание
Starting from version 2.10.0, there is a number of other ways for specifying several URIs. See syntax examples.
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.
По умолчанию, пользователем считается „guest“.
Реплика в режиме только для чтения не принимает запросы по изменению данных по порту для прослушивания.
Параметр replication
является динамическим, то есть для входа в режим мастера необходимо просто присвоить параметру replication
пустую строку и выполнить следующее:
box.cfg{ replication = новое-значение }
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICATION
Динамический: да
-
replication_anon
¶
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.
Так как анонимная реплика не зарегистрирована в таблице _cluster
, нет никаких ограничений для количества анонимных реплик в наборе: можно создавать их сколько угодно.
Чтобы сделать реплику анонимной, передайте опцию replication_anon=true
в box.cfg
и установите значение read_only
равным true
.
Попробуем создать анонимную реплику. Предположим, что у нас есть мастер с такой настройкой:
box.cfg{listen=3301}
и создан локальный спейс «loc»:
box.schema.space.create('loc', {is_local=true})
box.space.loc:create_index("pk")
Теперь, чтобы настроить анонимную реплику, нам нужно обратиться к box.cfg
, как обычно.
box.cfg{replication_anon=true, read_only=true, replication=3301}
Как было сказано выше, replication_anon
может быть true
только вместе с read_only
. Этот экземпляр получит снимок мастера и начнет следить за его изменениями. Он не получит id, поэтому его значение останется нулевым.
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
...
Теперь можно использовать реплику. Например, можно сделать вставку в локальный спейс:
tarantool> for i = 1,10 do
> box.space.loc:insert{i}
> end
---
...
Заметьте, что пока экземпляр анонимный, увеличится нулевая компонента его vclock
:
tarantool> box.info.vclock
---
- {0: 10, 1: 4}
...
А теперь давайте сделаем анонимную реплику снова обычной:
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-51a46def7661
2019-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> subscribed
2019-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
Эта реплика получила id равный 2. Мы можем снова сделать ее открытой на запись:
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: memtx
before_replace: 'function: 0x01109f9dc8'
on_replace: 'function: 0x01109f9d90'
ck_constraint: []
field_count: 0
temporary: false
index: []
is_local: false
enabled: false
name: test
id: 513
- created
...
tarantool> box.info.vclock
---
- {0: 10, 1: 5, 2: 2}
...
Теперь, как и ожидалось, реплика отслеживает свои изменения во 2-й компоненте vclock. С этого момента она также может стать мастером репликации.
Замечания:
- Нельзя реплицироваться от анонимной реплики.
- Чтобы вернуть анонимный экземпляр к обычному состоянию, сначала запустите его как анонимный, а потом вызовите
box.cfg{replication_anon=false}
- Чтобы деанонимизация прошла успешно, экземпляр должен быть скопирован с какого-то экземпляра, открытого на запись, иначе он не может быть добавлен в таблицу
_cluster
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_ANON
Динамический: да
-
bootstrap_leader
¶
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'},
}
Тип: строка
По умолчанию: null
Environment variable: TT_BOOTSTRAP_LEADER
Динамический: да
-
bootstrap_strategy
¶
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.
Тип: строка
Default: auto
Environment variable: TT_BOOTSTRAP_STRATEGY
Динамический: да
-
replication_connect_timeout
¶
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.
Тип: число с плавающей запятой
По умолчанию: 30
Environment variable: TT_REPLICATION_CONNECT_TIMEOUT
Динамический: да
-
replication_connect_quorum
¶
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.
Пример:
box.cfg { replication_connect_quorum = 2 }
Тип: целое число
По умолчанию: null
Environment variable: TT_REPLICATION_CONNECT_QUORUM
Динамический: да
-
replication_skip_conflict
¶
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.
Однако если указать replication_skip_conflict = true
, пользователи могут задать пропуск таких ошибок. Так, вместо сохранения сломанной транзакции в xlog, там будет записано NOP
(No operation).
Пример:
box.cfg{replication_skip_conflict=true}
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_SKIP_CONFLICT
Динамический: да
Примечание
replication_skip_conflict = true
рекомендуется использовать только для ручного восстановления репликации.
-
replication_sync_lag
¶
Since version 1.9.0.
The maximum lag allowed for a replica.
When a replica syncs
(gets updates from a master), it may not catch up completely.
The number of seconds that the replica is behind the master is called the «lag».
Syncing is considered to be complete when the replica’s lag is less than
or equal to replication_sync_lag
.
Если пользователь задает значение replication_sync_lag
, равное nil или 365 * 100 * 86400 (TIMEOUT_INFINITY), то отставание не имеет значения – реплика всегда будет синхронизирована. Кроме того, отставание не учитывается (считается бесконечным), если мастер работает на версии Tarantool старше 1.7.7, которая не отправляет сообщения контрольного сигнала.
Этот параметр не учитывается во время настройки. Для получения подробной информации, см. статус orphan.
Тип: число с плавающей запятой
По умолчанию: 10
Environment variable: TT_REPLICATION_SYNC_LAG
Динамический: да
-
replication_sync_timeout
¶
Since version 1.10.2.
The number of seconds that a node waits when trying to sync with
other nodes in a replica set (see bootstrap_strategy),
after connecting or during configuration update.
This could fail indefinitely if replication_sync_lag
is smaller
than network latency, or if the replica cannot keep pace with master
updates. If replication_sync_timeout
expires, the replica
enters orphan status.
Тип: число с плавающей запятой
По умолчанию: 300
Environment variable: TT_REPLICATION_SYNC_TIMEOUT
Динамический: да
Примечание
The default replication_sync_timeout
value is going to be changed in future versions from 300
to 0
.
You can learn the reasoning behind this decision from the Default value for replication_sync_timeout topic, which also describes how to try the new behavior in the current version.
-
replication_timeout
¶
Since version 1.7.5.
If the master has no updates to send to the replicas, it sends heartbeat messages
every replication_timeout
seconds, and each replica sends an ACK packet back.
И мастер, и реплики запрограммированы разорвать соединение при отсутствии сообщений в течение четырех промежутков времени, указанного в параметре replication_timeout
. После разрыва соединения реплика пытается снова подключиться к мастеру.
См. дополнительную информацию в разделе Мониторинг набора реплик.
Тип: целое число
По умолчанию: 1
Environment variable: TT_REPLICATION_TIMEOUT
Динамический: да
-
replicaset_uuid
¶
Since version 1.9.0.
As described in section
«Replication architecture»,
each replica set is identified by a
universally unique identifier
called replica set UUID, and each instance is identified by an
instance UUID.
Как правило, достаточно позволить системе сгенерировать и форматировать строки, содержащие UUID, которые будут храниться постоянно.
Однако, некоторые администраторы предпочитают сохранять конфигурацию Tarantool в центральном репозитории, например, Apache ZooKeeper. Они могут самостоятельно присвоить значения экземплярам (instance_uuid) и набору реплик (replicaset_uuid
) при первом запуске.
Общие правила:
- Значения должны быть действительно уникальными; они не должны одновременно принадлежать другим экземплярам или наборам реплик в той же инфраструктуре.
- Значения должны использоваться постоянно, неизменно с первого запуска (первоначальные значения хранятся в файлах снимков и проверяются при каждом перезапуске системы).
- Значения должны соответствовать требованиям RFC 4122. Нулевой UUID не допускается.
Формат UUID включает в себя шестнадцать октетов, представленных в виде 32 шестнадцатеричных чисел (с основанием 16) в пяти группах, разделенных дефисами в форме 8-4-4-4-12
– 36 символов (32 буквенно-цифровых символа и четыре дефиса).
Пример:
box.cfg{replicaset_uuid='7b853d13-508b-4b8e-82e6-806f088ea6e9'}
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_UUID
Динамический: нет
-
instance_uuid
¶
Since version 1.9.0.
For replication administration purposes, it is possible to set the
universally unique identifiers
of the instance (instance_uuid
) and the replica set
(replicaset_uuid
), instead of having the system generate the values.
Для получения подробной информации см. описание параметра replicaset_uuid.
Пример:
box.cfg{instance_uuid='037fec43-18a9-4e12-a684-a42b716fcd02'}
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_UUID
Динамический: нет
-
replication_synchro_quorum
¶
Since version 2.5.1.
For synchronous replication only.
This option tells how many replicas should confirm the receipt of a
synchronous transaction before it can finish its commit.
Since version 2.5.3,
the option supports dynamic evaluation of the quorum number.
That is, the number of quorum can be specified not as a constant number, but as a function instead.
In this case, the option returns the formula evaluated.
The result is treated as an integer number.
Once any replicas are added or removed, the expression is re-evaluated automatically.
For example,
box.cfg{replication_synchro_quorum = "N / 2 + 1"}
Where N
is a current number of registered replicas in a cluster.
Keep in mind that the example above represents a canonical quorum definition.
The formula at least 50% of the cluster size + 1
guarantees data reliability.
Using a value less than the canonical one might lead to unexpected results,
including a split-brain.
Since version 2.10.0, this option
does not account for anonymous replicas.
По умолчанию значение параметра равно N / 2 + 1
.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Если значение параметра равно 1
, синхронные транзакции работают как асинхронные, пока они не настроены. 1
означает, что для коммита достаточно успешной записи в WAL на мастере.
Тип: число
Default: N / 2 + 1 (before version 2.10.0, the default value was 1)
Environment variable: TT_REPLICATION_SYNCHRO_QUORUM
Динамический: да
-
replication_synchro_timeout
¶
Since version 2.5.1.
For synchronous replication only.
Tells how many seconds to wait for a synchronous transaction quorum
replication until it is declared failed and is rolled back.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Тип: число
По умолчанию: 5
Environment variable: TT_REPLICATION_SYNCHRO_TIMEOUT
Динамический: да
-
replication_threads
¶
Since version 2.10.0.
The number of threads spawned to decode the incoming replication data.
The default value is 1
.
It means that a single separate thread handles all the incoming replication streams.
In most cases, one thread is enough for all incoming data.
Therefore, it is likely that the user will not need to set this configuration option.
Possible values range from 1 to 1000.
If there are multiple replication threads, connections to serve are distributed evenly between the threads.
Тип: число
По умолчанию: 1
Possible values: from 1 to 1000
Environment variable: TT_REPLICATION_THREADS
Dynamic: no
-
election_mode
¶
Since version 2.6.1.
Specify the role of a replica set node in the
leader election process.
Possible values:
- off
- voter
- candidate
- manual.
Participation of a replica set node in the automated leader election can be
turned on and off by this option.
The default value is off
. All nodes that have values other than off
run the Raft state machine internally talking to other nodes according
to the Raft leader election protocol. When the option is off
, the node
accepts Raft messages
from other nodes, but it doesn’t participate in the election activities,
and this doesn’t affect the node’s state. So, for example, if a node is not
a leader but it has election_mode = 'off'
, it is writable anyway.
You can control which nodes can become a leader. If you want a node
to participate in the election process but don’t want that it becomes
a leaders, set the election_mode
option to voter
. In this case,
the election works as usual, this particular node will vote for other nodes,
but won’t become a leader.
If the node should be able to become a leader, use election_mode = 'candidate'
.
Since version 2.8.2, the manual election mode is introduced.
It may be used when a user wants to control which instance is the leader explicitly instead of relying on
the Raft election algorithm.
When an instance is configured with the election_mode='manual'
, it behaves as follows:
- By default, the instance acts like a voter – it is read-only and may vote for other instances that are candidates.
- Once box.ctl.promote() is called, the instance becomes a candidate and starts a new election round.
If the instance wins the elections, it becomes a leader, but won’t participate in any new elections.
Тип: строка
Default: „off“
Environment variable: TT_ELECTION_MODE
Динамический: да
-
election_timeout
¶
Since version 2.6.1.
Specify the timeout between election rounds in the
leader election process if the previous round
ended up with a split-vote.
In the leader election process, there
can be an election timeout for the case of a split-vote.
The timeout can be configured using this option; the default value is
5 seconds.
It is quite big, and for most of the cases it can be freely lowered to
300-400 ms. It can be a floating point value (300 ms would be
box.cfg{election_timeout = 0.3}
).
To avoid the split vote repeat, the timeout is randomized on each node
during every new election, from 100% to 110% of the original timeout value.
For example, if the timeout is 300 ms and there are 3 nodes started
the election simultaneously in the same term,
they can set their election timeouts to 300, 310, and 320 respectively,
or to 305, 302, and 324, and so on. In that way, the votes will never be split
because the election on different nodes won’t be restarted simultaneously.
Тип: число
По умолчанию: 5
Environment variable: TT_ELECTION_TIMEOUT
Динамический: да
-
election_fencing_mode
¶
Since version 2.11.0.
In earlier Tarantool versions, use election_fencing_enabled instead.
Specify the leader fencing mode that
affects the leader election process. When the parameter is set to soft
or strict
, the leader resigns its leadership if it has less than
replication_synchro_quorum
of alive connections to the cluster nodes.
The resigning leader receives the status of a
follower in the current election term and becomes
read-only.
- In
soft
mode, a connection is considered dead if there are no responses for
4*replication_timeout seconds both on the current leader and the followers.
- In
strict
mode, a connection is considered dead if there are no responses
for 2*replication_timeout seconds on the
current leader and
4*replication_timeout seconds on the
followers. This improves chances that there is only one leader at any time.
Fencing applies to the instances that have the
election_mode set to candidate
or manual
.
To turn off leader fencing, set election_fencing_mode
to off
.
Тип: строка
Default: „soft“
Environment variable: TT_ELECTION_FENCING_MODE
Динамический: да
-
instance_name
¶
Since version 3.0.0.
Specify the instance name.
This value must be unique in a replica set.
The following rules are applied to instance names:
- The maximum number of symbols is 63.
- Should start with a letter.
- Can contain lowercase letters (a-z). If uppercase letters are used, they are converted to lowercase.
- Can contain digits (0-9).
- Can contain the following characters:
-
, _
.
To change or remove the specified name, you should temporarily set the box.cfg.force_recovery configuration option to true
.
When all the names are updated and all the instances synced, box.cfg.force_recovery
can be set back to false
.
Примечание
The instance name is persisted in the box.space._cluster system space.
See also: box.info.name
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_NAME
Динамический: нет
-
replicaset_name
¶
Since version 3.0.0.
Specify the name of a replica set to which this instance belongs.
This value must be the same for all instances of the replica set.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The replica set name is persisted in the box.space._schema system space.
See also: box.info.replicaset
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_NAME
Динамический: нет
-
cluster_name
¶
Since version 3.0.0.
Specify the name of a cluster to which this instance belongs.
This value must be the same for all instances of the cluster.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The cluster name is persisted in the box.space._schema system space.
See also: box.info.cluster
Тип: строка
По умолчанию: null
Environment variable: TT_CLUSTER_NAME
Динамический: нет
Работа с сетями
-
io_collect_interval
¶
Since version 1.4.9.
The instance will sleep for io_collect_interval seconds between iterations
of the event loop. Can be used to reduce CPU load in deployments in which
the number of client connections is large, but requests are not so frequent
(for example, each connection issues just a handful of requests per second).
Тип: число с плавающей запятой
По умолчанию: null
Environment variable: TT_IO_COLLECT_INTERVAL
Динамический: да
-
net_msg_max
¶
Since version 1.10.1.
To handle messages, Tarantool allocates fibers.
To prevent fiber overhead from affecting the whole system,
Tarantool restricts how many messages the fibers handle,
so that some pending requests are blocked.
В мощных системах увеличьте значение net_msg_max
, и планировщик немедленно приступит к обработке отложенных запросов.
В более слабых системах уменьшите значение net_msg_max
, чтобы снизить загрузку, хотя это и займет некоторое время, поскольку планировщик будет ожидать завершения уже запущенных запросов.
When net_msg_max
is reached,
Tarantool suspends processing of incoming packages until it
has processed earlier messages. This is not a direct restriction of
the number of fibers that handle network messages, rather it
is a system-wide restriction of channel bandwidth.
This in turn causes restriction of the number of incoming
network messages that the
transaction processor thread
handles, and therefore indirectly affects the fibers that handle
network messages.
(The number of fibers is smaller than the number of messages because
messages can be released as soon as they are delivered, while
incoming requests might not be processed until some time after delivery.)
Для стандартных систем подойдет значение, используемое по умолчанию (768).
Тип: целое число
По умолчанию: 768
Environment variable: TT_NET_MSG_MAX
Динамический: да
-
readahead
¶
Since version 1.6.2.
The size of the read-ahead buffer associated with a client connection. The
larger the buffer, the more memory an active connection consumes and the
more requests can be read from the operating system buffer in a single
system call. The rule of thumb is to make sure the buffer can contain at
least a few dozen requests. Therefore, if a typical tuple in a request is
large, e.g. a few kilobytes or even megabytes, the read-ahead buffer size
should be increased. If batched request processing is not used, it’s prudent
to leave this setting at its default.
Тип: целое число
По умолчанию: 16320
Environment variable: TT_READAHEAD
Динамический: да
-
iproto_threads
¶
Since version 2.8.1.
The number of network threads.
There can be unusual workloads where the network thread
is 100% loaded and the transaction processor thread is not, so the network
thread is a bottleneck. In that case set iproto_threads
to 2 or more.
The operating system kernel will determine which connection goes to
which thread.
On typical systems, the default value (1) is correct.
Тип: целое число
По умолчанию: 1
Environment variable: TT_IPROTO_THREADS
Динамический: нет
Запись в журнал
This section provides information on how to configure options related to logging.
You can also use the log module to configure logging in your
application.
-
log_level
¶
Since version 1.6.2.
Specify the level of detail the log has. There are the following levels:
- 0 –
fatal
- 1 –
syserror
- 2 –
error
- 3 –
crit
- 4 –
warn
- 5 –
info
- 6 –
verbose
- 7 –
debug
By setting log_level
, you can enable logging of all events with severities above
or equal to the given level. Tarantool prints logs to the standard
error stream by default. This can be changed with the
log configuration parameter.
Type: integer, string
По умолчанию: 5
Environment variable: TT_LOG_LEVEL
Динамический: да
Примечание
Prior to Tarantool 1.7.5 there were only six levels and DEBUG
was
level 6. Starting with Tarantool 1.7.5, VERBOSE
is level 6 and DEBUG
is level 7.
VERBOSE
is a new level for monitoring repetitive events which would cause
too much log writing if INFO
were used instead.
-
log
¶
Since version 1.7.4.
By default, Tarantool sends the log to the standard error stream
(stderr
). If log
is specified, Tarantool can send the log to a:
- file
- pipe
- system logger
Example 1: sending the log to the tarantool.log
file.
box.cfg{log = 'tarantool.log'}
-- или
box.cfg{log = 'file:tarantool.log'}
This opens the file tarantool.log
for output on the server’s default
directory. If the log
string has no prefix or has the prefix «file:»,
then the string is interpreted as a file path.
Example 2: sending the log to a pipe.
box.cfg{log = '| cronolog tarantool.log'}
-- or
box.cfg{log = 'pipe: cronolog tarantool.log'}
This starts the program cronolog when the server starts, and
sends all log messages to the standard input (stdin
) of cronolog
.
If the log
string begins with „|“ or has the prefix «pipe:»,
then the string is interpreted as a Unix
pipeline.
Example 3: sending the log to syslog.
box.cfg{log = 'syslog:identity=tarantool'}
-- или
box.cfg{log = 'syslog:facility=user'}
-- или
box.cfg{log = 'syslog:identity=tarantool,facility=user'}
-- или
box.cfg{log = 'syslog:server=unix:/dev/log'}
If the log
string begins with «syslog:», then it is
interpreted as a message for the
syslogd program, which normally
is running in the background on any Unix-like platform.
The setting can be syslog:
, syslog:facility=...
, syslog:identity=...
,
syslog:server=...
, or a combination.
- The
syslog:identity
setting is an arbitrary string, which is placed at
the beginning of all messages. The default value is «tarantool».
- В настоящий момент настройка
syslog:facility
не учитывается, но будет использоваться в дальнейшем. Ее значением должно быть одно из ключевых слов syslog, которые сообщают программе syslogd, куда отправлять сообщение. Возможные значения: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7. По умолчанию: user.
- The
syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path beginning with «unix:», or an ipv4 port number.
The default socket value is: dev/log
(on Linux) or /var/run/syslog
(on macOS).
The default port value is: 514, the UDP port.
When logging to a file, Tarantool reopens the log on SIGHUP.
When log is a program, its PID is saved in the log.pid
variable. You need to send it a signal to rotate logs.
Тип: строка
По умолчанию: null
Environment variable: TT_LOG
Динамический: нет
-
log_nonblock
¶
Since version 1.7.4.
If log_nonblock
equals true, Tarantool does not block during logging
when the system is not ready for writing, and drops the message
instead. If log_level is high, and many
messages go to the log, setting log_nonblock
to true may improve
logging performance at the cost of some log messages getting lost.
This parameter has effect only if log is
configured to send logs to a pipe or system logger.
The default log_nonblock
value is nil, which means that
blocking behavior corresponds to the logger type:
- false for
stderr
and file loggers.
- true for a pipe and system logger.
This is a behavior change: in earlier versions of the Tarantool
server, the default value was true.
Тип: логический
По умолчанию: nil
Environment variable: TT_LOG_NONBLOCK
Динамический: нет
-
too_long_threshold
¶
Since version 1.6.2.
If processing a request takes longer than the given value (in seconds),
warn about it in the log. Has effect only if log_level is greater than or equal to 4 (WARNING).
Тип: число с плавающей запятой
По умолчанию: 0.5
Environment variable: TT_TOO_LONG_THRESHOLD
Динамический: да
-
log_format
¶
Since version 1.7.6.
Log entries have two possible formats:
- „plain“ (по умолчанию) или
- „json“ (более детально с JSON-метками).
Here is what a log entry looks like if box.cfg{log_format='plain'}
:
2017-10-16 11:36:01.508 [18081] main/101/interactive I> set 'log_format' configuration option to "plain"
Here is what a log entry looks like if box.cfg{log_format='json'}
:
{"time": "2017-10-16T11:36:17.996-0600",
"level": "INFO",
"message": "set 'log_format' configuration option to \"json\"",
"pid": 18081,|
"cord_name": "main",
"fiber_id": 101,
"fiber_name": "interactive",
"file": "builtin\/box\/load_cfg.lua",
"line": 317}
The log_format='plain'
entry has a time value, process ID,
cord name, fiber_id,
fiber_name,
log level, and message.
The log_format='json'
entry has the same fields along with their labels,
and in addition has the file name and line number of the Tarantool source.
Тип: строка
По умолчанию: „plain“
Environment variable: TT_LOG_FORMAT
Динамический: да
-
log_modules
¶
Since version 2.11.0.
Configure the specified log levels (log_level) for different modules.
You can specify a logging level for the following module types:
- Modules (files) that use the default logger.
Example: Set log levels for files that use the default logger.
- Modules that use custom loggers created using the log.new() function.
Example: Set log levels for modules that use custom loggers.
- The
tarantool
module that enables you to configure the logging level for Tarantool core messages. Specifically, it configures the logging level for messages logged from non-Lua code, including C modules.
Example: Set a log level for C modules.
Type: table
Default: blank
Environment variable: TT_LOG_MODULES
Динамический: да
Example 1: Set log levels for files that use the default logger
Suppose you have two identical modules placed by the following paths: test/logging/module1.lua
and test/logging/module2.lua
.
These modules use the default logger and look as follows:
return {
say_hello = function()
local log = require('log')
log.info('Info message from module1')
end
}
To load these modules in your application, you need to add the corresponding require
directives:
module1 = require('test.logging.module1')
module2 = require('test.logging.module2')
To configure logging levels, you need to provide module names corresponding to paths to these modules.
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function:
box_cfg = { log_modules = {
['test.logging.module1'] = 'verbose',
['test.logging.module2'] = 'error' }
}
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1.say_hello()
shows a message but module2.say_hello()
is swallowed:
-- Prints 'info' messages --
module1.say_hello()
--[[
[92617] main/103/interactive/test.logging.module1 I> Info message from module1
---
...
--]]
-- Swallows 'info' messages --
module2.say_hello()
--[[
---
...
--]]
Example 2: Set log levels for modules that use custom loggers
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the verbose
level for module1
and the error
level for module2
:
box_cfg = { log_level = 'warn',
log_modules = {
module1 = 'verbose',
module2 = 'error' }
}
To create custom loggers, call the log.new() function:
-- Creates new loggers --
module1_log = require('log').new('module1')
module2_log = require('log').new('module2')
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1_log.info()
shows a message but module2_log.info()
is swallowed:
-- Prints 'info' messages --
module1_log.info('Info message from module1')
--[[
[16300] main/103/interactive/module1 I> Info message from module1
---
...
--]]
-- Swallows 'debug' messages --
module1_log.debug('Debug message from module1')
--[[
---
...
--]]
-- Swallows 'info' messages --
module2_log.info('Info message from module2')
--[[
---
...
--]]
Example 3: Set a log level for C modules
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the info
level for the tarantool
module:
box_cfg = { log_level = 'warn',
log_modules = { tarantool = 'info' } }
The specified level affects messages logged from C modules:
ffi = require('ffi')
-- Prints 'info' messages --
ffi.C._say(ffi.C.S_INFO, nil, 0, nil, 'Info message from C module')
--[[
[6024] main/103/interactive I> Info message from C module
---
...
--]]
-- Swallows 'debug' messages --
ffi.C._say(ffi.C.S_DEBUG, nil, 0, nil, 'Debug message from C module')
--[[
---
...
--]]
The example above uses the LuaJIT ffi library to call C functions provided by the say
module.
This example illustrates how «rotation» works, that is, what happens when the server
instance is writing to a log and signals are used when archiving it.
Start with two terminal shells: Terminal #1 and Terminal #2.
In Terminal #1, start an interactive Tarantool session.
Then, use the log
property to send logs to Log_file
and
call log.info
to put a message in the log file.
box.cfg{log='Log_file'}
log = require('log')
log.info('Log Line #1')
In Terminal #2, use the mv
command to rename the log file to Log_file.bak
.
mv Log_file Log_file.bak
As a result, the next log message will go to Log_file.bak
.
Go back to Terminal #1 and put a message «Log Line #2» in the log file.
log.info('Log Line #2')
In Terminal #2, use ps
to find the process ID of the Tarantool instance.
ps -A | grep tarantool
In Terminal #2, execute kill -HUP
to send a SIGHUP signal to the Tarantool instance.
Tarantool will open Log_file
again, and the next log message will go to Log_file
.
kill -HUP process_id
The same effect could be accomplished by calling log.rotate.
In Terminal #1, put a message «Log Line #3» in the log file.
log.info('Log Line #3')
In Terminal #2, use less
to examine files.
Log_file.bak
will have the following lines …
2015-11-30 15:13:06.373 [27469] main/101/interactive I> Log Line #1`
2015-11-30 15:14:25.973 [27469] main/101/interactive I> Log Line #2`
… and Log_file
will look like this:
log file has been reopened
2015-11-30 15:15:32.629 [27469] main/101/interactive I> Log Line #3
Audit log
Enterprise Edition
Audit log features are available in the Enterprise Edition only.
The audit_*
parameters define configuration related to audit logging.
-
audit_extract_key
¶
Since: 3.0.0.
If set to true
, the audit subsystem extracts and prints only the primary key instead of full
tuples in DML events (space_insert
, space_replace
, space_delete
).
Otherwise, full tuples are logged.
The option may be useful in case tuples are big.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_AUDIT_EXTRACT_KEY
-
audit_filter
¶
Enable logging for a specified subset of audit events.
This option accepts the following values:
- Event names (for example,
password_change
). For details, see Audit log events.
- Event groups (for example,
audit
). For details, see Event groups.
The option contains either one value from Possible values
section (see below) or a combination of them.
To enable custom audit log events, specify the custom
value in this option.
The default value is compatibility
, which enables logging of all events available before 2.10.0.
Example
box.cfg{
audit_log = 'audit.log',
audit_filter = 'audit,auth,priv,password_change,access_denied'
}
Type: array
Possible values: „all“, „audit“, „auth“, „priv“, „ddl“, „dml“, „data_operations“, „compatibility“,
„audit_enable“, „auth_ok“, „auth_fail“, „disconnect“, „user_create“, „user_drop“, „role_create“, „role_drop“,
„user_disable“, „user_enable“, „user_grant_rights“, „role_grant_rights“, „role_revoke_rights“, „password_change“,
„access_denied“, „eval“, „call“, „space_select“, „space_create“, „space_alter“, „space_drop“, „space_insert“,
„space_replace“, „space_delete“, „custom“
Default: „compatibility“
Environment variable: TT_AUDIT_FILTER
-
audit_format
¶
Specify the format that is used for the audit log events – plain text, CSV or JSON format.
Plain text is used by default. This human-readable format can be efficiently compressed.
box.cfg{audit_log = 'audit.log', audit_format = 'plain'}
Example
remote: session_type:background module:common.admin.auth user: type:custom_tdg_audit tag:tdg_severity_INFO description:[5e35b406-4274-4903-857b-c80115275940] subj: "anonymous", msg: "Access granted to anonymous user"
The JSON format is more convenient to receive log events, analyze them and integrate them with other systems if needed.
box.cfg{audit_log = 'audit.log', audit_format = 'json'}
Example
{"time": "2022-11-17T21:55:49.880+0300", "remote": "", "session_type": "background", "module": "common.admin.auth", "user": "", "type": "custom_tdg_audit", "tag": "tdg_severity_INFO", "description": "[c26cd11a-3342-4ce6-8f0b-a4b222268b9d] subj: \"anonymous\", msg: \"Access granted to anonymous user\""}
Using the CSV format allows you to view audit log events in tabular form.
box.cfg{audit_log = 'audit.log', audit_format = 'csv'}
Example
2022-11-17T21:58:03.131+0300,,background,common.admin.auth,,,custom_tdg_audit,tdg_severity_INFO,"[b3dfe2a3-ec29-4e61-b747-eb2332c83b2e] subj: ""anonymous"", msg: ""Access granted to anonymous user"""
Тип: строка
Possible values: „json“, „csv“, „plain“
Default: „json“
Environment variable: TT_AUDIT_FORMAT
-
audit_log
¶
Enable audit logging and define the log location.
This option accepts a string value that allows you to define the log location.
The following locations are supported:
- File: to write audit logs to a file, specify a path to a file (with an optional
file
prefix)
- Pipeline: to start a program and write audit logs to it, specify a program name (with
|
or pipe
prefix)
- System log: to write audit logs to a system log, specify a message for
syslogd
(with syslog
prefix)
See the examples below.
By default, audit logging is disabled.
Example: Writing to a file
box.cfg{audit_log = 'audit_tarantool.log'}
-- or
box.cfg{audit_log = 'file:audit_tarantool.log'}
This opens the audit_tarantool.log
file for output in the server’s default directory.
If the audit_log
string has no prefix or the prefix file:
, the string is interpreted as a file path.
If you log to a file, Tarantool will reopen the audit log at SIGHUP.
Example: Sending to a pipeline
box.cfg{audit_log = '| cronolog audit_tarantool.log'}
-- or
box.cfg{audit_log = 'pipe: cronolog audit_tarantool.log'}'
This starts the cronolog program when the server starts
and sends all audit_log
messages to cronolog’s standard input (stdin
).
If the audit_log
string starts with „|“ or contains the prefix pipe:
,
the string is interpreted as a Unix pipeline.
If log is a program, check out its pid and send it a signal to rotate logs.
Example: Writing to a system log
Предупреждение
Below is an example of writing audit logs to a directory shared with the system logs.
Tarantool allows this option, but it is not recommended to do this to avoid difficulties
when working with audit logs. System and audit logs should be written separately.
To do this, create separate paths and specify them.
This sample configuration sends the audit log to syslog:
box.cfg{audit_log = 'syslog:identity=tarantool'}
-- or
box.cfg{audit_log = 'syslog:facility=user'}
-- or
box.cfg{audit_log = 'syslog:identity=tarantool,facility=user'}
-- or
box.cfg{audit_log = 'syslog:server=unix:/dev/log'}
If the audit_log
string starts with «syslog:»,
it is interpreted as a message for the syslogd program,
which normally runs in the background of any Unix-like platform.
The setting can be „syslog:“, „syslog:facility=…“, „syslog:identity=…“, „syslog:server=…“ or a combination.
The syslog:identity
setting is an arbitrary string that is placed at the beginning of all messages.
The default value is tarantool
.
The syslog:facility
setting is currently ignored, but will be used in the future.
The value must be one of the syslog keywords
that tell syslogd
where to send the message.
The possible values are auth
, authpriv
, cron
, daemon
, ftp
,
kern
, lpr
, mail
, news
, security
, syslog
, user
, uucp
,
local0
, local1
, local2
, local3
, local4
, local5
, local6
, local7
.
The default value is local7
.
The syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path starting with «unix:» or an ipv4 port number.
The default socket value is /dev/log
(on Linux) or /var/run/syslog
(on Mac OS).
The default port value is 514, which is the UDP port.
An example of a Tarantool audit log entry in the syslog:
09:32:52 tarantool_audit: {"time": "2024-02-08T09:32:52.190+0300", "uuid": "94454e46-9a0e-493a-bb9f-d59e44a43581", "severity": "INFO", "remote": "unix/:(socket)", "session_type": "console", "module": "tarantool", "user": "admin", "type": "space_create", "tag": "", "description": "Create space bands"}
Тип: строка
Possible values: see the string format above
Default: „nill“
Environment variable: TT_AUDIT_LOG
-
audit_nonblock
¶
Specify the logging behavior if the system is not ready to write.
If set to true
, Tarantool does not block during logging if the system is non-writable and writes a message instead.
Using this value may improve logging performance at the cost of losing some log messages.
Примечание
The option only has an effect if the audit_log is set to syslog
or pipe
.
Setting audit_nonblock
to true
is not allowed if the output is to a file.
In this case, set audit_nonblock
to false
.
Тип: логический
По умолчанию: true
Environment variable: TT_AUDIT_NONBLOCK
-
audit_spaces
¶
Since: 3.0.0.
The array of space names for which data operation events (space_select
, space_insert
, space_replace
,
space_delete
) should be logged. The array accepts string values.
If set to box.NULL, the data operation events are logged for all spaces.
Example
In the example, only the events of bands
and singers
spaces are logged:
box.cfg{
audit_spaces = 'bands,singers'
}
Type: array
Default: box.NULL
Environment variable: TT_AUDIT_SPACES
Authentication
Enterprise Edition
Authentication features are supported by the Enterprise Edition only.
- auth_delay
- auth_retries
- auth_type
- disable_guest
- password_min_length
- password_enforce_uppercase
- password_enforce_lowercase
- password_enforce_digits
- password_enforce_specialchars
- password_lifetime_days
- password_history_length
-
auth_delay
¶
Since 2.11.0.
Specify a period of time (in seconds) that a specific user should wait
for the next attempt after failed authentication.
With the configuration below, Tarantool refuses the authentication attempt if the previous
attempt was less than 5 seconds ago.
box.cfg{ auth_delay = 5 }
Тип: число
Default: 0
Environment variable: TT_AUTH_DELAY
Динамический: да
-
auth_retries
¶
Since 3.0.0.
Specify the maximum number of authentication retries allowed before auth_delay
is enforced.
The default value is 0, which means auth_delay
is enforced after the first failed authentication attempt.
The retry counter is reset after auth_delay
seconds since the first failed attempt.
For example, if a client tries to authenticate fewer than auth_retries
times within auth_delay
seconds, no authentication delay is enforced.
The retry counter is also reset after any successful authentication attempt.
Тип: число
Default: 0
Environment variable: TT_AUTH_RETRIES
Динамический: да
-
auth_type
¶
Since 2.11.0.
Specify an authentication protocol:
- „chap-sha1“: use the CHAP protocol to authenticate users with
SHA-1
hashing applied to passwords.
- „pap-sha256“: use PAP authentication with the
SHA256
hashing algorithm.
For new users, the box.schema.user.create method
will generate authentication data using PAP-SHA256
.
For existing users, you need to reset a password using
box.schema.user.passwd
to use the new authentication protocol.
Тип: строка
Default value: „chap-sha1“
Environment variable: TT_AUTH_TYPE
Динамический: да
-
disable_guest
¶
Since 2.11.0.
If true, disables access over remote connections
from unauthenticated or guest access users.
This option affects both
net.box and
replication connections.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_DISABLE_GUEST
Динамический: да
-
password_min_length
¶
Since 2.11.0.
Specify the minimum number of characters for a password.
The following example shows how to set the minimum password length to 10.
box.cfg{ password_min_length = 10 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_MIN_LENGTH
Динамический: да
-
password_enforce_uppercase
¶
Since 2.11.0.
If true, a password should contain uppercase letters (A-Z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_UPPERCASE
Динамический: да
-
password_enforce_lowercase
¶
Since 2.11.0.
If true, a password should contain lowercase letters (a-z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_LOWERCASE
Динамический: да
-
password_enforce_digits
¶
Since 2.11.0.
If true, a password should contain digits (0-9).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_DIGITS
Динамический: да
-
password_enforce_specialchars
¶
Since 2.11.0.
If true, a password should contain at least one special character (such as &|?!@$
).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARS
Динамический: да
-
password_lifetime_days
¶
Since 2.11.0.
Specify the maximum period of time (in days) a user can use the same password.
When this period ends, a user gets the «Password expired» error on a login attempt.
To restore access for such users, use box.schema.user.passwd.
Примечание
The default 0 value means that a password never expires.
The example below shows how to set a maximum password age to 365 days.
box.cfg{ password_lifetime_days = 365 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_LIFETIME_DAYS
Динамический: да
-
password_history_length
¶
Since 2.11.0.
Specify the number of unique new user passwords before an old password can be reused.
In the example below, a new password should differ from the last three passwords.
box.cfg{ password_history_length = 3 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_HISTORY_LENGTH
Динамический: да
Примечание
Tarantool uses the auth_history
field in the
box.space._user
system space to store user passwords.
Flight recorder
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶
Since 2.11.0.
Enable the flight recorder.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FLIGHTREC_ENABLED
Динамический: да
-
flightrec_logs_size
¶
Since 2.11.0.
Specify the size (in bytes) of the log storage.
You can set this option to 0
to disable the log storage.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_LOGS_SIZE
Динамический: да
-
flightrec_logs_max_msg_size
¶
Since 2.11.0.
Specify the maximum size (in bytes) of the log message.
The log message is truncated if its size exceeds this limit.
Тип: целое число
Default: 4096
Maximum: 16384
Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZE
Динамический: да
-
flightrec_logs_log_level
¶
Since 2.11.0.
Specify the level of detail the log has.
You can learn more about log levels from the log_level
option description.
Note that the flightrec_logs_log_level
value might differ from log_level
.
Тип: целое число
Default: 6
Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVEL
Динамический: да
-
flightrec_metrics_period
¶
Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump.
So, this value defines how much historical metrics data is collected up to the moment of crash.
The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое число
Default: 180
Environment variable: TT_FLIGHTREC_METRICS_PERIOD
Динамический: да
-
flightrec_metrics_interval
¶
Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics.
This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB,
you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: число
По умолчанию: 1.0
Minimum: 0.001
Environment variable: TT_FLIGHTREC_METRICS_INTERVAL
Динамический: да
-
flightrec_requests_size
¶
Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data.
You can set this parameter to 0
to disable a storage of requests and responses.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_REQUESTS_SIZE
Динамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
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
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.
Примечание
The garbage collector called by the checkpoint daemon is distinct from the Lua garbage collector which is for Lua objects, and distinct from the Tarantool garbage collector that specializes in handling shard buckets.
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.
-
checkpoint_interval
¶ 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.
Тип: целое числоПо умолчанию: 3600 (один час)Environment variable: TT_CHECKPOINT_INTERVALДинамический: да
-
checkpoint_count
¶ 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.
Примечание
Snapshots will not be deleted if replication is ongoing and the file has not been relayed to a replica. Therefore,
checkpoint_count
has no effect unless all replicas are alive.Тип: целое числоПо умолчанию: 2Environment variable: TT_CHECKPOINT_COUNTДинамический: да
-
checkpoint_wal_threshold
¶ 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.
Этот параметр позволяет администраторам справиться с проблемой, которая может возникнуть при вычислении объема дискового пространства для раздела, содержащего файлы WAL.
Тип: целое числоПо умолчанию: 10^18 (большое число: можно считать, что предела нет)Environment variable: TT_CHECKPOINT_WAL_THRESHOLDДинамический: да
Записи в бинарный журнал и создание снимков
- 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
-
force_recovery
¶
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().
В остальных случаях Tarantool прерывает восстановление на ошибке чтения.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FORCE_RECOVERY
Динамический: нет
-
wal_max_size
¶
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.
Тип: целое число
По умолчанию: 268435456 (256 * 1024 * 1024) байтов
Environment variable: TT_WAL_MAX_SIZE
Динамический: нет
-
snap_io_rate_limit
¶
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.
Тип: число с плавающей запятой
По умолчанию: null
Environment variable: TT_SNAP_IO_RATE_LIMIT
Динамический: да
-
wal_mode
¶
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).
Тип: строка
По умолчанию: «write»
Environment variable: TT_WAL_MODE
Динамический: нет
-
wal_dir_rescan_delay
¶
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.
Тип: число с плавающей запятой
По умолчанию: 2
Environment variable: TT_WAL_DIR_RESCAN_DELAY
Динамический: нет
-
wal_queue_max_size
¶
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.
Примечание
You might consider increasing the wal_queue_max_size
value in case of
large tuples (approximately one megabyte or larger).
Тип: число
Default: 16777216 bytes
Environment variable: TT_WAL_QUEUE_MAX_SIZE
Динамический: да
-
wal_cleanup_delay
¶
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.
Примечание
The wal_cleanup_delay
option has no effect on nodes running as
anonymous replicas.
Тип: число
Default: 14400 seconds
Environment variable: TT_WAL_CLEANUP_DELAY
Динамический: да
-
wal_ext
¶
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
По умолчанию: nil
Environment variable: TT_WAL_EXT
Динамический: да
-
secure_erasing
¶
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.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_SECURE_ERASING
Динамический: да
Горячее резервирование
-
hot_standby
¶
Since version 1.7.4.
Whether to start the server in hot standby mode.
Горячее резервирование – это функция, которая обеспечивает простое восстановление после отказа без репликации.
Предполагается, что есть два экземпляра сервера, использующих одну и ту же конфигурацию. Первый из них станет «основным» экземпляром. Тот, который запускается вторым, станет «резервным» экземпляром.
Чтобы создать резервный экземпляр, запустите второй экземпляр Tarantool-сервера на том же компьютере с теми же настройками конфигурации box.cfg – включая одинаковые директории и ненулевые URI – и с дополнительной настройкой конфигурации hot_standby = true
. В ближайшее время вы увидите уведомление, которое заканчивается словами I> Entering hot standby mode
(вход в режим горячего резервирования). Всё в порядке – это означает, что резервный экземпляр готов взять работу на себя, если основной экземпляр прекратит работу.
Резервный экземпляр начнет инициализацию и попытается заблокировать wal_dir, но не сможет, поскольку директория wal_dir
заблокирована основным экземпляром. Поэтому резервный экземпляр входит в цикл, выполняя чтение журнала упреждающей записи, в который записывает данные основной экземпляр (поэтому два экземпляра всегда синхронизированы), и пытаясь произвести блокировку. Если основной экземпляр по какой-либо причине прекращает работу, блокировка снимается. В таком случае резервный экземпляр сможет заблокировать директорию на себя, подключится по адресу для прослушивания и станет основным экземпляром. В ближайшее время вы увидите уведомление, которое заканчивается словами I> ready to accept requests
(готов принимать запросы).
Таким образом, если основной экземпляр прекращает работу, время простоя отсутствует.
Функция горячего резервирования не работает:
- если wal_dir_rescan_delay = большое число (в Mac OS и FreeBSD); на этих платформах цикл запрограммирован на повторение каждые
wal_dir_rescan_delay
секунд.
- если wal_mode = „none“; будет работать только при
wal_mode = 'write'
или wal_mode = 'fsync'
.
- со спейсами, созданными на движке vinyl engine = „vinyl“; работает с движком memtx
engine = 'memtx'
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_HOT_STANDBY
Динамический: нет
Репликация
- 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
-
replication
¶
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
Если в наборе реплик более одного источника репликации, укажите массив URI, например (замените „uri“ и „uri2“ в данном примере на рабочие URI):
box.cfg{ replication = { 'uri1', 'uri2' } }
Примечание
Starting from version 2.10.0, there is a number of other ways for specifying several URIs. See syntax examples.
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.
По умолчанию, пользователем считается „guest“.
Реплика в режиме только для чтения не принимает запросы по изменению данных по порту для прослушивания.
Параметр replication
является динамическим, то есть для входа в режим мастера необходимо просто присвоить параметру replication
пустую строку и выполнить следующее:
box.cfg{ replication = новое-значение }
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICATION
Динамический: да
-
replication_anon
¶
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.
Так как анонимная реплика не зарегистрирована в таблице _cluster
, нет никаких ограничений для количества анонимных реплик в наборе: можно создавать их сколько угодно.
Чтобы сделать реплику анонимной, передайте опцию replication_anon=true
в box.cfg
и установите значение read_only
равным true
.
Попробуем создать анонимную реплику. Предположим, что у нас есть мастер с такой настройкой:
box.cfg{listen=3301}
и создан локальный спейс «loc»:
box.schema.space.create('loc', {is_local=true})
box.space.loc:create_index("pk")
Теперь, чтобы настроить анонимную реплику, нам нужно обратиться к box.cfg
, как обычно.
box.cfg{replication_anon=true, read_only=true, replication=3301}
Как было сказано выше, replication_anon
может быть true
только вместе с read_only
. Этот экземпляр получит снимок мастера и начнет следить за его изменениями. Он не получит id, поэтому его значение останется нулевым.
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
...
Теперь можно использовать реплику. Например, можно сделать вставку в локальный спейс:
tarantool> for i = 1,10 do
> box.space.loc:insert{i}
> end
---
...
Заметьте, что пока экземпляр анонимный, увеличится нулевая компонента его vclock
:
tarantool> box.info.vclock
---
- {0: 10, 1: 4}
...
А теперь давайте сделаем анонимную реплику снова обычной:
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-51a46def7661
2019-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> subscribed
2019-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
Эта реплика получила id равный 2. Мы можем снова сделать ее открытой на запись:
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: memtx
before_replace: 'function: 0x01109f9dc8'
on_replace: 'function: 0x01109f9d90'
ck_constraint: []
field_count: 0
temporary: false
index: []
is_local: false
enabled: false
name: test
id: 513
- created
...
tarantool> box.info.vclock
---
- {0: 10, 1: 5, 2: 2}
...
Теперь, как и ожидалось, реплика отслеживает свои изменения во 2-й компоненте vclock. С этого момента она также может стать мастером репликации.
Замечания:
- Нельзя реплицироваться от анонимной реплики.
- Чтобы вернуть анонимный экземпляр к обычному состоянию, сначала запустите его как анонимный, а потом вызовите
box.cfg{replication_anon=false}
- Чтобы деанонимизация прошла успешно, экземпляр должен быть скопирован с какого-то экземпляра, открытого на запись, иначе он не может быть добавлен в таблицу
_cluster
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_ANON
Динамический: да
-
bootstrap_leader
¶
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'},
}
Тип: строка
По умолчанию: null
Environment variable: TT_BOOTSTRAP_LEADER
Динамический: да
-
bootstrap_strategy
¶
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.
Тип: строка
Default: auto
Environment variable: TT_BOOTSTRAP_STRATEGY
Динамический: да
-
replication_connect_timeout
¶
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.
Тип: число с плавающей запятой
По умолчанию: 30
Environment variable: TT_REPLICATION_CONNECT_TIMEOUT
Динамический: да
-
replication_connect_quorum
¶
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.
Пример:
box.cfg { replication_connect_quorum = 2 }
Тип: целое число
По умолчанию: null
Environment variable: TT_REPLICATION_CONNECT_QUORUM
Динамический: да
-
replication_skip_conflict
¶
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.
Однако если указать replication_skip_conflict = true
, пользователи могут задать пропуск таких ошибок. Так, вместо сохранения сломанной транзакции в xlog, там будет записано NOP
(No operation).
Пример:
box.cfg{replication_skip_conflict=true}
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_SKIP_CONFLICT
Динамический: да
Примечание
replication_skip_conflict = true
рекомендуется использовать только для ручного восстановления репликации.
-
replication_sync_lag
¶
Since version 1.9.0.
The maximum lag allowed for a replica.
When a replica syncs
(gets updates from a master), it may not catch up completely.
The number of seconds that the replica is behind the master is called the «lag».
Syncing is considered to be complete when the replica’s lag is less than
or equal to replication_sync_lag
.
Если пользователь задает значение replication_sync_lag
, равное nil или 365 * 100 * 86400 (TIMEOUT_INFINITY), то отставание не имеет значения – реплика всегда будет синхронизирована. Кроме того, отставание не учитывается (считается бесконечным), если мастер работает на версии Tarantool старше 1.7.7, которая не отправляет сообщения контрольного сигнала.
Этот параметр не учитывается во время настройки. Для получения подробной информации, см. статус orphan.
Тип: число с плавающей запятой
По умолчанию: 10
Environment variable: TT_REPLICATION_SYNC_LAG
Динамический: да
-
replication_sync_timeout
¶
Since version 1.10.2.
The number of seconds that a node waits when trying to sync with
other nodes in a replica set (see bootstrap_strategy),
after connecting or during configuration update.
This could fail indefinitely if replication_sync_lag
is smaller
than network latency, or if the replica cannot keep pace with master
updates. If replication_sync_timeout
expires, the replica
enters orphan status.
Тип: число с плавающей запятой
По умолчанию: 300
Environment variable: TT_REPLICATION_SYNC_TIMEOUT
Динамический: да
Примечание
The default replication_sync_timeout
value is going to be changed in future versions from 300
to 0
.
You can learn the reasoning behind this decision from the Default value for replication_sync_timeout topic, which also describes how to try the new behavior in the current version.
-
replication_timeout
¶
Since version 1.7.5.
If the master has no updates to send to the replicas, it sends heartbeat messages
every replication_timeout
seconds, and each replica sends an ACK packet back.
И мастер, и реплики запрограммированы разорвать соединение при отсутствии сообщений в течение четырех промежутков времени, указанного в параметре replication_timeout
. После разрыва соединения реплика пытается снова подключиться к мастеру.
См. дополнительную информацию в разделе Мониторинг набора реплик.
Тип: целое число
По умолчанию: 1
Environment variable: TT_REPLICATION_TIMEOUT
Динамический: да
-
replicaset_uuid
¶
Since version 1.9.0.
As described in section
«Replication architecture»,
each replica set is identified by a
universally unique identifier
called replica set UUID, and each instance is identified by an
instance UUID.
Как правило, достаточно позволить системе сгенерировать и форматировать строки, содержащие UUID, которые будут храниться постоянно.
Однако, некоторые администраторы предпочитают сохранять конфигурацию Tarantool в центральном репозитории, например, Apache ZooKeeper. Они могут самостоятельно присвоить значения экземплярам (instance_uuid) и набору реплик (replicaset_uuid
) при первом запуске.
Общие правила:
- Значения должны быть действительно уникальными; они не должны одновременно принадлежать другим экземплярам или наборам реплик в той же инфраструктуре.
- Значения должны использоваться постоянно, неизменно с первого запуска (первоначальные значения хранятся в файлах снимков и проверяются при каждом перезапуске системы).
- Значения должны соответствовать требованиям RFC 4122. Нулевой UUID не допускается.
Формат UUID включает в себя шестнадцать октетов, представленных в виде 32 шестнадцатеричных чисел (с основанием 16) в пяти группах, разделенных дефисами в форме 8-4-4-4-12
– 36 символов (32 буквенно-цифровых символа и четыре дефиса).
Пример:
box.cfg{replicaset_uuid='7b853d13-508b-4b8e-82e6-806f088ea6e9'}
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_UUID
Динамический: нет
-
instance_uuid
¶
Since version 1.9.0.
For replication administration purposes, it is possible to set the
universally unique identifiers
of the instance (instance_uuid
) and the replica set
(replicaset_uuid
), instead of having the system generate the values.
Для получения подробной информации см. описание параметра replicaset_uuid.
Пример:
box.cfg{instance_uuid='037fec43-18a9-4e12-a684-a42b716fcd02'}
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_UUID
Динамический: нет
-
replication_synchro_quorum
¶
Since version 2.5.1.
For synchronous replication only.
This option tells how many replicas should confirm the receipt of a
synchronous transaction before it can finish its commit.
Since version 2.5.3,
the option supports dynamic evaluation of the quorum number.
That is, the number of quorum can be specified not as a constant number, but as a function instead.
In this case, the option returns the formula evaluated.
The result is treated as an integer number.
Once any replicas are added or removed, the expression is re-evaluated automatically.
For example,
box.cfg{replication_synchro_quorum = "N / 2 + 1"}
Where N
is a current number of registered replicas in a cluster.
Keep in mind that the example above represents a canonical quorum definition.
The formula at least 50% of the cluster size + 1
guarantees data reliability.
Using a value less than the canonical one might lead to unexpected results,
including a split-brain.
Since version 2.10.0, this option
does not account for anonymous replicas.
По умолчанию значение параметра равно N / 2 + 1
.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Если значение параметра равно 1
, синхронные транзакции работают как асинхронные, пока они не настроены. 1
означает, что для коммита достаточно успешной записи в WAL на мастере.
Тип: число
Default: N / 2 + 1 (before version 2.10.0, the default value was 1)
Environment variable: TT_REPLICATION_SYNCHRO_QUORUM
Динамический: да
-
replication_synchro_timeout
¶
Since version 2.5.1.
For synchronous replication only.
Tells how many seconds to wait for a synchronous transaction quorum
replication until it is declared failed and is rolled back.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Тип: число
По умолчанию: 5
Environment variable: TT_REPLICATION_SYNCHRO_TIMEOUT
Динамический: да
-
replication_threads
¶
Since version 2.10.0.
The number of threads spawned to decode the incoming replication data.
The default value is 1
.
It means that a single separate thread handles all the incoming replication streams.
In most cases, one thread is enough for all incoming data.
Therefore, it is likely that the user will not need to set this configuration option.
Possible values range from 1 to 1000.
If there are multiple replication threads, connections to serve are distributed evenly between the threads.
Тип: число
По умолчанию: 1
Possible values: from 1 to 1000
Environment variable: TT_REPLICATION_THREADS
Dynamic: no
-
election_mode
¶
Since version 2.6.1.
Specify the role of a replica set node in the
leader election process.
Possible values:
- off
- voter
- candidate
- manual.
Participation of a replica set node in the automated leader election can be
turned on and off by this option.
The default value is off
. All nodes that have values other than off
run the Raft state machine internally talking to other nodes according
to the Raft leader election protocol. When the option is off
, the node
accepts Raft messages
from other nodes, but it doesn’t participate in the election activities,
and this doesn’t affect the node’s state. So, for example, if a node is not
a leader but it has election_mode = 'off'
, it is writable anyway.
You can control which nodes can become a leader. If you want a node
to participate in the election process but don’t want that it becomes
a leaders, set the election_mode
option to voter
. In this case,
the election works as usual, this particular node will vote for other nodes,
but won’t become a leader.
If the node should be able to become a leader, use election_mode = 'candidate'
.
Since version 2.8.2, the manual election mode is introduced.
It may be used when a user wants to control which instance is the leader explicitly instead of relying on
the Raft election algorithm.
When an instance is configured with the election_mode='manual'
, it behaves as follows:
- By default, the instance acts like a voter – it is read-only and may vote for other instances that are candidates.
- Once box.ctl.promote() is called, the instance becomes a candidate and starts a new election round.
If the instance wins the elections, it becomes a leader, but won’t participate in any new elections.
Тип: строка
Default: „off“
Environment variable: TT_ELECTION_MODE
Динамический: да
-
election_timeout
¶
Since version 2.6.1.
Specify the timeout between election rounds in the
leader election process if the previous round
ended up with a split-vote.
In the leader election process, there
can be an election timeout for the case of a split-vote.
The timeout can be configured using this option; the default value is
5 seconds.
It is quite big, and for most of the cases it can be freely lowered to
300-400 ms. It can be a floating point value (300 ms would be
box.cfg{election_timeout = 0.3}
).
To avoid the split vote repeat, the timeout is randomized on each node
during every new election, from 100% to 110% of the original timeout value.
For example, if the timeout is 300 ms and there are 3 nodes started
the election simultaneously in the same term,
they can set their election timeouts to 300, 310, and 320 respectively,
or to 305, 302, and 324, and so on. In that way, the votes will never be split
because the election on different nodes won’t be restarted simultaneously.
Тип: число
По умолчанию: 5
Environment variable: TT_ELECTION_TIMEOUT
Динамический: да
-
election_fencing_mode
¶
Since version 2.11.0.
In earlier Tarantool versions, use election_fencing_enabled instead.
Specify the leader fencing mode that
affects the leader election process. When the parameter is set to soft
or strict
, the leader resigns its leadership if it has less than
replication_synchro_quorum
of alive connections to the cluster nodes.
The resigning leader receives the status of a
follower in the current election term and becomes
read-only.
- In
soft
mode, a connection is considered dead if there are no responses for
4*replication_timeout seconds both on the current leader and the followers.
- In
strict
mode, a connection is considered dead if there are no responses
for 2*replication_timeout seconds on the
current leader and
4*replication_timeout seconds on the
followers. This improves chances that there is only one leader at any time.
Fencing applies to the instances that have the
election_mode set to candidate
or manual
.
To turn off leader fencing, set election_fencing_mode
to off
.
Тип: строка
Default: „soft“
Environment variable: TT_ELECTION_FENCING_MODE
Динамический: да
-
instance_name
¶
Since version 3.0.0.
Specify the instance name.
This value must be unique in a replica set.
The following rules are applied to instance names:
- The maximum number of symbols is 63.
- Should start with a letter.
- Can contain lowercase letters (a-z). If uppercase letters are used, they are converted to lowercase.
- Can contain digits (0-9).
- Can contain the following characters:
-
, _
.
To change or remove the specified name, you should temporarily set the box.cfg.force_recovery configuration option to true
.
When all the names are updated and all the instances synced, box.cfg.force_recovery
can be set back to false
.
Примечание
The instance name is persisted in the box.space._cluster system space.
See also: box.info.name
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_NAME
Динамический: нет
-
replicaset_name
¶
Since version 3.0.0.
Specify the name of a replica set to which this instance belongs.
This value must be the same for all instances of the replica set.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The replica set name is persisted in the box.space._schema system space.
See also: box.info.replicaset
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_NAME
Динамический: нет
-
cluster_name
¶
Since version 3.0.0.
Specify the name of a cluster to which this instance belongs.
This value must be the same for all instances of the cluster.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The cluster name is persisted in the box.space._schema system space.
See also: box.info.cluster
Тип: строка
По умолчанию: null
Environment variable: TT_CLUSTER_NAME
Динамический: нет
Работа с сетями
-
io_collect_interval
¶
Since version 1.4.9.
The instance will sleep for io_collect_interval seconds between iterations
of the event loop. Can be used to reduce CPU load in deployments in which
the number of client connections is large, but requests are not so frequent
(for example, each connection issues just a handful of requests per second).
Тип: число с плавающей запятой
По умолчанию: null
Environment variable: TT_IO_COLLECT_INTERVAL
Динамический: да
-
net_msg_max
¶
Since version 1.10.1.
To handle messages, Tarantool allocates fibers.
To prevent fiber overhead from affecting the whole system,
Tarantool restricts how many messages the fibers handle,
so that some pending requests are blocked.
В мощных системах увеличьте значение net_msg_max
, и планировщик немедленно приступит к обработке отложенных запросов.
В более слабых системах уменьшите значение net_msg_max
, чтобы снизить загрузку, хотя это и займет некоторое время, поскольку планировщик будет ожидать завершения уже запущенных запросов.
When net_msg_max
is reached,
Tarantool suspends processing of incoming packages until it
has processed earlier messages. This is not a direct restriction of
the number of fibers that handle network messages, rather it
is a system-wide restriction of channel bandwidth.
This in turn causes restriction of the number of incoming
network messages that the
transaction processor thread
handles, and therefore indirectly affects the fibers that handle
network messages.
(The number of fibers is smaller than the number of messages because
messages can be released as soon as they are delivered, while
incoming requests might not be processed until some time after delivery.)
Для стандартных систем подойдет значение, используемое по умолчанию (768).
Тип: целое число
По умолчанию: 768
Environment variable: TT_NET_MSG_MAX
Динамический: да
-
readahead
¶
Since version 1.6.2.
The size of the read-ahead buffer associated with a client connection. The
larger the buffer, the more memory an active connection consumes and the
more requests can be read from the operating system buffer in a single
system call. The rule of thumb is to make sure the buffer can contain at
least a few dozen requests. Therefore, if a typical tuple in a request is
large, e.g. a few kilobytes or even megabytes, the read-ahead buffer size
should be increased. If batched request processing is not used, it’s prudent
to leave this setting at its default.
Тип: целое число
По умолчанию: 16320
Environment variable: TT_READAHEAD
Динамический: да
-
iproto_threads
¶
Since version 2.8.1.
The number of network threads.
There can be unusual workloads where the network thread
is 100% loaded and the transaction processor thread is not, so the network
thread is a bottleneck. In that case set iproto_threads
to 2 or more.
The operating system kernel will determine which connection goes to
which thread.
On typical systems, the default value (1) is correct.
Тип: целое число
По умолчанию: 1
Environment variable: TT_IPROTO_THREADS
Динамический: нет
Запись в журнал
This section provides information on how to configure options related to logging.
You can also use the log module to configure logging in your
application.
-
log_level
¶
Since version 1.6.2.
Specify the level of detail the log has. There are the following levels:
- 0 –
fatal
- 1 –
syserror
- 2 –
error
- 3 –
crit
- 4 –
warn
- 5 –
info
- 6 –
verbose
- 7 –
debug
By setting log_level
, you can enable logging of all events with severities above
or equal to the given level. Tarantool prints logs to the standard
error stream by default. This can be changed with the
log configuration parameter.
Type: integer, string
По умолчанию: 5
Environment variable: TT_LOG_LEVEL
Динамический: да
Примечание
Prior to Tarantool 1.7.5 there were only six levels and DEBUG
was
level 6. Starting with Tarantool 1.7.5, VERBOSE
is level 6 and DEBUG
is level 7.
VERBOSE
is a new level for monitoring repetitive events which would cause
too much log writing if INFO
were used instead.
-
log
¶
Since version 1.7.4.
By default, Tarantool sends the log to the standard error stream
(stderr
). If log
is specified, Tarantool can send the log to a:
- file
- pipe
- system logger
Example 1: sending the log to the tarantool.log
file.
box.cfg{log = 'tarantool.log'}
-- или
box.cfg{log = 'file:tarantool.log'}
This opens the file tarantool.log
for output on the server’s default
directory. If the log
string has no prefix or has the prefix «file:»,
then the string is interpreted as a file path.
Example 2: sending the log to a pipe.
box.cfg{log = '| cronolog tarantool.log'}
-- or
box.cfg{log = 'pipe: cronolog tarantool.log'}
This starts the program cronolog when the server starts, and
sends all log messages to the standard input (stdin
) of cronolog
.
If the log
string begins with „|“ or has the prefix «pipe:»,
then the string is interpreted as a Unix
pipeline.
Example 3: sending the log to syslog.
box.cfg{log = 'syslog:identity=tarantool'}
-- или
box.cfg{log = 'syslog:facility=user'}
-- или
box.cfg{log = 'syslog:identity=tarantool,facility=user'}
-- или
box.cfg{log = 'syslog:server=unix:/dev/log'}
If the log
string begins with «syslog:», then it is
interpreted as a message for the
syslogd program, which normally
is running in the background on any Unix-like platform.
The setting can be syslog:
, syslog:facility=...
, syslog:identity=...
,
syslog:server=...
, or a combination.
- The
syslog:identity
setting is an arbitrary string, which is placed at
the beginning of all messages. The default value is «tarantool».
- В настоящий момент настройка
syslog:facility
не учитывается, но будет использоваться в дальнейшем. Ее значением должно быть одно из ключевых слов syslog, которые сообщают программе syslogd, куда отправлять сообщение. Возможные значения: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7. По умолчанию: user.
- The
syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path beginning with «unix:», or an ipv4 port number.
The default socket value is: dev/log
(on Linux) or /var/run/syslog
(on macOS).
The default port value is: 514, the UDP port.
When logging to a file, Tarantool reopens the log on SIGHUP.
When log is a program, its PID is saved in the log.pid
variable. You need to send it a signal to rotate logs.
Тип: строка
По умолчанию: null
Environment variable: TT_LOG
Динамический: нет
-
log_nonblock
¶
Since version 1.7.4.
If log_nonblock
equals true, Tarantool does not block during logging
when the system is not ready for writing, and drops the message
instead. If log_level is high, and many
messages go to the log, setting log_nonblock
to true may improve
logging performance at the cost of some log messages getting lost.
This parameter has effect only if log is
configured to send logs to a pipe or system logger.
The default log_nonblock
value is nil, which means that
blocking behavior corresponds to the logger type:
- false for
stderr
and file loggers.
- true for a pipe and system logger.
This is a behavior change: in earlier versions of the Tarantool
server, the default value was true.
Тип: логический
По умолчанию: nil
Environment variable: TT_LOG_NONBLOCK
Динамический: нет
-
too_long_threshold
¶
Since version 1.6.2.
If processing a request takes longer than the given value (in seconds),
warn about it in the log. Has effect only if log_level is greater than or equal to 4 (WARNING).
Тип: число с плавающей запятой
По умолчанию: 0.5
Environment variable: TT_TOO_LONG_THRESHOLD
Динамический: да
-
log_format
¶
Since version 1.7.6.
Log entries have two possible formats:
- „plain“ (по умолчанию) или
- „json“ (более детально с JSON-метками).
Here is what a log entry looks like if box.cfg{log_format='plain'}
:
2017-10-16 11:36:01.508 [18081] main/101/interactive I> set 'log_format' configuration option to "plain"
Here is what a log entry looks like if box.cfg{log_format='json'}
:
{"time": "2017-10-16T11:36:17.996-0600",
"level": "INFO",
"message": "set 'log_format' configuration option to \"json\"",
"pid": 18081,|
"cord_name": "main",
"fiber_id": 101,
"fiber_name": "interactive",
"file": "builtin\/box\/load_cfg.lua",
"line": 317}
The log_format='plain'
entry has a time value, process ID,
cord name, fiber_id,
fiber_name,
log level, and message.
The log_format='json'
entry has the same fields along with their labels,
and in addition has the file name and line number of the Tarantool source.
Тип: строка
По умолчанию: „plain“
Environment variable: TT_LOG_FORMAT
Динамический: да
-
log_modules
¶
Since version 2.11.0.
Configure the specified log levels (log_level) for different modules.
You can specify a logging level for the following module types:
- Modules (files) that use the default logger.
Example: Set log levels for files that use the default logger.
- Modules that use custom loggers created using the log.new() function.
Example: Set log levels for modules that use custom loggers.
- The
tarantool
module that enables you to configure the logging level for Tarantool core messages. Specifically, it configures the logging level for messages logged from non-Lua code, including C modules.
Example: Set a log level for C modules.
Type: table
Default: blank
Environment variable: TT_LOG_MODULES
Динамический: да
Example 1: Set log levels for files that use the default logger
Suppose you have two identical modules placed by the following paths: test/logging/module1.lua
and test/logging/module2.lua
.
These modules use the default logger and look as follows:
return {
say_hello = function()
local log = require('log')
log.info('Info message from module1')
end
}
To load these modules in your application, you need to add the corresponding require
directives:
module1 = require('test.logging.module1')
module2 = require('test.logging.module2')
To configure logging levels, you need to provide module names corresponding to paths to these modules.
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function:
box_cfg = { log_modules = {
['test.logging.module1'] = 'verbose',
['test.logging.module2'] = 'error' }
}
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1.say_hello()
shows a message but module2.say_hello()
is swallowed:
-- Prints 'info' messages --
module1.say_hello()
--[[
[92617] main/103/interactive/test.logging.module1 I> Info message from module1
---
...
--]]
-- Swallows 'info' messages --
module2.say_hello()
--[[
---
...
--]]
Example 2: Set log levels for modules that use custom loggers
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the verbose
level for module1
and the error
level for module2
:
box_cfg = { log_level = 'warn',
log_modules = {
module1 = 'verbose',
module2 = 'error' }
}
To create custom loggers, call the log.new() function:
-- Creates new loggers --
module1_log = require('log').new('module1')
module2_log = require('log').new('module2')
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1_log.info()
shows a message but module2_log.info()
is swallowed:
-- Prints 'info' messages --
module1_log.info('Info message from module1')
--[[
[16300] main/103/interactive/module1 I> Info message from module1
---
...
--]]
-- Swallows 'debug' messages --
module1_log.debug('Debug message from module1')
--[[
---
...
--]]
-- Swallows 'info' messages --
module2_log.info('Info message from module2')
--[[
---
...
--]]
Example 3: Set a log level for C modules
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the info
level for the tarantool
module:
box_cfg = { log_level = 'warn',
log_modules = { tarantool = 'info' } }
The specified level affects messages logged from C modules:
ffi = require('ffi')
-- Prints 'info' messages --
ffi.C._say(ffi.C.S_INFO, nil, 0, nil, 'Info message from C module')
--[[
[6024] main/103/interactive I> Info message from C module
---
...
--]]
-- Swallows 'debug' messages --
ffi.C._say(ffi.C.S_DEBUG, nil, 0, nil, 'Debug message from C module')
--[[
---
...
--]]
The example above uses the LuaJIT ffi library to call C functions provided by the say
module.
This example illustrates how «rotation» works, that is, what happens when the server
instance is writing to a log and signals are used when archiving it.
Start with two terminal shells: Terminal #1 and Terminal #2.
In Terminal #1, start an interactive Tarantool session.
Then, use the log
property to send logs to Log_file
and
call log.info
to put a message in the log file.
box.cfg{log='Log_file'}
log = require('log')
log.info('Log Line #1')
In Terminal #2, use the mv
command to rename the log file to Log_file.bak
.
mv Log_file Log_file.bak
As a result, the next log message will go to Log_file.bak
.
Go back to Terminal #1 and put a message «Log Line #2» in the log file.
log.info('Log Line #2')
In Terminal #2, use ps
to find the process ID of the Tarantool instance.
ps -A | grep tarantool
In Terminal #2, execute kill -HUP
to send a SIGHUP signal to the Tarantool instance.
Tarantool will open Log_file
again, and the next log message will go to Log_file
.
kill -HUP process_id
The same effect could be accomplished by calling log.rotate.
In Terminal #1, put a message «Log Line #3» in the log file.
log.info('Log Line #3')
In Terminal #2, use less
to examine files.
Log_file.bak
will have the following lines …
2015-11-30 15:13:06.373 [27469] main/101/interactive I> Log Line #1`
2015-11-30 15:14:25.973 [27469] main/101/interactive I> Log Line #2`
… and Log_file
will look like this:
log file has been reopened
2015-11-30 15:15:32.629 [27469] main/101/interactive I> Log Line #3
Audit log
Enterprise Edition
Audit log features are available in the Enterprise Edition only.
The audit_*
parameters define configuration related to audit logging.
-
audit_extract_key
¶
Since: 3.0.0.
If set to true
, the audit subsystem extracts and prints only the primary key instead of full
tuples in DML events (space_insert
, space_replace
, space_delete
).
Otherwise, full tuples are logged.
The option may be useful in case tuples are big.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_AUDIT_EXTRACT_KEY
-
audit_filter
¶
Enable logging for a specified subset of audit events.
This option accepts the following values:
- Event names (for example,
password_change
). For details, see Audit log events.
- Event groups (for example,
audit
). For details, see Event groups.
The option contains either one value from Possible values
section (see below) or a combination of them.
To enable custom audit log events, specify the custom
value in this option.
The default value is compatibility
, which enables logging of all events available before 2.10.0.
Example
box.cfg{
audit_log = 'audit.log',
audit_filter = 'audit,auth,priv,password_change,access_denied'
}
Type: array
Possible values: „all“, „audit“, „auth“, „priv“, „ddl“, „dml“, „data_operations“, „compatibility“,
„audit_enable“, „auth_ok“, „auth_fail“, „disconnect“, „user_create“, „user_drop“, „role_create“, „role_drop“,
„user_disable“, „user_enable“, „user_grant_rights“, „role_grant_rights“, „role_revoke_rights“, „password_change“,
„access_denied“, „eval“, „call“, „space_select“, „space_create“, „space_alter“, „space_drop“, „space_insert“,
„space_replace“, „space_delete“, „custom“
Default: „compatibility“
Environment variable: TT_AUDIT_FILTER
-
audit_format
¶
Specify the format that is used for the audit log events – plain text, CSV or JSON format.
Plain text is used by default. This human-readable format can be efficiently compressed.
box.cfg{audit_log = 'audit.log', audit_format = 'plain'}
Example
remote: session_type:background module:common.admin.auth user: type:custom_tdg_audit tag:tdg_severity_INFO description:[5e35b406-4274-4903-857b-c80115275940] subj: "anonymous", msg: "Access granted to anonymous user"
The JSON format is more convenient to receive log events, analyze them and integrate them with other systems if needed.
box.cfg{audit_log = 'audit.log', audit_format = 'json'}
Example
{"time": "2022-11-17T21:55:49.880+0300", "remote": "", "session_type": "background", "module": "common.admin.auth", "user": "", "type": "custom_tdg_audit", "tag": "tdg_severity_INFO", "description": "[c26cd11a-3342-4ce6-8f0b-a4b222268b9d] subj: \"anonymous\", msg: \"Access granted to anonymous user\""}
Using the CSV format allows you to view audit log events in tabular form.
box.cfg{audit_log = 'audit.log', audit_format = 'csv'}
Example
2022-11-17T21:58:03.131+0300,,background,common.admin.auth,,,custom_tdg_audit,tdg_severity_INFO,"[b3dfe2a3-ec29-4e61-b747-eb2332c83b2e] subj: ""anonymous"", msg: ""Access granted to anonymous user"""
Тип: строка
Possible values: „json“, „csv“, „plain“
Default: „json“
Environment variable: TT_AUDIT_FORMAT
-
audit_log
¶
Enable audit logging and define the log location.
This option accepts a string value that allows you to define the log location.
The following locations are supported:
- File: to write audit logs to a file, specify a path to a file (with an optional
file
prefix)
- Pipeline: to start a program and write audit logs to it, specify a program name (with
|
or pipe
prefix)
- System log: to write audit logs to a system log, specify a message for
syslogd
(with syslog
prefix)
See the examples below.
By default, audit logging is disabled.
Example: Writing to a file
box.cfg{audit_log = 'audit_tarantool.log'}
-- or
box.cfg{audit_log = 'file:audit_tarantool.log'}
This opens the audit_tarantool.log
file for output in the server’s default directory.
If the audit_log
string has no prefix or the prefix file:
, the string is interpreted as a file path.
If you log to a file, Tarantool will reopen the audit log at SIGHUP.
Example: Sending to a pipeline
box.cfg{audit_log = '| cronolog audit_tarantool.log'}
-- or
box.cfg{audit_log = 'pipe: cronolog audit_tarantool.log'}'
This starts the cronolog program when the server starts
and sends all audit_log
messages to cronolog’s standard input (stdin
).
If the audit_log
string starts with „|“ or contains the prefix pipe:
,
the string is interpreted as a Unix pipeline.
If log is a program, check out its pid and send it a signal to rotate logs.
Example: Writing to a system log
Предупреждение
Below is an example of writing audit logs to a directory shared with the system logs.
Tarantool allows this option, but it is not recommended to do this to avoid difficulties
when working with audit logs. System and audit logs should be written separately.
To do this, create separate paths and specify them.
This sample configuration sends the audit log to syslog:
box.cfg{audit_log = 'syslog:identity=tarantool'}
-- or
box.cfg{audit_log = 'syslog:facility=user'}
-- or
box.cfg{audit_log = 'syslog:identity=tarantool,facility=user'}
-- or
box.cfg{audit_log = 'syslog:server=unix:/dev/log'}
If the audit_log
string starts with «syslog:»,
it is interpreted as a message for the syslogd program,
which normally runs in the background of any Unix-like platform.
The setting can be „syslog:“, „syslog:facility=…“, „syslog:identity=…“, „syslog:server=…“ or a combination.
The syslog:identity
setting is an arbitrary string that is placed at the beginning of all messages.
The default value is tarantool
.
The syslog:facility
setting is currently ignored, but will be used in the future.
The value must be one of the syslog keywords
that tell syslogd
where to send the message.
The possible values are auth
, authpriv
, cron
, daemon
, ftp
,
kern
, lpr
, mail
, news
, security
, syslog
, user
, uucp
,
local0
, local1
, local2
, local3
, local4
, local5
, local6
, local7
.
The default value is local7
.
The syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path starting with «unix:» or an ipv4 port number.
The default socket value is /dev/log
(on Linux) or /var/run/syslog
(on Mac OS).
The default port value is 514, which is the UDP port.
An example of a Tarantool audit log entry in the syslog:
09:32:52 tarantool_audit: {"time": "2024-02-08T09:32:52.190+0300", "uuid": "94454e46-9a0e-493a-bb9f-d59e44a43581", "severity": "INFO", "remote": "unix/:(socket)", "session_type": "console", "module": "tarantool", "user": "admin", "type": "space_create", "tag": "", "description": "Create space bands"}
Тип: строка
Possible values: see the string format above
Default: „nill“
Environment variable: TT_AUDIT_LOG
-
audit_nonblock
¶
Specify the logging behavior if the system is not ready to write.
If set to true
, Tarantool does not block during logging if the system is non-writable and writes a message instead.
Using this value may improve logging performance at the cost of losing some log messages.
Примечание
The option only has an effect if the audit_log is set to syslog
or pipe
.
Setting audit_nonblock
to true
is not allowed if the output is to a file.
In this case, set audit_nonblock
to false
.
Тип: логический
По умолчанию: true
Environment variable: TT_AUDIT_NONBLOCK
-
audit_spaces
¶
Since: 3.0.0.
The array of space names for which data operation events (space_select
, space_insert
, space_replace
,
space_delete
) should be logged. The array accepts string values.
If set to box.NULL, the data operation events are logged for all spaces.
Example
In the example, only the events of bands
and singers
spaces are logged:
box.cfg{
audit_spaces = 'bands,singers'
}
Type: array
Default: box.NULL
Environment variable: TT_AUDIT_SPACES
Authentication
Enterprise Edition
Authentication features are supported by the Enterprise Edition only.
- auth_delay
- auth_retries
- auth_type
- disable_guest
- password_min_length
- password_enforce_uppercase
- password_enforce_lowercase
- password_enforce_digits
- password_enforce_specialchars
- password_lifetime_days
- password_history_length
-
auth_delay
¶
Since 2.11.0.
Specify a period of time (in seconds) that a specific user should wait
for the next attempt after failed authentication.
With the configuration below, Tarantool refuses the authentication attempt if the previous
attempt was less than 5 seconds ago.
box.cfg{ auth_delay = 5 }
Тип: число
Default: 0
Environment variable: TT_AUTH_DELAY
Динамический: да
-
auth_retries
¶
Since 3.0.0.
Specify the maximum number of authentication retries allowed before auth_delay
is enforced.
The default value is 0, which means auth_delay
is enforced after the first failed authentication attempt.
The retry counter is reset after auth_delay
seconds since the first failed attempt.
For example, if a client tries to authenticate fewer than auth_retries
times within auth_delay
seconds, no authentication delay is enforced.
The retry counter is also reset after any successful authentication attempt.
Тип: число
Default: 0
Environment variable: TT_AUTH_RETRIES
Динамический: да
-
auth_type
¶
Since 2.11.0.
Specify an authentication protocol:
- „chap-sha1“: use the CHAP protocol to authenticate users with
SHA-1
hashing applied to passwords.
- „pap-sha256“: use PAP authentication with the
SHA256
hashing algorithm.
For new users, the box.schema.user.create method
will generate authentication data using PAP-SHA256
.
For existing users, you need to reset a password using
box.schema.user.passwd
to use the new authentication protocol.
Тип: строка
Default value: „chap-sha1“
Environment variable: TT_AUTH_TYPE
Динамический: да
-
disable_guest
¶
Since 2.11.0.
If true, disables access over remote connections
from unauthenticated or guest access users.
This option affects both
net.box and
replication connections.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_DISABLE_GUEST
Динамический: да
-
password_min_length
¶
Since 2.11.0.
Specify the minimum number of characters for a password.
The following example shows how to set the minimum password length to 10.
box.cfg{ password_min_length = 10 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_MIN_LENGTH
Динамический: да
-
password_enforce_uppercase
¶
Since 2.11.0.
If true, a password should contain uppercase letters (A-Z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_UPPERCASE
Динамический: да
-
password_enforce_lowercase
¶
Since 2.11.0.
If true, a password should contain lowercase letters (a-z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_LOWERCASE
Динамический: да
-
password_enforce_digits
¶
Since 2.11.0.
If true, a password should contain digits (0-9).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_DIGITS
Динамический: да
-
password_enforce_specialchars
¶
Since 2.11.0.
If true, a password should contain at least one special character (such as &|?!@$
).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARS
Динамический: да
-
password_lifetime_days
¶
Since 2.11.0.
Specify the maximum period of time (in days) a user can use the same password.
When this period ends, a user gets the «Password expired» error on a login attempt.
To restore access for such users, use box.schema.user.passwd.
Примечание
The default 0 value means that a password never expires.
The example below shows how to set a maximum password age to 365 days.
box.cfg{ password_lifetime_days = 365 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_LIFETIME_DAYS
Динамический: да
-
password_history_length
¶
Since 2.11.0.
Specify the number of unique new user passwords before an old password can be reused.
In the example below, a new password should differ from the last three passwords.
box.cfg{ password_history_length = 3 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_HISTORY_LENGTH
Динамический: да
Примечание
Tarantool uses the auth_history
field in the
box.space._user
system space to store user passwords.
Flight recorder
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶
Since 2.11.0.
Enable the flight recorder.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FLIGHTREC_ENABLED
Динамический: да
-
flightrec_logs_size
¶
Since 2.11.0.
Specify the size (in bytes) of the log storage.
You can set this option to 0
to disable the log storage.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_LOGS_SIZE
Динамический: да
-
flightrec_logs_max_msg_size
¶
Since 2.11.0.
Specify the maximum size (in bytes) of the log message.
The log message is truncated if its size exceeds this limit.
Тип: целое число
Default: 4096
Maximum: 16384
Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZE
Динамический: да
-
flightrec_logs_log_level
¶
Since 2.11.0.
Specify the level of detail the log has.
You can learn more about log levels from the log_level
option description.
Note that the flightrec_logs_log_level
value might differ from log_level
.
Тип: целое число
Default: 6
Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVEL
Динамический: да
-
flightrec_metrics_period
¶
Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump.
So, this value defines how much historical metrics data is collected up to the moment of crash.
The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое число
Default: 180
Environment variable: TT_FLIGHTREC_METRICS_PERIOD
Динамический: да
-
flightrec_metrics_interval
¶
Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics.
This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB,
you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: число
По умолчанию: 1.0
Minimum: 0.001
Environment variable: TT_FLIGHTREC_METRICS_INTERVAL
Динамический: да
-
flightrec_requests_size
¶
Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data.
You can set this parameter to 0
to disable a storage of requests and responses.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_REQUESTS_SIZE
Динамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
- 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
-
force_recovery
¶ 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().В остальных случаях Tarantool прерывает восстановление на ошибке чтения.
Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_FORCE_RECOVERYДинамический: нет
-
wal_max_size
¶ 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 thanwal_max_size
, Tarantool creates a new WAL file.Тип: целое числоПо умолчанию: 268435456 (256 * 1024 * 1024) байтовEnvironment variable: TT_WAL_MAX_SIZEДинамический: нет
-
snap_io_rate_limit
¶ 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.Тип: число с плавающей запятойПо умолчанию: nullEnvironment variable: TT_SNAP_IO_RATE_LIMITДинамический: да
-
wal_mode
¶ Since version 1.6.2.
Specify fiber-WAL-disk synchronization mode as:
none
: write-ahead log is not maintained. A node withwal_mode
set tonone
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).
Тип: строкаПо умолчанию: «write»Environment variable: TT_WAL_MODEДинамический: нет
-
wal_dir_rescan_delay
¶ 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.
Тип: число с плавающей запятойПо умолчанию: 2Environment variable: TT_WAL_DIR_RESCAN_DELAYДинамический: нет
-
wal_queue_max_size
¶ 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.
Примечание
You might consider increasing the
wal_queue_max_size
value in case of large tuples (approximately one megabyte or larger).Тип: числоDefault: 16777216 bytesEnvironment variable: TT_WAL_QUEUE_MAX_SIZEДинамический: да
-
wal_cleanup_delay
¶ 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.Примечание
The
wal_cleanup_delay
option has no effect on nodes running as anonymous replicas.Тип: числоDefault: 14400 secondsEnvironment variable: TT_WAL_CLEANUP_DELAYДинамический: да
-
wal_ext
¶ 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
andnew
options totrue
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 forspace2
.
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По умолчанию: nilEnvironment variable: TT_WAL_EXTДинамический: да
-
secure_erasing
¶ 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.Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_SECURE_ERASINGДинамический: да
Горячее резервирование
-
hot_standby
¶
Since version 1.7.4.
Whether to start the server in hot standby mode.
Горячее резервирование – это функция, которая обеспечивает простое восстановление после отказа без репликации.
Предполагается, что есть два экземпляра сервера, использующих одну и ту же конфигурацию. Первый из них станет «основным» экземпляром. Тот, который запускается вторым, станет «резервным» экземпляром.
Чтобы создать резервный экземпляр, запустите второй экземпляр Tarantool-сервера на том же компьютере с теми же настройками конфигурации box.cfg – включая одинаковые директории и ненулевые URI – и с дополнительной настройкой конфигурации hot_standby = true
. В ближайшее время вы увидите уведомление, которое заканчивается словами I> Entering hot standby mode
(вход в режим горячего резервирования). Всё в порядке – это означает, что резервный экземпляр готов взять работу на себя, если основной экземпляр прекратит работу.
Резервный экземпляр начнет инициализацию и попытается заблокировать wal_dir, но не сможет, поскольку директория wal_dir
заблокирована основным экземпляром. Поэтому резервный экземпляр входит в цикл, выполняя чтение журнала упреждающей записи, в который записывает данные основной экземпляр (поэтому два экземпляра всегда синхронизированы), и пытаясь произвести блокировку. Если основной экземпляр по какой-либо причине прекращает работу, блокировка снимается. В таком случае резервный экземпляр сможет заблокировать директорию на себя, подключится по адресу для прослушивания и станет основным экземпляром. В ближайшее время вы увидите уведомление, которое заканчивается словами I> ready to accept requests
(готов принимать запросы).
Таким образом, если основной экземпляр прекращает работу, время простоя отсутствует.
Функция горячего резервирования не работает:
- если wal_dir_rescan_delay = большое число (в Mac OS и FreeBSD); на этих платформах цикл запрограммирован на повторение каждые
wal_dir_rescan_delay
секунд.
- если wal_mode = „none“; будет работать только при
wal_mode = 'write'
или wal_mode = 'fsync'
.
- со спейсами, созданными на движке vinyl engine = „vinyl“; работает с движком memtx
engine = 'memtx'
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_HOT_STANDBY
Динамический: нет
Репликация
- 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
-
replication
¶
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
Если в наборе реплик более одного источника репликации, укажите массив URI, например (замените „uri“ и „uri2“ в данном примере на рабочие URI):
box.cfg{ replication = { 'uri1', 'uri2' } }
Примечание
Starting from version 2.10.0, there is a number of other ways for specifying several URIs. See syntax examples.
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.
По умолчанию, пользователем считается „guest“.
Реплика в режиме только для чтения не принимает запросы по изменению данных по порту для прослушивания.
Параметр replication
является динамическим, то есть для входа в режим мастера необходимо просто присвоить параметру replication
пустую строку и выполнить следующее:
box.cfg{ replication = новое-значение }
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICATION
Динамический: да
-
replication_anon
¶
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.
Так как анонимная реплика не зарегистрирована в таблице _cluster
, нет никаких ограничений для количества анонимных реплик в наборе: можно создавать их сколько угодно.
Чтобы сделать реплику анонимной, передайте опцию replication_anon=true
в box.cfg
и установите значение read_only
равным true
.
Попробуем создать анонимную реплику. Предположим, что у нас есть мастер с такой настройкой:
box.cfg{listen=3301}
и создан локальный спейс «loc»:
box.schema.space.create('loc', {is_local=true})
box.space.loc:create_index("pk")
Теперь, чтобы настроить анонимную реплику, нам нужно обратиться к box.cfg
, как обычно.
box.cfg{replication_anon=true, read_only=true, replication=3301}
Как было сказано выше, replication_anon
может быть true
только вместе с read_only
. Этот экземпляр получит снимок мастера и начнет следить за его изменениями. Он не получит id, поэтому его значение останется нулевым.
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
...
Теперь можно использовать реплику. Например, можно сделать вставку в локальный спейс:
tarantool> for i = 1,10 do
> box.space.loc:insert{i}
> end
---
...
Заметьте, что пока экземпляр анонимный, увеличится нулевая компонента его vclock
:
tarantool> box.info.vclock
---
- {0: 10, 1: 4}
...
А теперь давайте сделаем анонимную реплику снова обычной:
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-51a46def7661
2019-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> subscribed
2019-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
Эта реплика получила id равный 2. Мы можем снова сделать ее открытой на запись:
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: memtx
before_replace: 'function: 0x01109f9dc8'
on_replace: 'function: 0x01109f9d90'
ck_constraint: []
field_count: 0
temporary: false
index: []
is_local: false
enabled: false
name: test
id: 513
- created
...
tarantool> box.info.vclock
---
- {0: 10, 1: 5, 2: 2}
...
Теперь, как и ожидалось, реплика отслеживает свои изменения во 2-й компоненте vclock. С этого момента она также может стать мастером репликации.
Замечания:
- Нельзя реплицироваться от анонимной реплики.
- Чтобы вернуть анонимный экземпляр к обычному состоянию, сначала запустите его как анонимный, а потом вызовите
box.cfg{replication_anon=false}
- Чтобы деанонимизация прошла успешно, экземпляр должен быть скопирован с какого-то экземпляра, открытого на запись, иначе он не может быть добавлен в таблицу
_cluster
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_ANON
Динамический: да
-
bootstrap_leader
¶
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'},
}
Тип: строка
По умолчанию: null
Environment variable: TT_BOOTSTRAP_LEADER
Динамический: да
-
bootstrap_strategy
¶
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.
Тип: строка
Default: auto
Environment variable: TT_BOOTSTRAP_STRATEGY
Динамический: да
-
replication_connect_timeout
¶
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.
Тип: число с плавающей запятой
По умолчанию: 30
Environment variable: TT_REPLICATION_CONNECT_TIMEOUT
Динамический: да
-
replication_connect_quorum
¶
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.
Пример:
box.cfg { replication_connect_quorum = 2 }
Тип: целое число
По умолчанию: null
Environment variable: TT_REPLICATION_CONNECT_QUORUM
Динамический: да
-
replication_skip_conflict
¶
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.
Однако если указать replication_skip_conflict = true
, пользователи могут задать пропуск таких ошибок. Так, вместо сохранения сломанной транзакции в xlog, там будет записано NOP
(No operation).
Пример:
box.cfg{replication_skip_conflict=true}
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_SKIP_CONFLICT
Динамический: да
Примечание
replication_skip_conflict = true
рекомендуется использовать только для ручного восстановления репликации.
-
replication_sync_lag
¶
Since version 1.9.0.
The maximum lag allowed for a replica.
When a replica syncs
(gets updates from a master), it may not catch up completely.
The number of seconds that the replica is behind the master is called the «lag».
Syncing is considered to be complete when the replica’s lag is less than
or equal to replication_sync_lag
.
Если пользователь задает значение replication_sync_lag
, равное nil или 365 * 100 * 86400 (TIMEOUT_INFINITY), то отставание не имеет значения – реплика всегда будет синхронизирована. Кроме того, отставание не учитывается (считается бесконечным), если мастер работает на версии Tarantool старше 1.7.7, которая не отправляет сообщения контрольного сигнала.
Этот параметр не учитывается во время настройки. Для получения подробной информации, см. статус orphan.
Тип: число с плавающей запятой
По умолчанию: 10
Environment variable: TT_REPLICATION_SYNC_LAG
Динамический: да
-
replication_sync_timeout
¶
Since version 1.10.2.
The number of seconds that a node waits when trying to sync with
other nodes in a replica set (see bootstrap_strategy),
after connecting or during configuration update.
This could fail indefinitely if replication_sync_lag
is smaller
than network latency, or if the replica cannot keep pace with master
updates. If replication_sync_timeout
expires, the replica
enters orphan status.
Тип: число с плавающей запятой
По умолчанию: 300
Environment variable: TT_REPLICATION_SYNC_TIMEOUT
Динамический: да
Примечание
The default replication_sync_timeout
value is going to be changed in future versions from 300
to 0
.
You can learn the reasoning behind this decision from the Default value for replication_sync_timeout topic, which also describes how to try the new behavior in the current version.
-
replication_timeout
¶
Since version 1.7.5.
If the master has no updates to send to the replicas, it sends heartbeat messages
every replication_timeout
seconds, and each replica sends an ACK packet back.
И мастер, и реплики запрограммированы разорвать соединение при отсутствии сообщений в течение четырех промежутков времени, указанного в параметре replication_timeout
. После разрыва соединения реплика пытается снова подключиться к мастеру.
См. дополнительную информацию в разделе Мониторинг набора реплик.
Тип: целое число
По умолчанию: 1
Environment variable: TT_REPLICATION_TIMEOUT
Динамический: да
-
replicaset_uuid
¶
Since version 1.9.0.
As described in section
«Replication architecture»,
each replica set is identified by a
universally unique identifier
called replica set UUID, and each instance is identified by an
instance UUID.
Как правило, достаточно позволить системе сгенерировать и форматировать строки, содержащие UUID, которые будут храниться постоянно.
Однако, некоторые администраторы предпочитают сохранять конфигурацию Tarantool в центральном репозитории, например, Apache ZooKeeper. Они могут самостоятельно присвоить значения экземплярам (instance_uuid) и набору реплик (replicaset_uuid
) при первом запуске.
Общие правила:
- Значения должны быть действительно уникальными; они не должны одновременно принадлежать другим экземплярам или наборам реплик в той же инфраструктуре.
- Значения должны использоваться постоянно, неизменно с первого запуска (первоначальные значения хранятся в файлах снимков и проверяются при каждом перезапуске системы).
- Значения должны соответствовать требованиям RFC 4122. Нулевой UUID не допускается.
Формат UUID включает в себя шестнадцать октетов, представленных в виде 32 шестнадцатеричных чисел (с основанием 16) в пяти группах, разделенных дефисами в форме 8-4-4-4-12
– 36 символов (32 буквенно-цифровых символа и четыре дефиса).
Пример:
box.cfg{replicaset_uuid='7b853d13-508b-4b8e-82e6-806f088ea6e9'}
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_UUID
Динамический: нет
-
instance_uuid
¶
Since version 1.9.0.
For replication administration purposes, it is possible to set the
universally unique identifiers
of the instance (instance_uuid
) and the replica set
(replicaset_uuid
), instead of having the system generate the values.
Для получения подробной информации см. описание параметра replicaset_uuid.
Пример:
box.cfg{instance_uuid='037fec43-18a9-4e12-a684-a42b716fcd02'}
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_UUID
Динамический: нет
-
replication_synchro_quorum
¶
Since version 2.5.1.
For synchronous replication only.
This option tells how many replicas should confirm the receipt of a
synchronous transaction before it can finish its commit.
Since version 2.5.3,
the option supports dynamic evaluation of the quorum number.
That is, the number of quorum can be specified not as a constant number, but as a function instead.
In this case, the option returns the formula evaluated.
The result is treated as an integer number.
Once any replicas are added or removed, the expression is re-evaluated automatically.
For example,
box.cfg{replication_synchro_quorum = "N / 2 + 1"}
Where N
is a current number of registered replicas in a cluster.
Keep in mind that the example above represents a canonical quorum definition.
The formula at least 50% of the cluster size + 1
guarantees data reliability.
Using a value less than the canonical one might lead to unexpected results,
including a split-brain.
Since version 2.10.0, this option
does not account for anonymous replicas.
По умолчанию значение параметра равно N / 2 + 1
.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Если значение параметра равно 1
, синхронные транзакции работают как асинхронные, пока они не настроены. 1
означает, что для коммита достаточно успешной записи в WAL на мастере.
Тип: число
Default: N / 2 + 1 (before version 2.10.0, the default value was 1)
Environment variable: TT_REPLICATION_SYNCHRO_QUORUM
Динамический: да
-
replication_synchro_timeout
¶
Since version 2.5.1.
For synchronous replication only.
Tells how many seconds to wait for a synchronous transaction quorum
replication until it is declared failed and is rolled back.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Тип: число
По умолчанию: 5
Environment variable: TT_REPLICATION_SYNCHRO_TIMEOUT
Динамический: да
-
replication_threads
¶
Since version 2.10.0.
The number of threads spawned to decode the incoming replication data.
The default value is 1
.
It means that a single separate thread handles all the incoming replication streams.
In most cases, one thread is enough for all incoming data.
Therefore, it is likely that the user will not need to set this configuration option.
Possible values range from 1 to 1000.
If there are multiple replication threads, connections to serve are distributed evenly between the threads.
Тип: число
По умолчанию: 1
Possible values: from 1 to 1000
Environment variable: TT_REPLICATION_THREADS
Dynamic: no
-
election_mode
¶
Since version 2.6.1.
Specify the role of a replica set node in the
leader election process.
Possible values:
- off
- voter
- candidate
- manual.
Participation of a replica set node in the automated leader election can be
turned on and off by this option.
The default value is off
. All nodes that have values other than off
run the Raft state machine internally talking to other nodes according
to the Raft leader election protocol. When the option is off
, the node
accepts Raft messages
from other nodes, but it doesn’t participate in the election activities,
and this doesn’t affect the node’s state. So, for example, if a node is not
a leader but it has election_mode = 'off'
, it is writable anyway.
You can control which nodes can become a leader. If you want a node
to participate in the election process but don’t want that it becomes
a leaders, set the election_mode
option to voter
. In this case,
the election works as usual, this particular node will vote for other nodes,
but won’t become a leader.
If the node should be able to become a leader, use election_mode = 'candidate'
.
Since version 2.8.2, the manual election mode is introduced.
It may be used when a user wants to control which instance is the leader explicitly instead of relying on
the Raft election algorithm.
When an instance is configured with the election_mode='manual'
, it behaves as follows:
- By default, the instance acts like a voter – it is read-only and may vote for other instances that are candidates.
- Once box.ctl.promote() is called, the instance becomes a candidate and starts a new election round.
If the instance wins the elections, it becomes a leader, but won’t participate in any new elections.
Тип: строка
Default: „off“
Environment variable: TT_ELECTION_MODE
Динамический: да
-
election_timeout
¶
Since version 2.6.1.
Specify the timeout between election rounds in the
leader election process if the previous round
ended up with a split-vote.
In the leader election process, there
can be an election timeout for the case of a split-vote.
The timeout can be configured using this option; the default value is
5 seconds.
It is quite big, and for most of the cases it can be freely lowered to
300-400 ms. It can be a floating point value (300 ms would be
box.cfg{election_timeout = 0.3}
).
To avoid the split vote repeat, the timeout is randomized on each node
during every new election, from 100% to 110% of the original timeout value.
For example, if the timeout is 300 ms and there are 3 nodes started
the election simultaneously in the same term,
they can set their election timeouts to 300, 310, and 320 respectively,
or to 305, 302, and 324, and so on. In that way, the votes will never be split
because the election on different nodes won’t be restarted simultaneously.
Тип: число
По умолчанию: 5
Environment variable: TT_ELECTION_TIMEOUT
Динамический: да
-
election_fencing_mode
¶
Since version 2.11.0.
In earlier Tarantool versions, use election_fencing_enabled instead.
Specify the leader fencing mode that
affects the leader election process. When the parameter is set to soft
or strict
, the leader resigns its leadership if it has less than
replication_synchro_quorum
of alive connections to the cluster nodes.
The resigning leader receives the status of a
follower in the current election term and becomes
read-only.
- In
soft
mode, a connection is considered dead if there are no responses for
4*replication_timeout seconds both on the current leader and the followers.
- In
strict
mode, a connection is considered dead if there are no responses
for 2*replication_timeout seconds on the
current leader and
4*replication_timeout seconds on the
followers. This improves chances that there is only one leader at any time.
Fencing applies to the instances that have the
election_mode set to candidate
or manual
.
To turn off leader fencing, set election_fencing_mode
to off
.
Тип: строка
Default: „soft“
Environment variable: TT_ELECTION_FENCING_MODE
Динамический: да
-
instance_name
¶
Since version 3.0.0.
Specify the instance name.
This value must be unique in a replica set.
The following rules are applied to instance names:
- The maximum number of symbols is 63.
- Should start with a letter.
- Can contain lowercase letters (a-z). If uppercase letters are used, they are converted to lowercase.
- Can contain digits (0-9).
- Can contain the following characters:
-
, _
.
To change or remove the specified name, you should temporarily set the box.cfg.force_recovery configuration option to true
.
When all the names are updated and all the instances synced, box.cfg.force_recovery
can be set back to false
.
Примечание
The instance name is persisted in the box.space._cluster system space.
See also: box.info.name
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_NAME
Динамический: нет
-
replicaset_name
¶
Since version 3.0.0.
Specify the name of a replica set to which this instance belongs.
This value must be the same for all instances of the replica set.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The replica set name is persisted in the box.space._schema system space.
See also: box.info.replicaset
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_NAME
Динамический: нет
-
cluster_name
¶
Since version 3.0.0.
Specify the name of a cluster to which this instance belongs.
This value must be the same for all instances of the cluster.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The cluster name is persisted in the box.space._schema system space.
See also: box.info.cluster
Тип: строка
По умолчанию: null
Environment variable: TT_CLUSTER_NAME
Динамический: нет
Работа с сетями
-
io_collect_interval
¶
Since version 1.4.9.
The instance will sleep for io_collect_interval seconds between iterations
of the event loop. Can be used to reduce CPU load in deployments in which
the number of client connections is large, but requests are not so frequent
(for example, each connection issues just a handful of requests per second).
Тип: число с плавающей запятой
По умолчанию: null
Environment variable: TT_IO_COLLECT_INTERVAL
Динамический: да
-
net_msg_max
¶
Since version 1.10.1.
To handle messages, Tarantool allocates fibers.
To prevent fiber overhead from affecting the whole system,
Tarantool restricts how many messages the fibers handle,
so that some pending requests are blocked.
В мощных системах увеличьте значение net_msg_max
, и планировщик немедленно приступит к обработке отложенных запросов.
В более слабых системах уменьшите значение net_msg_max
, чтобы снизить загрузку, хотя это и займет некоторое время, поскольку планировщик будет ожидать завершения уже запущенных запросов.
When net_msg_max
is reached,
Tarantool suspends processing of incoming packages until it
has processed earlier messages. This is not a direct restriction of
the number of fibers that handle network messages, rather it
is a system-wide restriction of channel bandwidth.
This in turn causes restriction of the number of incoming
network messages that the
transaction processor thread
handles, and therefore indirectly affects the fibers that handle
network messages.
(The number of fibers is smaller than the number of messages because
messages can be released as soon as they are delivered, while
incoming requests might not be processed until some time after delivery.)
Для стандартных систем подойдет значение, используемое по умолчанию (768).
Тип: целое число
По умолчанию: 768
Environment variable: TT_NET_MSG_MAX
Динамический: да
-
readahead
¶
Since version 1.6.2.
The size of the read-ahead buffer associated with a client connection. The
larger the buffer, the more memory an active connection consumes and the
more requests can be read from the operating system buffer in a single
system call. The rule of thumb is to make sure the buffer can contain at
least a few dozen requests. Therefore, if a typical tuple in a request is
large, e.g. a few kilobytes or even megabytes, the read-ahead buffer size
should be increased. If batched request processing is not used, it’s prudent
to leave this setting at its default.
Тип: целое число
По умолчанию: 16320
Environment variable: TT_READAHEAD
Динамический: да
-
iproto_threads
¶
Since version 2.8.1.
The number of network threads.
There can be unusual workloads where the network thread
is 100% loaded and the transaction processor thread is not, so the network
thread is a bottleneck. In that case set iproto_threads
to 2 or more.
The operating system kernel will determine which connection goes to
which thread.
On typical systems, the default value (1) is correct.
Тип: целое число
По умолчанию: 1
Environment variable: TT_IPROTO_THREADS
Динамический: нет
Запись в журнал
This section provides information on how to configure options related to logging.
You can also use the log module to configure logging in your
application.
-
log_level
¶
Since version 1.6.2.
Specify the level of detail the log has. There are the following levels:
- 0 –
fatal
- 1 –
syserror
- 2 –
error
- 3 –
crit
- 4 –
warn
- 5 –
info
- 6 –
verbose
- 7 –
debug
By setting log_level
, you can enable logging of all events with severities above
or equal to the given level. Tarantool prints logs to the standard
error stream by default. This can be changed with the
log configuration parameter.
Type: integer, string
По умолчанию: 5
Environment variable: TT_LOG_LEVEL
Динамический: да
Примечание
Prior to Tarantool 1.7.5 there were only six levels and DEBUG
was
level 6. Starting with Tarantool 1.7.5, VERBOSE
is level 6 and DEBUG
is level 7.
VERBOSE
is a new level for monitoring repetitive events which would cause
too much log writing if INFO
were used instead.
-
log
¶
Since version 1.7.4.
By default, Tarantool sends the log to the standard error stream
(stderr
). If log
is specified, Tarantool can send the log to a:
- file
- pipe
- system logger
Example 1: sending the log to the tarantool.log
file.
box.cfg{log = 'tarantool.log'}
-- или
box.cfg{log = 'file:tarantool.log'}
This opens the file tarantool.log
for output on the server’s default
directory. If the log
string has no prefix or has the prefix «file:»,
then the string is interpreted as a file path.
Example 2: sending the log to a pipe.
box.cfg{log = '| cronolog tarantool.log'}
-- or
box.cfg{log = 'pipe: cronolog tarantool.log'}
This starts the program cronolog when the server starts, and
sends all log messages to the standard input (stdin
) of cronolog
.
If the log
string begins with „|“ or has the prefix «pipe:»,
then the string is interpreted as a Unix
pipeline.
Example 3: sending the log to syslog.
box.cfg{log = 'syslog:identity=tarantool'}
-- или
box.cfg{log = 'syslog:facility=user'}
-- или
box.cfg{log = 'syslog:identity=tarantool,facility=user'}
-- или
box.cfg{log = 'syslog:server=unix:/dev/log'}
If the log
string begins with «syslog:», then it is
interpreted as a message for the
syslogd program, which normally
is running in the background on any Unix-like platform.
The setting can be syslog:
, syslog:facility=...
, syslog:identity=...
,
syslog:server=...
, or a combination.
- The
syslog:identity
setting is an arbitrary string, which is placed at
the beginning of all messages. The default value is «tarantool».
- В настоящий момент настройка
syslog:facility
не учитывается, но будет использоваться в дальнейшем. Ее значением должно быть одно из ключевых слов syslog, которые сообщают программе syslogd, куда отправлять сообщение. Возможные значения: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7. По умолчанию: user.
- The
syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path beginning with «unix:», or an ipv4 port number.
The default socket value is: dev/log
(on Linux) or /var/run/syslog
(on macOS).
The default port value is: 514, the UDP port.
When logging to a file, Tarantool reopens the log on SIGHUP.
When log is a program, its PID is saved in the log.pid
variable. You need to send it a signal to rotate logs.
Тип: строка
По умолчанию: null
Environment variable: TT_LOG
Динамический: нет
-
log_nonblock
¶
Since version 1.7.4.
If log_nonblock
equals true, Tarantool does not block during logging
when the system is not ready for writing, and drops the message
instead. If log_level is high, and many
messages go to the log, setting log_nonblock
to true may improve
logging performance at the cost of some log messages getting lost.
This parameter has effect only if log is
configured to send logs to a pipe or system logger.
The default log_nonblock
value is nil, which means that
blocking behavior corresponds to the logger type:
- false for
stderr
and file loggers.
- true for a pipe and system logger.
This is a behavior change: in earlier versions of the Tarantool
server, the default value was true.
Тип: логический
По умолчанию: nil
Environment variable: TT_LOG_NONBLOCK
Динамический: нет
-
too_long_threshold
¶
Since version 1.6.2.
If processing a request takes longer than the given value (in seconds),
warn about it in the log. Has effect only if log_level is greater than or equal to 4 (WARNING).
Тип: число с плавающей запятой
По умолчанию: 0.5
Environment variable: TT_TOO_LONG_THRESHOLD
Динамический: да
-
log_format
¶
Since version 1.7.6.
Log entries have two possible formats:
- „plain“ (по умолчанию) или
- „json“ (более детально с JSON-метками).
Here is what a log entry looks like if box.cfg{log_format='plain'}
:
2017-10-16 11:36:01.508 [18081] main/101/interactive I> set 'log_format' configuration option to "plain"
Here is what a log entry looks like if box.cfg{log_format='json'}
:
{"time": "2017-10-16T11:36:17.996-0600",
"level": "INFO",
"message": "set 'log_format' configuration option to \"json\"",
"pid": 18081,|
"cord_name": "main",
"fiber_id": 101,
"fiber_name": "interactive",
"file": "builtin\/box\/load_cfg.lua",
"line": 317}
The log_format='plain'
entry has a time value, process ID,
cord name, fiber_id,
fiber_name,
log level, and message.
The log_format='json'
entry has the same fields along with their labels,
and in addition has the file name and line number of the Tarantool source.
Тип: строка
По умолчанию: „plain“
Environment variable: TT_LOG_FORMAT
Динамический: да
-
log_modules
¶
Since version 2.11.0.
Configure the specified log levels (log_level) for different modules.
You can specify a logging level for the following module types:
- Modules (files) that use the default logger.
Example: Set log levels for files that use the default logger.
- Modules that use custom loggers created using the log.new() function.
Example: Set log levels for modules that use custom loggers.
- The
tarantool
module that enables you to configure the logging level for Tarantool core messages. Specifically, it configures the logging level for messages logged from non-Lua code, including C modules.
Example: Set a log level for C modules.
Type: table
Default: blank
Environment variable: TT_LOG_MODULES
Динамический: да
Example 1: Set log levels for files that use the default logger
Suppose you have two identical modules placed by the following paths: test/logging/module1.lua
and test/logging/module2.lua
.
These modules use the default logger and look as follows:
return {
say_hello = function()
local log = require('log')
log.info('Info message from module1')
end
}
To load these modules in your application, you need to add the corresponding require
directives:
module1 = require('test.logging.module1')
module2 = require('test.logging.module2')
To configure logging levels, you need to provide module names corresponding to paths to these modules.
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function:
box_cfg = { log_modules = {
['test.logging.module1'] = 'verbose',
['test.logging.module2'] = 'error' }
}
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1.say_hello()
shows a message but module2.say_hello()
is swallowed:
-- Prints 'info' messages --
module1.say_hello()
--[[
[92617] main/103/interactive/test.logging.module1 I> Info message from module1
---
...
--]]
-- Swallows 'info' messages --
module2.say_hello()
--[[
---
...
--]]
Example 2: Set log levels for modules that use custom loggers
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the verbose
level for module1
and the error
level for module2
:
box_cfg = { log_level = 'warn',
log_modules = {
module1 = 'verbose',
module2 = 'error' }
}
To create custom loggers, call the log.new() function:
-- Creates new loggers --
module1_log = require('log').new('module1')
module2_log = require('log').new('module2')
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1_log.info()
shows a message but module2_log.info()
is swallowed:
-- Prints 'info' messages --
module1_log.info('Info message from module1')
--[[
[16300] main/103/interactive/module1 I> Info message from module1
---
...
--]]
-- Swallows 'debug' messages --
module1_log.debug('Debug message from module1')
--[[
---
...
--]]
-- Swallows 'info' messages --
module2_log.info('Info message from module2')
--[[
---
...
--]]
Example 3: Set a log level for C modules
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the info
level for the tarantool
module:
box_cfg = { log_level = 'warn',
log_modules = { tarantool = 'info' } }
The specified level affects messages logged from C modules:
ffi = require('ffi')
-- Prints 'info' messages --
ffi.C._say(ffi.C.S_INFO, nil, 0, nil, 'Info message from C module')
--[[
[6024] main/103/interactive I> Info message from C module
---
...
--]]
-- Swallows 'debug' messages --
ffi.C._say(ffi.C.S_DEBUG, nil, 0, nil, 'Debug message from C module')
--[[
---
...
--]]
The example above uses the LuaJIT ffi library to call C functions provided by the say
module.
This example illustrates how «rotation» works, that is, what happens when the server
instance is writing to a log and signals are used when archiving it.
Start with two terminal shells: Terminal #1 and Terminal #2.
In Terminal #1, start an interactive Tarantool session.
Then, use the log
property to send logs to Log_file
and
call log.info
to put a message in the log file.
box.cfg{log='Log_file'}
log = require('log')
log.info('Log Line #1')
In Terminal #2, use the mv
command to rename the log file to Log_file.bak
.
mv Log_file Log_file.bak
As a result, the next log message will go to Log_file.bak
.
Go back to Terminal #1 and put a message «Log Line #2» in the log file.
log.info('Log Line #2')
In Terminal #2, use ps
to find the process ID of the Tarantool instance.
ps -A | grep tarantool
In Terminal #2, execute kill -HUP
to send a SIGHUP signal to the Tarantool instance.
Tarantool will open Log_file
again, and the next log message will go to Log_file
.
kill -HUP process_id
The same effect could be accomplished by calling log.rotate.
In Terminal #1, put a message «Log Line #3» in the log file.
log.info('Log Line #3')
In Terminal #2, use less
to examine files.
Log_file.bak
will have the following lines …
2015-11-30 15:13:06.373 [27469] main/101/interactive I> Log Line #1`
2015-11-30 15:14:25.973 [27469] main/101/interactive I> Log Line #2`
… and Log_file
will look like this:
log file has been reopened
2015-11-30 15:15:32.629 [27469] main/101/interactive I> Log Line #3
Audit log
Enterprise Edition
Audit log features are available in the Enterprise Edition only.
The audit_*
parameters define configuration related to audit logging.
-
audit_extract_key
¶
Since: 3.0.0.
If set to true
, the audit subsystem extracts and prints only the primary key instead of full
tuples in DML events (space_insert
, space_replace
, space_delete
).
Otherwise, full tuples are logged.
The option may be useful in case tuples are big.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_AUDIT_EXTRACT_KEY
-
audit_filter
¶
Enable logging for a specified subset of audit events.
This option accepts the following values:
- Event names (for example,
password_change
). For details, see Audit log events.
- Event groups (for example,
audit
). For details, see Event groups.
The option contains either one value from Possible values
section (see below) or a combination of them.
To enable custom audit log events, specify the custom
value in this option.
The default value is compatibility
, which enables logging of all events available before 2.10.0.
Example
box.cfg{
audit_log = 'audit.log',
audit_filter = 'audit,auth,priv,password_change,access_denied'
}
Type: array
Possible values: „all“, „audit“, „auth“, „priv“, „ddl“, „dml“, „data_operations“, „compatibility“,
„audit_enable“, „auth_ok“, „auth_fail“, „disconnect“, „user_create“, „user_drop“, „role_create“, „role_drop“,
„user_disable“, „user_enable“, „user_grant_rights“, „role_grant_rights“, „role_revoke_rights“, „password_change“,
„access_denied“, „eval“, „call“, „space_select“, „space_create“, „space_alter“, „space_drop“, „space_insert“,
„space_replace“, „space_delete“, „custom“
Default: „compatibility“
Environment variable: TT_AUDIT_FILTER
-
audit_format
¶
Specify the format that is used for the audit log events – plain text, CSV or JSON format.
Plain text is used by default. This human-readable format can be efficiently compressed.
box.cfg{audit_log = 'audit.log', audit_format = 'plain'}
Example
remote: session_type:background module:common.admin.auth user: type:custom_tdg_audit tag:tdg_severity_INFO description:[5e35b406-4274-4903-857b-c80115275940] subj: "anonymous", msg: "Access granted to anonymous user"
The JSON format is more convenient to receive log events, analyze them and integrate them with other systems if needed.
box.cfg{audit_log = 'audit.log', audit_format = 'json'}
Example
{"time": "2022-11-17T21:55:49.880+0300", "remote": "", "session_type": "background", "module": "common.admin.auth", "user": "", "type": "custom_tdg_audit", "tag": "tdg_severity_INFO", "description": "[c26cd11a-3342-4ce6-8f0b-a4b222268b9d] subj: \"anonymous\", msg: \"Access granted to anonymous user\""}
Using the CSV format allows you to view audit log events in tabular form.
box.cfg{audit_log = 'audit.log', audit_format = 'csv'}
Example
2022-11-17T21:58:03.131+0300,,background,common.admin.auth,,,custom_tdg_audit,tdg_severity_INFO,"[b3dfe2a3-ec29-4e61-b747-eb2332c83b2e] subj: ""anonymous"", msg: ""Access granted to anonymous user"""
Тип: строка
Possible values: „json“, „csv“, „plain“
Default: „json“
Environment variable: TT_AUDIT_FORMAT
-
audit_log
¶
Enable audit logging and define the log location.
This option accepts a string value that allows you to define the log location.
The following locations are supported:
- File: to write audit logs to a file, specify a path to a file (with an optional
file
prefix)
- Pipeline: to start a program and write audit logs to it, specify a program name (with
|
or pipe
prefix)
- System log: to write audit logs to a system log, specify a message for
syslogd
(with syslog
prefix)
See the examples below.
By default, audit logging is disabled.
Example: Writing to a file
box.cfg{audit_log = 'audit_tarantool.log'}
-- or
box.cfg{audit_log = 'file:audit_tarantool.log'}
This opens the audit_tarantool.log
file for output in the server’s default directory.
If the audit_log
string has no prefix or the prefix file:
, the string is interpreted as a file path.
If you log to a file, Tarantool will reopen the audit log at SIGHUP.
Example: Sending to a pipeline
box.cfg{audit_log = '| cronolog audit_tarantool.log'}
-- or
box.cfg{audit_log = 'pipe: cronolog audit_tarantool.log'}'
This starts the cronolog program when the server starts
and sends all audit_log
messages to cronolog’s standard input (stdin
).
If the audit_log
string starts with „|“ or contains the prefix pipe:
,
the string is interpreted as a Unix pipeline.
If log is a program, check out its pid and send it a signal to rotate logs.
Example: Writing to a system log
Предупреждение
Below is an example of writing audit logs to a directory shared with the system logs.
Tarantool allows this option, but it is not recommended to do this to avoid difficulties
when working with audit logs. System and audit logs should be written separately.
To do this, create separate paths and specify them.
This sample configuration sends the audit log to syslog:
box.cfg{audit_log = 'syslog:identity=tarantool'}
-- or
box.cfg{audit_log = 'syslog:facility=user'}
-- or
box.cfg{audit_log = 'syslog:identity=tarantool,facility=user'}
-- or
box.cfg{audit_log = 'syslog:server=unix:/dev/log'}
If the audit_log
string starts with «syslog:»,
it is interpreted as a message for the syslogd program,
which normally runs in the background of any Unix-like platform.
The setting can be „syslog:“, „syslog:facility=…“, „syslog:identity=…“, „syslog:server=…“ or a combination.
The syslog:identity
setting is an arbitrary string that is placed at the beginning of all messages.
The default value is tarantool
.
The syslog:facility
setting is currently ignored, but will be used in the future.
The value must be one of the syslog keywords
that tell syslogd
where to send the message.
The possible values are auth
, authpriv
, cron
, daemon
, ftp
,
kern
, lpr
, mail
, news
, security
, syslog
, user
, uucp
,
local0
, local1
, local2
, local3
, local4
, local5
, local6
, local7
.
The default value is local7
.
The syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path starting with «unix:» or an ipv4 port number.
The default socket value is /dev/log
(on Linux) or /var/run/syslog
(on Mac OS).
The default port value is 514, which is the UDP port.
An example of a Tarantool audit log entry in the syslog:
09:32:52 tarantool_audit: {"time": "2024-02-08T09:32:52.190+0300", "uuid": "94454e46-9a0e-493a-bb9f-d59e44a43581", "severity": "INFO", "remote": "unix/:(socket)", "session_type": "console", "module": "tarantool", "user": "admin", "type": "space_create", "tag": "", "description": "Create space bands"}
Тип: строка
Possible values: see the string format above
Default: „nill“
Environment variable: TT_AUDIT_LOG
-
audit_nonblock
¶
Specify the logging behavior if the system is not ready to write.
If set to true
, Tarantool does not block during logging if the system is non-writable and writes a message instead.
Using this value may improve logging performance at the cost of losing some log messages.
Примечание
The option only has an effect if the audit_log is set to syslog
or pipe
.
Setting audit_nonblock
to true
is not allowed if the output is to a file.
In this case, set audit_nonblock
to false
.
Тип: логический
По умолчанию: true
Environment variable: TT_AUDIT_NONBLOCK
-
audit_spaces
¶
Since: 3.0.0.
The array of space names for which data operation events (space_select
, space_insert
, space_replace
,
space_delete
) should be logged. The array accepts string values.
If set to box.NULL, the data operation events are logged for all spaces.
Example
In the example, only the events of bands
and singers
spaces are logged:
box.cfg{
audit_spaces = 'bands,singers'
}
Type: array
Default: box.NULL
Environment variable: TT_AUDIT_SPACES
Authentication
Enterprise Edition
Authentication features are supported by the Enterprise Edition only.
- auth_delay
- auth_retries
- auth_type
- disable_guest
- password_min_length
- password_enforce_uppercase
- password_enforce_lowercase
- password_enforce_digits
- password_enforce_specialchars
- password_lifetime_days
- password_history_length
-
auth_delay
¶
Since 2.11.0.
Specify a period of time (in seconds) that a specific user should wait
for the next attempt after failed authentication.
With the configuration below, Tarantool refuses the authentication attempt if the previous
attempt was less than 5 seconds ago.
box.cfg{ auth_delay = 5 }
Тип: число
Default: 0
Environment variable: TT_AUTH_DELAY
Динамический: да
-
auth_retries
¶
Since 3.0.0.
Specify the maximum number of authentication retries allowed before auth_delay
is enforced.
The default value is 0, which means auth_delay
is enforced after the first failed authentication attempt.
The retry counter is reset after auth_delay
seconds since the first failed attempt.
For example, if a client tries to authenticate fewer than auth_retries
times within auth_delay
seconds, no authentication delay is enforced.
The retry counter is also reset after any successful authentication attempt.
Тип: число
Default: 0
Environment variable: TT_AUTH_RETRIES
Динамический: да
-
auth_type
¶
Since 2.11.0.
Specify an authentication protocol:
- „chap-sha1“: use the CHAP protocol to authenticate users with
SHA-1
hashing applied to passwords.
- „pap-sha256“: use PAP authentication with the
SHA256
hashing algorithm.
For new users, the box.schema.user.create method
will generate authentication data using PAP-SHA256
.
For existing users, you need to reset a password using
box.schema.user.passwd
to use the new authentication protocol.
Тип: строка
Default value: „chap-sha1“
Environment variable: TT_AUTH_TYPE
Динамический: да
-
disable_guest
¶
Since 2.11.0.
If true, disables access over remote connections
from unauthenticated or guest access users.
This option affects both
net.box and
replication connections.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_DISABLE_GUEST
Динамический: да
-
password_min_length
¶
Since 2.11.0.
Specify the minimum number of characters for a password.
The following example shows how to set the minimum password length to 10.
box.cfg{ password_min_length = 10 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_MIN_LENGTH
Динамический: да
-
password_enforce_uppercase
¶
Since 2.11.0.
If true, a password should contain uppercase letters (A-Z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_UPPERCASE
Динамический: да
-
password_enforce_lowercase
¶
Since 2.11.0.
If true, a password should contain lowercase letters (a-z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_LOWERCASE
Динамический: да
-
password_enforce_digits
¶
Since 2.11.0.
If true, a password should contain digits (0-9).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_DIGITS
Динамический: да
-
password_enforce_specialchars
¶
Since 2.11.0.
If true, a password should contain at least one special character (such as &|?!@$
).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARS
Динамический: да
-
password_lifetime_days
¶
Since 2.11.0.
Specify the maximum period of time (in days) a user can use the same password.
When this period ends, a user gets the «Password expired» error on a login attempt.
To restore access for such users, use box.schema.user.passwd.
Примечание
The default 0 value means that a password never expires.
The example below shows how to set a maximum password age to 365 days.
box.cfg{ password_lifetime_days = 365 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_LIFETIME_DAYS
Динамический: да
-
password_history_length
¶
Since 2.11.0.
Specify the number of unique new user passwords before an old password can be reused.
In the example below, a new password should differ from the last three passwords.
box.cfg{ password_history_length = 3 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_HISTORY_LENGTH
Динамический: да
Примечание
Tarantool uses the auth_history
field in the
box.space._user
system space to store user passwords.
Flight recorder
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶
Since 2.11.0.
Enable the flight recorder.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FLIGHTREC_ENABLED
Динамический: да
-
flightrec_logs_size
¶
Since 2.11.0.
Specify the size (in bytes) of the log storage.
You can set this option to 0
to disable the log storage.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_LOGS_SIZE
Динамический: да
-
flightrec_logs_max_msg_size
¶
Since 2.11.0.
Specify the maximum size (in bytes) of the log message.
The log message is truncated if its size exceeds this limit.
Тип: целое число
Default: 4096
Maximum: 16384
Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZE
Динамический: да
-
flightrec_logs_log_level
¶
Since 2.11.0.
Specify the level of detail the log has.
You can learn more about log levels from the log_level
option description.
Note that the flightrec_logs_log_level
value might differ from log_level
.
Тип: целое число
Default: 6
Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVEL
Динамический: да
-
flightrec_metrics_period
¶
Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump.
So, this value defines how much historical metrics data is collected up to the moment of crash.
The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое число
Default: 180
Environment variable: TT_FLIGHTREC_METRICS_PERIOD
Динамический: да
-
flightrec_metrics_interval
¶
Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics.
This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB,
you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: число
По умолчанию: 1.0
Minimum: 0.001
Environment variable: TT_FLIGHTREC_METRICS_INTERVAL
Динамический: да
-
flightrec_requests_size
¶
Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data.
You can set this parameter to 0
to disable a storage of requests and responses.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_REQUESTS_SIZE
Динамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
-
hot_standby
¶ Since version 1.7.4.
Whether to start the server in hot standby mode.
Горячее резервирование – это функция, которая обеспечивает простое восстановление после отказа без репликации.
Предполагается, что есть два экземпляра сервера, использующих одну и ту же конфигурацию. Первый из них станет «основным» экземпляром. Тот, который запускается вторым, станет «резервным» экземпляром.
Чтобы создать резервный экземпляр, запустите второй экземпляр Tarantool-сервера на том же компьютере с теми же настройками конфигурации box.cfg – включая одинаковые директории и ненулевые URI – и с дополнительной настройкой конфигурации
hot_standby = true
. В ближайшее время вы увидите уведомление, которое заканчивается словамиI> Entering hot standby mode
(вход в режим горячего резервирования). Всё в порядке – это означает, что резервный экземпляр готов взять работу на себя, если основной экземпляр прекратит работу.Резервный экземпляр начнет инициализацию и попытается заблокировать wal_dir, но не сможет, поскольку директория
wal_dir
заблокирована основным экземпляром. Поэтому резервный экземпляр входит в цикл, выполняя чтение журнала упреждающей записи, в который записывает данные основной экземпляр (поэтому два экземпляра всегда синхронизированы), и пытаясь произвести блокировку. Если основной экземпляр по какой-либо причине прекращает работу, блокировка снимается. В таком случае резервный экземпляр сможет заблокировать директорию на себя, подключится по адресу для прослушивания и станет основным экземпляром. В ближайшее время вы увидите уведомление, которое заканчивается словамиI> ready to accept requests
(готов принимать запросы).Таким образом, если основной экземпляр прекращает работу, время простоя отсутствует.
Функция горячего резервирования не работает:
- если wal_dir_rescan_delay = большое число (в Mac OS и FreeBSD); на этих платформах цикл запрограммирован на повторение каждые
wal_dir_rescan_delay
секунд. - если wal_mode = „none“; будет работать только при
wal_mode = 'write'
илиwal_mode = 'fsync'
. - со спейсами, созданными на движке vinyl engine = „vinyl“; работает с движком memtx
engine = 'memtx'
.
Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_HOT_STANDBYДинамический: нет- если wal_dir_rescan_delay = большое число (в Mac OS и FreeBSD); на этих платформах цикл запрограммирован на повторение каждые
Репликация
- 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
-
replication
¶
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
Если в наборе реплик более одного источника репликации, укажите массив URI, например (замените „uri“ и „uri2“ в данном примере на рабочие URI):
box.cfg{ replication = { 'uri1', 'uri2' } }
Примечание
Starting from version 2.10.0, there is a number of other ways for specifying several URIs. See syntax examples.
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.
По умолчанию, пользователем считается „guest“.
Реплика в режиме только для чтения не принимает запросы по изменению данных по порту для прослушивания.
Параметр replication
является динамическим, то есть для входа в режим мастера необходимо просто присвоить параметру replication
пустую строку и выполнить следующее:
box.cfg{ replication = новое-значение }
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICATION
Динамический: да
-
replication_anon
¶
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.
Так как анонимная реплика не зарегистрирована в таблице _cluster
, нет никаких ограничений для количества анонимных реплик в наборе: можно создавать их сколько угодно.
Чтобы сделать реплику анонимной, передайте опцию replication_anon=true
в box.cfg
и установите значение read_only
равным true
.
Попробуем создать анонимную реплику. Предположим, что у нас есть мастер с такой настройкой:
box.cfg{listen=3301}
и создан локальный спейс «loc»:
box.schema.space.create('loc', {is_local=true})
box.space.loc:create_index("pk")
Теперь, чтобы настроить анонимную реплику, нам нужно обратиться к box.cfg
, как обычно.
box.cfg{replication_anon=true, read_only=true, replication=3301}
Как было сказано выше, replication_anon
может быть true
только вместе с read_only
. Этот экземпляр получит снимок мастера и начнет следить за его изменениями. Он не получит id, поэтому его значение останется нулевым.
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
...
Теперь можно использовать реплику. Например, можно сделать вставку в локальный спейс:
tarantool> for i = 1,10 do
> box.space.loc:insert{i}
> end
---
...
Заметьте, что пока экземпляр анонимный, увеличится нулевая компонента его vclock
:
tarantool> box.info.vclock
---
- {0: 10, 1: 4}
...
А теперь давайте сделаем анонимную реплику снова обычной:
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-51a46def7661
2019-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> subscribed
2019-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
Эта реплика получила id равный 2. Мы можем снова сделать ее открытой на запись:
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: memtx
before_replace: 'function: 0x01109f9dc8'
on_replace: 'function: 0x01109f9d90'
ck_constraint: []
field_count: 0
temporary: false
index: []
is_local: false
enabled: false
name: test
id: 513
- created
...
tarantool> box.info.vclock
---
- {0: 10, 1: 5, 2: 2}
...
Теперь, как и ожидалось, реплика отслеживает свои изменения во 2-й компоненте vclock. С этого момента она также может стать мастером репликации.
Замечания:
- Нельзя реплицироваться от анонимной реплики.
- Чтобы вернуть анонимный экземпляр к обычному состоянию, сначала запустите его как анонимный, а потом вызовите
box.cfg{replication_anon=false}
- Чтобы деанонимизация прошла успешно, экземпляр должен быть скопирован с какого-то экземпляра, открытого на запись, иначе он не может быть добавлен в таблицу
_cluster
.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_ANON
Динамический: да
-
bootstrap_leader
¶
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'},
}
Тип: строка
По умолчанию: null
Environment variable: TT_BOOTSTRAP_LEADER
Динамический: да
-
bootstrap_strategy
¶
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.
Тип: строка
Default: auto
Environment variable: TT_BOOTSTRAP_STRATEGY
Динамический: да
-
replication_connect_timeout
¶
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.
Тип: число с плавающей запятой
По умолчанию: 30
Environment variable: TT_REPLICATION_CONNECT_TIMEOUT
Динамический: да
-
replication_connect_quorum
¶
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.
Пример:
box.cfg { replication_connect_quorum = 2 }
Тип: целое число
По умолчанию: null
Environment variable: TT_REPLICATION_CONNECT_QUORUM
Динамический: да
-
replication_skip_conflict
¶
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.
Однако если указать replication_skip_conflict = true
, пользователи могут задать пропуск таких ошибок. Так, вместо сохранения сломанной транзакции в xlog, там будет записано NOP
(No operation).
Пример:
box.cfg{replication_skip_conflict=true}
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_REPLICATION_SKIP_CONFLICT
Динамический: да
Примечание
replication_skip_conflict = true
рекомендуется использовать только для ручного восстановления репликации.
-
replication_sync_lag
¶
Since version 1.9.0.
The maximum lag allowed for a replica.
When a replica syncs
(gets updates from a master), it may not catch up completely.
The number of seconds that the replica is behind the master is called the «lag».
Syncing is considered to be complete when the replica’s lag is less than
or equal to replication_sync_lag
.
Если пользователь задает значение replication_sync_lag
, равное nil или 365 * 100 * 86400 (TIMEOUT_INFINITY), то отставание не имеет значения – реплика всегда будет синхронизирована. Кроме того, отставание не учитывается (считается бесконечным), если мастер работает на версии Tarantool старше 1.7.7, которая не отправляет сообщения контрольного сигнала.
Этот параметр не учитывается во время настройки. Для получения подробной информации, см. статус orphan.
Тип: число с плавающей запятой
По умолчанию: 10
Environment variable: TT_REPLICATION_SYNC_LAG
Динамический: да
-
replication_sync_timeout
¶
Since version 1.10.2.
The number of seconds that a node waits when trying to sync with
other nodes in a replica set (see bootstrap_strategy),
after connecting or during configuration update.
This could fail indefinitely if replication_sync_lag
is smaller
than network latency, or if the replica cannot keep pace with master
updates. If replication_sync_timeout
expires, the replica
enters orphan status.
Тип: число с плавающей запятой
По умолчанию: 300
Environment variable: TT_REPLICATION_SYNC_TIMEOUT
Динамический: да
Примечание
The default replication_sync_timeout
value is going to be changed in future versions from 300
to 0
.
You can learn the reasoning behind this decision from the Default value for replication_sync_timeout topic, which also describes how to try the new behavior in the current version.
-
replication_timeout
¶
Since version 1.7.5.
If the master has no updates to send to the replicas, it sends heartbeat messages
every replication_timeout
seconds, and each replica sends an ACK packet back.
И мастер, и реплики запрограммированы разорвать соединение при отсутствии сообщений в течение четырех промежутков времени, указанного в параметре replication_timeout
. После разрыва соединения реплика пытается снова подключиться к мастеру.
См. дополнительную информацию в разделе Мониторинг набора реплик.
Тип: целое число
По умолчанию: 1
Environment variable: TT_REPLICATION_TIMEOUT
Динамический: да
-
replicaset_uuid
¶
Since version 1.9.0.
As described in section
«Replication architecture»,
each replica set is identified by a
universally unique identifier
called replica set UUID, and each instance is identified by an
instance UUID.
Как правило, достаточно позволить системе сгенерировать и форматировать строки, содержащие UUID, которые будут храниться постоянно.
Однако, некоторые администраторы предпочитают сохранять конфигурацию Tarantool в центральном репозитории, например, Apache ZooKeeper. Они могут самостоятельно присвоить значения экземплярам (instance_uuid) и набору реплик (replicaset_uuid
) при первом запуске.
Общие правила:
- Значения должны быть действительно уникальными; они не должны одновременно принадлежать другим экземплярам или наборам реплик в той же инфраструктуре.
- Значения должны использоваться постоянно, неизменно с первого запуска (первоначальные значения хранятся в файлах снимков и проверяются при каждом перезапуске системы).
- Значения должны соответствовать требованиям RFC 4122. Нулевой UUID не допускается.
Формат UUID включает в себя шестнадцать октетов, представленных в виде 32 шестнадцатеричных чисел (с основанием 16) в пяти группах, разделенных дефисами в форме 8-4-4-4-12
– 36 символов (32 буквенно-цифровых символа и четыре дефиса).
Пример:
box.cfg{replicaset_uuid='7b853d13-508b-4b8e-82e6-806f088ea6e9'}
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_UUID
Динамический: нет
-
instance_uuid
¶
Since version 1.9.0.
For replication administration purposes, it is possible to set the
universally unique identifiers
of the instance (instance_uuid
) and the replica set
(replicaset_uuid
), instead of having the system generate the values.
Для получения подробной информации см. описание параметра replicaset_uuid.
Пример:
box.cfg{instance_uuid='037fec43-18a9-4e12-a684-a42b716fcd02'}
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_UUID
Динамический: нет
-
replication_synchro_quorum
¶
Since version 2.5.1.
For synchronous replication only.
This option tells how many replicas should confirm the receipt of a
synchronous transaction before it can finish its commit.
Since version 2.5.3,
the option supports dynamic evaluation of the quorum number.
That is, the number of quorum can be specified not as a constant number, but as a function instead.
In this case, the option returns the formula evaluated.
The result is treated as an integer number.
Once any replicas are added or removed, the expression is re-evaluated automatically.
For example,
box.cfg{replication_synchro_quorum = "N / 2 + 1"}
Where N
is a current number of registered replicas in a cluster.
Keep in mind that the example above represents a canonical quorum definition.
The formula at least 50% of the cluster size + 1
guarantees data reliability.
Using a value less than the canonical one might lead to unexpected results,
including a split-brain.
Since version 2.10.0, this option
does not account for anonymous replicas.
По умолчанию значение параметра равно N / 2 + 1
.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Если значение параметра равно 1
, синхронные транзакции работают как асинхронные, пока они не настроены. 1
означает, что для коммита достаточно успешной записи в WAL на мастере.
Тип: число
Default: N / 2 + 1 (before version 2.10.0, the default value was 1)
Environment variable: TT_REPLICATION_SYNCHRO_QUORUM
Динамический: да
-
replication_synchro_timeout
¶
Since version 2.5.1.
For synchronous replication only.
Tells how many seconds to wait for a synchronous transaction quorum
replication until it is declared failed and is rolled back.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Тип: число
По умолчанию: 5
Environment variable: TT_REPLICATION_SYNCHRO_TIMEOUT
Динамический: да
-
replication_threads
¶
Since version 2.10.0.
The number of threads spawned to decode the incoming replication data.
The default value is 1
.
It means that a single separate thread handles all the incoming replication streams.
In most cases, one thread is enough for all incoming data.
Therefore, it is likely that the user will not need to set this configuration option.
Possible values range from 1 to 1000.
If there are multiple replication threads, connections to serve are distributed evenly between the threads.
Тип: число
По умолчанию: 1
Possible values: from 1 to 1000
Environment variable: TT_REPLICATION_THREADS
Dynamic: no
-
election_mode
¶
Since version 2.6.1.
Specify the role of a replica set node in the
leader election process.
Possible values:
- off
- voter
- candidate
- manual.
Participation of a replica set node in the automated leader election can be
turned on and off by this option.
The default value is off
. All nodes that have values other than off
run the Raft state machine internally talking to other nodes according
to the Raft leader election protocol. When the option is off
, the node
accepts Raft messages
from other nodes, but it doesn’t participate in the election activities,
and this doesn’t affect the node’s state. So, for example, if a node is not
a leader but it has election_mode = 'off'
, it is writable anyway.
You can control which nodes can become a leader. If you want a node
to participate in the election process but don’t want that it becomes
a leaders, set the election_mode
option to voter
. In this case,
the election works as usual, this particular node will vote for other nodes,
but won’t become a leader.
If the node should be able to become a leader, use election_mode = 'candidate'
.
Since version 2.8.2, the manual election mode is introduced.
It may be used when a user wants to control which instance is the leader explicitly instead of relying on
the Raft election algorithm.
When an instance is configured with the election_mode='manual'
, it behaves as follows:
- By default, the instance acts like a voter – it is read-only and may vote for other instances that are candidates.
- Once box.ctl.promote() is called, the instance becomes a candidate and starts a new election round.
If the instance wins the elections, it becomes a leader, but won’t participate in any new elections.
Тип: строка
Default: „off“
Environment variable: TT_ELECTION_MODE
Динамический: да
-
election_timeout
¶
Since version 2.6.1.
Specify the timeout between election rounds in the
leader election process if the previous round
ended up with a split-vote.
In the leader election process, there
can be an election timeout for the case of a split-vote.
The timeout can be configured using this option; the default value is
5 seconds.
It is quite big, and for most of the cases it can be freely lowered to
300-400 ms. It can be a floating point value (300 ms would be
box.cfg{election_timeout = 0.3}
).
To avoid the split vote repeat, the timeout is randomized on each node
during every new election, from 100% to 110% of the original timeout value.
For example, if the timeout is 300 ms and there are 3 nodes started
the election simultaneously in the same term,
they can set their election timeouts to 300, 310, and 320 respectively,
or to 305, 302, and 324, and so on. In that way, the votes will never be split
because the election on different nodes won’t be restarted simultaneously.
Тип: число
По умолчанию: 5
Environment variable: TT_ELECTION_TIMEOUT
Динамический: да
-
election_fencing_mode
¶
Since version 2.11.0.
In earlier Tarantool versions, use election_fencing_enabled instead.
Specify the leader fencing mode that
affects the leader election process. When the parameter is set to soft
or strict
, the leader resigns its leadership if it has less than
replication_synchro_quorum
of alive connections to the cluster nodes.
The resigning leader receives the status of a
follower in the current election term and becomes
read-only.
- In
soft
mode, a connection is considered dead if there are no responses for
4*replication_timeout seconds both on the current leader and the followers.
- In
strict
mode, a connection is considered dead if there are no responses
for 2*replication_timeout seconds on the
current leader and
4*replication_timeout seconds on the
followers. This improves chances that there is only one leader at any time.
Fencing applies to the instances that have the
election_mode set to candidate
or manual
.
To turn off leader fencing, set election_fencing_mode
to off
.
Тип: строка
Default: „soft“
Environment variable: TT_ELECTION_FENCING_MODE
Динамический: да
-
instance_name
¶
Since version 3.0.0.
Specify the instance name.
This value must be unique in a replica set.
The following rules are applied to instance names:
- The maximum number of symbols is 63.
- Should start with a letter.
- Can contain lowercase letters (a-z). If uppercase letters are used, they are converted to lowercase.
- Can contain digits (0-9).
- Can contain the following characters:
-
, _
.
To change or remove the specified name, you should temporarily set the box.cfg.force_recovery configuration option to true
.
When all the names are updated and all the instances synced, box.cfg.force_recovery
can be set back to false
.
Примечание
The instance name is persisted in the box.space._cluster system space.
See also: box.info.name
Тип: строка
По умолчанию: null
Environment variable: TT_INSTANCE_NAME
Динамический: нет
-
replicaset_name
¶
Since version 3.0.0.
Specify the name of a replica set to which this instance belongs.
This value must be the same for all instances of the replica set.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The replica set name is persisted in the box.space._schema system space.
See also: box.info.replicaset
Тип: строка
По умолчанию: null
Environment variable: TT_REPLICASET_NAME
Динамический: нет
-
cluster_name
¶
Since version 3.0.0.
Specify the name of a cluster to which this instance belongs.
This value must be the same for all instances of the cluster.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The cluster name is persisted in the box.space._schema system space.
See also: box.info.cluster
Тип: строка
По умолчанию: null
Environment variable: TT_CLUSTER_NAME
Динамический: нет
Работа с сетями
-
io_collect_interval
¶
Since version 1.4.9.
The instance will sleep for io_collect_interval seconds between iterations
of the event loop. Can be used to reduce CPU load in deployments in which
the number of client connections is large, but requests are not so frequent
(for example, each connection issues just a handful of requests per second).
Тип: число с плавающей запятой
По умолчанию: null
Environment variable: TT_IO_COLLECT_INTERVAL
Динамический: да
-
net_msg_max
¶
Since version 1.10.1.
To handle messages, Tarantool allocates fibers.
To prevent fiber overhead from affecting the whole system,
Tarantool restricts how many messages the fibers handle,
so that some pending requests are blocked.
В мощных системах увеличьте значение net_msg_max
, и планировщик немедленно приступит к обработке отложенных запросов.
В более слабых системах уменьшите значение net_msg_max
, чтобы снизить загрузку, хотя это и займет некоторое время, поскольку планировщик будет ожидать завершения уже запущенных запросов.
When net_msg_max
is reached,
Tarantool suspends processing of incoming packages until it
has processed earlier messages. This is not a direct restriction of
the number of fibers that handle network messages, rather it
is a system-wide restriction of channel bandwidth.
This in turn causes restriction of the number of incoming
network messages that the
transaction processor thread
handles, and therefore indirectly affects the fibers that handle
network messages.
(The number of fibers is smaller than the number of messages because
messages can be released as soon as they are delivered, while
incoming requests might not be processed until some time after delivery.)
Для стандартных систем подойдет значение, используемое по умолчанию (768).
Тип: целое число
По умолчанию: 768
Environment variable: TT_NET_MSG_MAX
Динамический: да
-
readahead
¶
Since version 1.6.2.
The size of the read-ahead buffer associated with a client connection. The
larger the buffer, the more memory an active connection consumes and the
more requests can be read from the operating system buffer in a single
system call. The rule of thumb is to make sure the buffer can contain at
least a few dozen requests. Therefore, if a typical tuple in a request is
large, e.g. a few kilobytes or even megabytes, the read-ahead buffer size
should be increased. If batched request processing is not used, it’s prudent
to leave this setting at its default.
Тип: целое число
По умолчанию: 16320
Environment variable: TT_READAHEAD
Динамический: да
-
iproto_threads
¶
Since version 2.8.1.
The number of network threads.
There can be unusual workloads where the network thread
is 100% loaded and the transaction processor thread is not, so the network
thread is a bottleneck. In that case set iproto_threads
to 2 or more.
The operating system kernel will determine which connection goes to
which thread.
On typical systems, the default value (1) is correct.
Тип: целое число
По умолчанию: 1
Environment variable: TT_IPROTO_THREADS
Динамический: нет
Запись в журнал
This section provides information on how to configure options related to logging.
You can also use the log module to configure logging in your
application.
-
log_level
¶
Since version 1.6.2.
Specify the level of detail the log has. There are the following levels:
- 0 –
fatal
- 1 –
syserror
- 2 –
error
- 3 –
crit
- 4 –
warn
- 5 –
info
- 6 –
verbose
- 7 –
debug
By setting log_level
, you can enable logging of all events with severities above
or equal to the given level. Tarantool prints logs to the standard
error stream by default. This can be changed with the
log configuration parameter.
Type: integer, string
По умолчанию: 5
Environment variable: TT_LOG_LEVEL
Динамический: да
Примечание
Prior to Tarantool 1.7.5 there were only six levels and DEBUG
was
level 6. Starting with Tarantool 1.7.5, VERBOSE
is level 6 and DEBUG
is level 7.
VERBOSE
is a new level for monitoring repetitive events which would cause
too much log writing if INFO
were used instead.
-
log
¶
Since version 1.7.4.
By default, Tarantool sends the log to the standard error stream
(stderr
). If log
is specified, Tarantool can send the log to a:
- file
- pipe
- system logger
Example 1: sending the log to the tarantool.log
file.
box.cfg{log = 'tarantool.log'}
-- или
box.cfg{log = 'file:tarantool.log'}
This opens the file tarantool.log
for output on the server’s default
directory. If the log
string has no prefix or has the prefix «file:»,
then the string is interpreted as a file path.
Example 2: sending the log to a pipe.
box.cfg{log = '| cronolog tarantool.log'}
-- or
box.cfg{log = 'pipe: cronolog tarantool.log'}
This starts the program cronolog when the server starts, and
sends all log messages to the standard input (stdin
) of cronolog
.
If the log
string begins with „|“ or has the prefix «pipe:»,
then the string is interpreted as a Unix
pipeline.
Example 3: sending the log to syslog.
box.cfg{log = 'syslog:identity=tarantool'}
-- или
box.cfg{log = 'syslog:facility=user'}
-- или
box.cfg{log = 'syslog:identity=tarantool,facility=user'}
-- или
box.cfg{log = 'syslog:server=unix:/dev/log'}
If the log
string begins with «syslog:», then it is
interpreted as a message for the
syslogd program, which normally
is running in the background on any Unix-like platform.
The setting can be syslog:
, syslog:facility=...
, syslog:identity=...
,
syslog:server=...
, or a combination.
- The
syslog:identity
setting is an arbitrary string, which is placed at
the beginning of all messages. The default value is «tarantool».
- В настоящий момент настройка
syslog:facility
не учитывается, но будет использоваться в дальнейшем. Ее значением должно быть одно из ключевых слов syslog, которые сообщают программе syslogd, куда отправлять сообщение. Возможные значения: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7. По умолчанию: user.
- The
syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path beginning with «unix:», or an ipv4 port number.
The default socket value is: dev/log
(on Linux) or /var/run/syslog
(on macOS).
The default port value is: 514, the UDP port.
When logging to a file, Tarantool reopens the log on SIGHUP.
When log is a program, its PID is saved in the log.pid
variable. You need to send it a signal to rotate logs.
Тип: строка
По умолчанию: null
Environment variable: TT_LOG
Динамический: нет
-
log_nonblock
¶
Since version 1.7.4.
If log_nonblock
equals true, Tarantool does not block during logging
when the system is not ready for writing, and drops the message
instead. If log_level is high, and many
messages go to the log, setting log_nonblock
to true may improve
logging performance at the cost of some log messages getting lost.
This parameter has effect only if log is
configured to send logs to a pipe or system logger.
The default log_nonblock
value is nil, which means that
blocking behavior corresponds to the logger type:
- false for
stderr
and file loggers.
- true for a pipe and system logger.
This is a behavior change: in earlier versions of the Tarantool
server, the default value was true.
Тип: логический
По умолчанию: nil
Environment variable: TT_LOG_NONBLOCK
Динамический: нет
-
too_long_threshold
¶
Since version 1.6.2.
If processing a request takes longer than the given value (in seconds),
warn about it in the log. Has effect only if log_level is greater than or equal to 4 (WARNING).
Тип: число с плавающей запятой
По умолчанию: 0.5
Environment variable: TT_TOO_LONG_THRESHOLD
Динамический: да
-
log_format
¶
Since version 1.7.6.
Log entries have two possible formats:
- „plain“ (по умолчанию) или
- „json“ (более детально с JSON-метками).
Here is what a log entry looks like if box.cfg{log_format='plain'}
:
2017-10-16 11:36:01.508 [18081] main/101/interactive I> set 'log_format' configuration option to "plain"
Here is what a log entry looks like if box.cfg{log_format='json'}
:
{"time": "2017-10-16T11:36:17.996-0600",
"level": "INFO",
"message": "set 'log_format' configuration option to \"json\"",
"pid": 18081,|
"cord_name": "main",
"fiber_id": 101,
"fiber_name": "interactive",
"file": "builtin\/box\/load_cfg.lua",
"line": 317}
The log_format='plain'
entry has a time value, process ID,
cord name, fiber_id,
fiber_name,
log level, and message.
The log_format='json'
entry has the same fields along with their labels,
and in addition has the file name and line number of the Tarantool source.
Тип: строка
По умолчанию: „plain“
Environment variable: TT_LOG_FORMAT
Динамический: да
-
log_modules
¶
Since version 2.11.0.
Configure the specified log levels (log_level) for different modules.
You can specify a logging level for the following module types:
- Modules (files) that use the default logger.
Example: Set log levels for files that use the default logger.
- Modules that use custom loggers created using the log.new() function.
Example: Set log levels for modules that use custom loggers.
- The
tarantool
module that enables you to configure the logging level for Tarantool core messages. Specifically, it configures the logging level for messages logged from non-Lua code, including C modules.
Example: Set a log level for C modules.
Type: table
Default: blank
Environment variable: TT_LOG_MODULES
Динамический: да
Example 1: Set log levels for files that use the default logger
Suppose you have two identical modules placed by the following paths: test/logging/module1.lua
and test/logging/module2.lua
.
These modules use the default logger and look as follows:
return {
say_hello = function()
local log = require('log')
log.info('Info message from module1')
end
}
To load these modules in your application, you need to add the corresponding require
directives:
module1 = require('test.logging.module1')
module2 = require('test.logging.module2')
To configure logging levels, you need to provide module names corresponding to paths to these modules.
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function:
box_cfg = { log_modules = {
['test.logging.module1'] = 'verbose',
['test.logging.module2'] = 'error' }
}
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1.say_hello()
shows a message but module2.say_hello()
is swallowed:
-- Prints 'info' messages --
module1.say_hello()
--[[
[92617] main/103/interactive/test.logging.module1 I> Info message from module1
---
...
--]]
-- Swallows 'info' messages --
module2.say_hello()
--[[
---
...
--]]
Example 2: Set log levels for modules that use custom loggers
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the verbose
level for module1
and the error
level for module2
:
box_cfg = { log_level = 'warn',
log_modules = {
module1 = 'verbose',
module2 = 'error' }
}
To create custom loggers, call the log.new() function:
-- Creates new loggers --
module1_log = require('log').new('module1')
module2_log = require('log').new('module2')
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1_log.info()
shows a message but module2_log.info()
is swallowed:
-- Prints 'info' messages --
module1_log.info('Info message from module1')
--[[
[16300] main/103/interactive/module1 I> Info message from module1
---
...
--]]
-- Swallows 'debug' messages --
module1_log.debug('Debug message from module1')
--[[
---
...
--]]
-- Swallows 'info' messages --
module2_log.info('Info message from module2')
--[[
---
...
--]]
Example 3: Set a log level for C modules
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the info
level for the tarantool
module:
box_cfg = { log_level = 'warn',
log_modules = { tarantool = 'info' } }
The specified level affects messages logged from C modules:
ffi = require('ffi')
-- Prints 'info' messages --
ffi.C._say(ffi.C.S_INFO, nil, 0, nil, 'Info message from C module')
--[[
[6024] main/103/interactive I> Info message from C module
---
...
--]]
-- Swallows 'debug' messages --
ffi.C._say(ffi.C.S_DEBUG, nil, 0, nil, 'Debug message from C module')
--[[
---
...
--]]
The example above uses the LuaJIT ffi library to call C functions provided by the say
module.
This example illustrates how «rotation» works, that is, what happens when the server
instance is writing to a log and signals are used when archiving it.
Start with two terminal shells: Terminal #1 and Terminal #2.
In Terminal #1, start an interactive Tarantool session.
Then, use the log
property to send logs to Log_file
and
call log.info
to put a message in the log file.
box.cfg{log='Log_file'}
log = require('log')
log.info('Log Line #1')
In Terminal #2, use the mv
command to rename the log file to Log_file.bak
.
mv Log_file Log_file.bak
As a result, the next log message will go to Log_file.bak
.
Go back to Terminal #1 and put a message «Log Line #2» in the log file.
log.info('Log Line #2')
In Terminal #2, use ps
to find the process ID of the Tarantool instance.
ps -A | grep tarantool
In Terminal #2, execute kill -HUP
to send a SIGHUP signal to the Tarantool instance.
Tarantool will open Log_file
again, and the next log message will go to Log_file
.
kill -HUP process_id
The same effect could be accomplished by calling log.rotate.
In Terminal #1, put a message «Log Line #3» in the log file.
log.info('Log Line #3')
In Terminal #2, use less
to examine files.
Log_file.bak
will have the following lines …
2015-11-30 15:13:06.373 [27469] main/101/interactive I> Log Line #1`
2015-11-30 15:14:25.973 [27469] main/101/interactive I> Log Line #2`
… and Log_file
will look like this:
log file has been reopened
2015-11-30 15:15:32.629 [27469] main/101/interactive I> Log Line #3
Audit log
Enterprise Edition
Audit log features are available in the Enterprise Edition only.
The audit_*
parameters define configuration related to audit logging.
-
audit_extract_key
¶
Since: 3.0.0.
If set to true
, the audit subsystem extracts and prints only the primary key instead of full
tuples in DML events (space_insert
, space_replace
, space_delete
).
Otherwise, full tuples are logged.
The option may be useful in case tuples are big.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_AUDIT_EXTRACT_KEY
-
audit_filter
¶
Enable logging for a specified subset of audit events.
This option accepts the following values:
- Event names (for example,
password_change
). For details, see Audit log events.
- Event groups (for example,
audit
). For details, see Event groups.
The option contains either one value from Possible values
section (see below) or a combination of them.
To enable custom audit log events, specify the custom
value in this option.
The default value is compatibility
, which enables logging of all events available before 2.10.0.
Example
box.cfg{
audit_log = 'audit.log',
audit_filter = 'audit,auth,priv,password_change,access_denied'
}
Type: array
Possible values: „all“, „audit“, „auth“, „priv“, „ddl“, „dml“, „data_operations“, „compatibility“,
„audit_enable“, „auth_ok“, „auth_fail“, „disconnect“, „user_create“, „user_drop“, „role_create“, „role_drop“,
„user_disable“, „user_enable“, „user_grant_rights“, „role_grant_rights“, „role_revoke_rights“, „password_change“,
„access_denied“, „eval“, „call“, „space_select“, „space_create“, „space_alter“, „space_drop“, „space_insert“,
„space_replace“, „space_delete“, „custom“
Default: „compatibility“
Environment variable: TT_AUDIT_FILTER
-
audit_format
¶
Specify the format that is used for the audit log events – plain text, CSV or JSON format.
Plain text is used by default. This human-readable format can be efficiently compressed.
box.cfg{audit_log = 'audit.log', audit_format = 'plain'}
Example
remote: session_type:background module:common.admin.auth user: type:custom_tdg_audit tag:tdg_severity_INFO description:[5e35b406-4274-4903-857b-c80115275940] subj: "anonymous", msg: "Access granted to anonymous user"
The JSON format is more convenient to receive log events, analyze them and integrate them with other systems if needed.
box.cfg{audit_log = 'audit.log', audit_format = 'json'}
Example
{"time": "2022-11-17T21:55:49.880+0300", "remote": "", "session_type": "background", "module": "common.admin.auth", "user": "", "type": "custom_tdg_audit", "tag": "tdg_severity_INFO", "description": "[c26cd11a-3342-4ce6-8f0b-a4b222268b9d] subj: \"anonymous\", msg: \"Access granted to anonymous user\""}
Using the CSV format allows you to view audit log events in tabular form.
box.cfg{audit_log = 'audit.log', audit_format = 'csv'}
Example
2022-11-17T21:58:03.131+0300,,background,common.admin.auth,,,custom_tdg_audit,tdg_severity_INFO,"[b3dfe2a3-ec29-4e61-b747-eb2332c83b2e] subj: ""anonymous"", msg: ""Access granted to anonymous user"""
Тип: строка
Possible values: „json“, „csv“, „plain“
Default: „json“
Environment variable: TT_AUDIT_FORMAT
-
audit_log
¶
Enable audit logging and define the log location.
This option accepts a string value that allows you to define the log location.
The following locations are supported:
- File: to write audit logs to a file, specify a path to a file (with an optional
file
prefix)
- Pipeline: to start a program and write audit logs to it, specify a program name (with
|
or pipe
prefix)
- System log: to write audit logs to a system log, specify a message for
syslogd
(with syslog
prefix)
See the examples below.
By default, audit logging is disabled.
Example: Writing to a file
box.cfg{audit_log = 'audit_tarantool.log'}
-- or
box.cfg{audit_log = 'file:audit_tarantool.log'}
This opens the audit_tarantool.log
file for output in the server’s default directory.
If the audit_log
string has no prefix or the prefix file:
, the string is interpreted as a file path.
If you log to a file, Tarantool will reopen the audit log at SIGHUP.
Example: Sending to a pipeline
box.cfg{audit_log = '| cronolog audit_tarantool.log'}
-- or
box.cfg{audit_log = 'pipe: cronolog audit_tarantool.log'}'
This starts the cronolog program when the server starts
and sends all audit_log
messages to cronolog’s standard input (stdin
).
If the audit_log
string starts with „|“ or contains the prefix pipe:
,
the string is interpreted as a Unix pipeline.
If log is a program, check out its pid and send it a signal to rotate logs.
Example: Writing to a system log
Предупреждение
Below is an example of writing audit logs to a directory shared with the system logs.
Tarantool allows this option, but it is not recommended to do this to avoid difficulties
when working with audit logs. System and audit logs should be written separately.
To do this, create separate paths and specify them.
This sample configuration sends the audit log to syslog:
box.cfg{audit_log = 'syslog:identity=tarantool'}
-- or
box.cfg{audit_log = 'syslog:facility=user'}
-- or
box.cfg{audit_log = 'syslog:identity=tarantool,facility=user'}
-- or
box.cfg{audit_log = 'syslog:server=unix:/dev/log'}
If the audit_log
string starts with «syslog:»,
it is interpreted as a message for the syslogd program,
which normally runs in the background of any Unix-like platform.
The setting can be „syslog:“, „syslog:facility=…“, „syslog:identity=…“, „syslog:server=…“ or a combination.
The syslog:identity
setting is an arbitrary string that is placed at the beginning of all messages.
The default value is tarantool
.
The syslog:facility
setting is currently ignored, but will be used in the future.
The value must be one of the syslog keywords
that tell syslogd
where to send the message.
The possible values are auth
, authpriv
, cron
, daemon
, ftp
,
kern
, lpr
, mail
, news
, security
, syslog
, user
, uucp
,
local0
, local1
, local2
, local3
, local4
, local5
, local6
, local7
.
The default value is local7
.
The syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path starting with «unix:» or an ipv4 port number.
The default socket value is /dev/log
(on Linux) or /var/run/syslog
(on Mac OS).
The default port value is 514, which is the UDP port.
An example of a Tarantool audit log entry in the syslog:
09:32:52 tarantool_audit: {"time": "2024-02-08T09:32:52.190+0300", "uuid": "94454e46-9a0e-493a-bb9f-d59e44a43581", "severity": "INFO", "remote": "unix/:(socket)", "session_type": "console", "module": "tarantool", "user": "admin", "type": "space_create", "tag": "", "description": "Create space bands"}
Тип: строка
Possible values: see the string format above
Default: „nill“
Environment variable: TT_AUDIT_LOG
-
audit_nonblock
¶
Specify the logging behavior if the system is not ready to write.
If set to true
, Tarantool does not block during logging if the system is non-writable and writes a message instead.
Using this value may improve logging performance at the cost of losing some log messages.
Примечание
The option only has an effect if the audit_log is set to syslog
or pipe
.
Setting audit_nonblock
to true
is not allowed if the output is to a file.
In this case, set audit_nonblock
to false
.
Тип: логический
По умолчанию: true
Environment variable: TT_AUDIT_NONBLOCK
-
audit_spaces
¶
Since: 3.0.0.
The array of space names for which data operation events (space_select
, space_insert
, space_replace
,
space_delete
) should be logged. The array accepts string values.
If set to box.NULL, the data operation events are logged for all spaces.
Example
In the example, only the events of bands
and singers
spaces are logged:
box.cfg{
audit_spaces = 'bands,singers'
}
Type: array
Default: box.NULL
Environment variable: TT_AUDIT_SPACES
Authentication
Enterprise Edition
Authentication features are supported by the Enterprise Edition only.
- auth_delay
- auth_retries
- auth_type
- disable_guest
- password_min_length
- password_enforce_uppercase
- password_enforce_lowercase
- password_enforce_digits
- password_enforce_specialchars
- password_lifetime_days
- password_history_length
-
auth_delay
¶
Since 2.11.0.
Specify a period of time (in seconds) that a specific user should wait
for the next attempt after failed authentication.
With the configuration below, Tarantool refuses the authentication attempt if the previous
attempt was less than 5 seconds ago.
box.cfg{ auth_delay = 5 }
Тип: число
Default: 0
Environment variable: TT_AUTH_DELAY
Динамический: да
-
auth_retries
¶
Since 3.0.0.
Specify the maximum number of authentication retries allowed before auth_delay
is enforced.
The default value is 0, which means auth_delay
is enforced after the first failed authentication attempt.
The retry counter is reset after auth_delay
seconds since the first failed attempt.
For example, if a client tries to authenticate fewer than auth_retries
times within auth_delay
seconds, no authentication delay is enforced.
The retry counter is also reset after any successful authentication attempt.
Тип: число
Default: 0
Environment variable: TT_AUTH_RETRIES
Динамический: да
-
auth_type
¶
Since 2.11.0.
Specify an authentication protocol:
- „chap-sha1“: use the CHAP protocol to authenticate users with
SHA-1
hashing applied to passwords.
- „pap-sha256“: use PAP authentication with the
SHA256
hashing algorithm.
For new users, the box.schema.user.create method
will generate authentication data using PAP-SHA256
.
For existing users, you need to reset a password using
box.schema.user.passwd
to use the new authentication protocol.
Тип: строка
Default value: „chap-sha1“
Environment variable: TT_AUTH_TYPE
Динамический: да
-
disable_guest
¶
Since 2.11.0.
If true, disables access over remote connections
from unauthenticated or guest access users.
This option affects both
net.box and
replication connections.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_DISABLE_GUEST
Динамический: да
-
password_min_length
¶
Since 2.11.0.
Specify the minimum number of characters for a password.
The following example shows how to set the minimum password length to 10.
box.cfg{ password_min_length = 10 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_MIN_LENGTH
Динамический: да
-
password_enforce_uppercase
¶
Since 2.11.0.
If true, a password should contain uppercase letters (A-Z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_UPPERCASE
Динамический: да
-
password_enforce_lowercase
¶
Since 2.11.0.
If true, a password should contain lowercase letters (a-z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_LOWERCASE
Динамический: да
-
password_enforce_digits
¶
Since 2.11.0.
If true, a password should contain digits (0-9).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_DIGITS
Динамический: да
-
password_enforce_specialchars
¶
Since 2.11.0.
If true, a password should contain at least one special character (such as &|?!@$
).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARS
Динамический: да
-
password_lifetime_days
¶
Since 2.11.0.
Specify the maximum period of time (in days) a user can use the same password.
When this period ends, a user gets the «Password expired» error on a login attempt.
To restore access for such users, use box.schema.user.passwd.
Примечание
The default 0 value means that a password never expires.
The example below shows how to set a maximum password age to 365 days.
box.cfg{ password_lifetime_days = 365 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_LIFETIME_DAYS
Динамический: да
-
password_history_length
¶
Since 2.11.0.
Specify the number of unique new user passwords before an old password can be reused.
In the example below, a new password should differ from the last three passwords.
box.cfg{ password_history_length = 3 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_HISTORY_LENGTH
Динамический: да
Примечание
Tarantool uses the auth_history
field in the
box.space._user
system space to store user passwords.
Flight recorder
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶
Since 2.11.0.
Enable the flight recorder.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FLIGHTREC_ENABLED
Динамический: да
-
flightrec_logs_size
¶
Since 2.11.0.
Specify the size (in bytes) of the log storage.
You can set this option to 0
to disable the log storage.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_LOGS_SIZE
Динамический: да
-
flightrec_logs_max_msg_size
¶
Since 2.11.0.
Specify the maximum size (in bytes) of the log message.
The log message is truncated if its size exceeds this limit.
Тип: целое число
Default: 4096
Maximum: 16384
Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZE
Динамический: да
-
flightrec_logs_log_level
¶
Since 2.11.0.
Specify the level of detail the log has.
You can learn more about log levels from the log_level
option description.
Note that the flightrec_logs_log_level
value might differ from log_level
.
Тип: целое число
Default: 6
Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVEL
Динамический: да
-
flightrec_metrics_period
¶
Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump.
So, this value defines how much historical metrics data is collected up to the moment of crash.
The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое число
Default: 180
Environment variable: TT_FLIGHTREC_METRICS_PERIOD
Динамический: да
-
flightrec_metrics_interval
¶
Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics.
This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB,
you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: число
По умолчанию: 1.0
Minimum: 0.001
Environment variable: TT_FLIGHTREC_METRICS_INTERVAL
Динамический: да
-
flightrec_requests_size
¶
Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data.
You can set this parameter to 0
to disable a storage of requests and responses.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_REQUESTS_SIZE
Динамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
- 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
-
replication
¶ 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 inreplication
with a URI (Universal Resource Identifier), for example:konstantin:secret_password@tarantool.org:3301
Если в наборе реплик более одного источника репликации, укажите массив URI, например (замените „uri“ и „uri2“ в данном примере на рабочие URI):
box.cfg{ replication = { 'uri1', 'uri2' } }
Примечание
Starting from version 2.10.0, there is a number of other ways for specifying several URIs. See syntax examples.
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 samereplication
specification on multiple server instances, as shown in these examples.По умолчанию, пользователем считается „guest“.
Реплика в режиме только для чтения не принимает запросы по изменению данных по порту для прослушивания.
Параметр
replication
является динамическим, то есть для входа в режим мастера необходимо просто присвоить параметруreplication
пустую строку и выполнить следующее:box.cfg{ replication = новое-значение }
Тип: строкаПо умолчанию: nullEnvironment variable: TT_REPLICATIONДинамический: да
-
replication_anon
¶ 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.
Так как анонимная реплика не зарегистрирована в таблице
_cluster
, нет никаких ограничений для количества анонимных реплик в наборе: можно создавать их сколько угодно.Чтобы сделать реплику анонимной, передайте опцию
replication_anon=true
вbox.cfg
и установите значениеread_only
равнымtrue
.Попробуем создать анонимную реплику. Предположим, что у нас есть мастер с такой настройкой:
box.cfg{listen=3301}
и создан локальный спейс «loc»:
box.schema.space.create('loc', {is_local=true}) box.space.loc:create_index("pk")
Теперь, чтобы настроить анонимную реплику, нам нужно обратиться к
box.cfg
, как обычно.box.cfg{replication_anon=true, read_only=true, replication=3301}
Как было сказано выше,
replication_anon
может бытьtrue
только вместе сread_only
. Этот экземпляр получит снимок мастера и начнет следить за его изменениями. Он не получит id, поэтому его значение останется нулевым.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 ...
Теперь можно использовать реплику. Например, можно сделать вставку в локальный спейс:
tarantool> for i = 1,10 do > box.space.loc:insert{i} > end --- ...
Заметьте, что пока экземпляр анонимный, увеличится нулевая компонента его
vclock
:tarantool> box.info.vclock --- - {0: 10, 1: 4} ...
А теперь давайте сделаем анонимную реплику снова обычной:
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-51a46def7661 2019-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> subscribed 2019-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
Эта реплика получила id равный 2. Мы можем снова сделать ее открытой на запись:
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: memtx before_replace: 'function: 0x01109f9dc8' on_replace: 'function: 0x01109f9d90' ck_constraint: [] field_count: 0 temporary: false index: [] is_local: false enabled: false name: test id: 513 - created ... tarantool> box.info.vclock --- - {0: 10, 1: 5, 2: 2} ...
Теперь, как и ожидалось, реплика отслеживает свои изменения во 2-й компоненте vclock. С этого момента она также может стать мастером репликации.
Замечания:
- Нельзя реплицироваться от анонимной реплики.
- Чтобы вернуть анонимный экземпляр к обычному состоянию, сначала запустите его как анонимный, а потом вызовите
box.cfg{replication_anon=false}
- Чтобы деанонимизация прошла успешно, экземпляр должен быть скопирован с какого-то экземпляра, открытого на запись, иначе он не может быть добавлен в таблицу
_cluster
.
Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_REPLICATION_ANONДинамический: да
-
bootstrap_leader
¶ 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'}, }
Тип: строкаПо умолчанию: nullEnvironment variable: TT_BOOTSTRAP_LEADERДинамический: да
-
bootstrap_strategy
¶ 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.
Тип: строкаDefault: autoEnvironment variable: TT_BOOTSTRAP_STRATEGYДинамический: да
-
replication_connect_timeout
¶ 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.
Тип: число с плавающей запятойПо умолчанию: 30Environment variable: TT_REPLICATION_CONNECT_TIMEOUTДинамический: да
-
replication_connect_quorum
¶ 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
to0
makes Tarantool require no immediate reconnect only in case of recovery. See Orphan status for details.Пример:
box.cfg { replication_connect_quorum = 2 }
Тип: целое числоПо умолчанию: nullEnvironment variable: TT_REPLICATION_CONNECT_QUORUMДинамический: да
-
replication_skip_conflict
¶ 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.
Однако если указать
replication_skip_conflict = true
, пользователи могут задать пропуск таких ошибок. Так, вместо сохранения сломанной транзакции в xlog, там будет записаноNOP
(No operation).Пример:
box.cfg{replication_skip_conflict=true}
Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_REPLICATION_SKIP_CONFLICTДинамический: даПримечание
replication_skip_conflict = true
рекомендуется использовать только для ручного восстановления репликации.
-
replication_sync_lag
¶ Since version 1.9.0.
The maximum lag allowed for a replica. When a replica syncs (gets updates from a master), it may not catch up completely. The number of seconds that the replica is behind the master is called the «lag». Syncing is considered to be complete when the replica’s lag is less than or equal to
replication_sync_lag
.Если пользователь задает значение
replication_sync_lag
, равное nil или 365 * 100 * 86400 (TIMEOUT_INFINITY), то отставание не имеет значения – реплика всегда будет синхронизирована. Кроме того, отставание не учитывается (считается бесконечным), если мастер работает на версии Tarantool старше 1.7.7, которая не отправляет сообщения контрольного сигнала.Этот параметр не учитывается во время настройки. Для получения подробной информации, см. статус orphan.
Тип: число с плавающей запятойПо умолчанию: 10Environment variable: TT_REPLICATION_SYNC_LAGДинамический: да
-
replication_sync_timeout
¶ Since version 1.10.2.
The number of seconds that a node waits when trying to sync with other nodes in a replica set (see bootstrap_strategy), after connecting or during configuration update. This could fail indefinitely if
replication_sync_lag
is smaller than network latency, or if the replica cannot keep pace with master updates. Ifreplication_sync_timeout
expires, the replica enters orphan status.Тип: число с плавающей запятойПо умолчанию: 300Environment variable: TT_REPLICATION_SYNC_TIMEOUTДинамический: даПримечание
The default
replication_sync_timeout
value is going to be changed in future versions from300
to0
. You can learn the reasoning behind this decision from the Default value for replication_sync_timeout topic, which also describes how to try the new behavior in the current version.
-
replication_timeout
¶ Since version 1.7.5.
If the master has no updates to send to the replicas, it sends heartbeat messages every
replication_timeout
seconds, and each replica sends an ACK packet back.И мастер, и реплики запрограммированы разорвать соединение при отсутствии сообщений в течение четырех промежутков времени, указанного в параметре
replication_timeout
. После разрыва соединения реплика пытается снова подключиться к мастеру.См. дополнительную информацию в разделе Мониторинг набора реплик.
Тип: целое числоПо умолчанию: 1Environment variable: TT_REPLICATION_TIMEOUTДинамический: да
-
replicaset_uuid
¶ Since version 1.9.0.
As described in section «Replication architecture», each replica set is identified by a universally unique identifier called replica set UUID, and each instance is identified by an instance UUID.
Как правило, достаточно позволить системе сгенерировать и форматировать строки, содержащие UUID, которые будут храниться постоянно.
Однако, некоторые администраторы предпочитают сохранять конфигурацию Tarantool в центральном репозитории, например, Apache ZooKeeper. Они могут самостоятельно присвоить значения экземплярам (instance_uuid) и набору реплик (
replicaset_uuid
) при первом запуске.Общие правила:
- Значения должны быть действительно уникальными; они не должны одновременно принадлежать другим экземплярам или наборам реплик в той же инфраструктуре.
- Значения должны использоваться постоянно, неизменно с первого запуска (первоначальные значения хранятся в файлах снимков и проверяются при каждом перезапуске системы).
- Значения должны соответствовать требованиям RFC 4122. Нулевой UUID не допускается.
Формат UUID включает в себя шестнадцать октетов, представленных в виде 32 шестнадцатеричных чисел (с основанием 16) в пяти группах, разделенных дефисами в форме
8-4-4-4-12
– 36 символов (32 буквенно-цифровых символа и четыре дефиса).Пример:
box.cfg{replicaset_uuid='7b853d13-508b-4b8e-82e6-806f088ea6e9'}
Тип: строкаПо умолчанию: nullEnvironment variable: TT_REPLICASET_UUIDДинамический: нет
-
instance_uuid
¶ Since version 1.9.0.
For replication administration purposes, it is possible to set the universally unique identifiers of the instance (
instance_uuid
) and the replica set (replicaset_uuid
), instead of having the system generate the values.Для получения подробной информации см. описание параметра replicaset_uuid.
Пример:
box.cfg{instance_uuid='037fec43-18a9-4e12-a684-a42b716fcd02'}
Тип: строкаПо умолчанию: nullEnvironment variable: TT_INSTANCE_UUIDДинамический: нет
-
replication_synchro_quorum
¶ Since version 2.5.1.
For synchronous replication only. This option tells how many replicas should confirm the receipt of a synchronous transaction before it can finish its commit.
Since version 2.5.3, the option supports dynamic evaluation of the quorum number. That is, the number of quorum can be specified not as a constant number, but as a function instead. In this case, the option returns the formula evaluated. The result is treated as an integer number. Once any replicas are added or removed, the expression is re-evaluated automatically.
For example,
box.cfg{replication_synchro_quorum = "N / 2 + 1"}
Where
N
is a current number of registered replicas in a cluster.Keep in mind that the example above represents a canonical quorum definition. The formula
at least 50% of the cluster size + 1
guarantees data reliability. Using a value less than the canonical one might lead to unexpected results, including a split-brain.Since version 2.10.0, this option does not account for anonymous replicas.
По умолчанию значение параметра равно
N / 2 + 1
.Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Если значение параметра равно
1
, синхронные транзакции работают как асинхронные, пока они не настроены.1
означает, что для коммита достаточно успешной записи в WAL на мастере.Тип: числоDefault: N / 2 + 1 (before version 2.10.0, the default value was 1)Environment variable: TT_REPLICATION_SYNCHRO_QUORUMДинамический: да
-
replication_synchro_timeout
¶ Since version 2.5.1.
For synchronous replication only. Tells how many seconds to wait for a synchronous transaction quorum replication until it is declared failed and is rolled back.
Она не используется на репликах, поэтому если мастер умирает, отложенные синхронные транзакции будут ждать на репликах до тех пор, пока не будет выбран новый мастер.
Тип: числоПо умолчанию: 5Environment variable: TT_REPLICATION_SYNCHRO_TIMEOUTДинамический: да
-
replication_threads
¶ Since version 2.10.0.
The number of threads spawned to decode the incoming replication data.
The default value is
1
. It means that a single separate thread handles all the incoming replication streams. In most cases, one thread is enough for all incoming data. Therefore, it is likely that the user will not need to set this configuration option.Possible values range from 1 to 1000. If there are multiple replication threads, connections to serve are distributed evenly between the threads.
Тип: числоПо умолчанию: 1Possible values: from 1 to 1000Environment variable: TT_REPLICATION_THREADSDynamic: no
-
election_mode
¶ Since version 2.6.1.
Specify the role of a replica set node in the leader election process.
Possible values:
- off
- voter
- candidate
- manual.
Participation of a replica set node in the automated leader election can be turned on and off by this option.
The default value is
off
. All nodes that have values other thanoff
run the Raft state machine internally talking to other nodes according to the Raft leader election protocol. When the option isoff
, the node accepts Raft messages from other nodes, but it doesn’t participate in the election activities, and this doesn’t affect the node’s state. So, for example, if a node is not a leader but it haselection_mode = 'off'
, it is writable anyway.You can control which nodes can become a leader. If you want a node to participate in the election process but don’t want that it becomes a leaders, set the
election_mode
option tovoter
. In this case, the election works as usual, this particular node will vote for other nodes, but won’t become a leader.If the node should be able to become a leader, use
election_mode = 'candidate'
.Since version 2.8.2, the manual election mode is introduced. It may be used when a user wants to control which instance is the leader explicitly instead of relying on the Raft election algorithm.
When an instance is configured with the
election_mode='manual'
, it behaves as follows:- By default, the instance acts like a voter – it is read-only and may vote for other instances that are candidates.
- Once box.ctl.promote() is called, the instance becomes a candidate and starts a new election round. If the instance wins the elections, it becomes a leader, but won’t participate in any new elections.
Тип: строкаDefault: „off“Environment variable: TT_ELECTION_MODEДинамический: да
-
election_timeout
¶ Since version 2.6.1.
Specify the timeout between election rounds in the leader election process if the previous round ended up with a split-vote.
In the leader election process, there can be an election timeout for the case of a split-vote. The timeout can be configured using this option; the default value is 5 seconds.
It is quite big, and for most of the cases it can be freely lowered to 300-400 ms. It can be a floating point value (300 ms would be
box.cfg{election_timeout = 0.3}
).To avoid the split vote repeat, the timeout is randomized on each node during every new election, from 100% to 110% of the original timeout value. For example, if the timeout is 300 ms and there are 3 nodes started the election simultaneously in the same term, they can set their election timeouts to 300, 310, and 320 respectively, or to 305, 302, and 324, and so on. In that way, the votes will never be split because the election on different nodes won’t be restarted simultaneously.
Тип: числоПо умолчанию: 5Environment variable: TT_ELECTION_TIMEOUTДинамический: да
-
election_fencing_mode
¶ Since version 2.11.0.
In earlier Tarantool versions, use election_fencing_enabled instead.
Specify the leader fencing mode that affects the leader election process. When the parameter is set to
soft
orstrict
, the leader resigns its leadership if it has less than replication_synchro_quorum of alive connections to the cluster nodes. The resigning leader receives the status of a follower in the current election term and becomes read-only.- In
soft
mode, a connection is considered dead if there are no responses for 4*replication_timeout seconds both on the current leader and the followers. - In
strict
mode, a connection is considered dead if there are no responses for 2*replication_timeout seconds on the current leader and 4*replication_timeout seconds on the followers. This improves chances that there is only one leader at any time.
Fencing applies to the instances that have the election_mode set to
candidate
ormanual
. To turn off leader fencing, setelection_fencing_mode
tooff
.Тип: строкаDefault: „soft“Environment variable: TT_ELECTION_FENCING_MODEДинамический: да- In
-
instance_name
¶ Since version 3.0.0.
Specify the instance name. This value must be unique in a replica set.
The following rules are applied to instance names:
- The maximum number of symbols is 63.
- Should start with a letter.
- Can contain lowercase letters (a-z). If uppercase letters are used, they are converted to lowercase.
- Can contain digits (0-9).
- Can contain the following characters:
-
,_
.
To change or remove the specified name, you should temporarily set the box.cfg.force_recovery configuration option to
true
. When all the names are updated and all the instances synced,box.cfg.force_recovery
can be set back tofalse
.Примечание
The instance name is persisted in the box.space._cluster system space.
See also: box.info.name
Тип: строкаПо умолчанию: nullEnvironment variable: TT_INSTANCE_NAMEДинамический: нет
-
replicaset_name
¶ Since version 3.0.0.
Specify the name of a replica set to which this instance belongs. This value must be the same for all instances of the replica set.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The replica set name is persisted in the box.space._schema system space.
See also: box.info.replicaset
Тип: строкаПо умолчанию: nullEnvironment variable: TT_REPLICASET_NAMEДинамический: нет
-
cluster_name
¶ Since version 3.0.0.
Specify the name of a cluster to which this instance belongs. This value must be the same for all instances of the cluster.
See the instance_name description to learn:
- which rules are applied to names
- how to change or remove an already specified name
Примечание
The cluster name is persisted in the box.space._schema system space.
See also: box.info.cluster
Тип: строкаПо умолчанию: nullEnvironment variable: TT_CLUSTER_NAMEДинамический: нет
Работа с сетями
-
io_collect_interval
¶
Since version 1.4.9.
The instance will sleep for io_collect_interval seconds between iterations
of the event loop. Can be used to reduce CPU load in deployments in which
the number of client connections is large, but requests are not so frequent
(for example, each connection issues just a handful of requests per second).
Тип: число с плавающей запятой
По умолчанию: null
Environment variable: TT_IO_COLLECT_INTERVAL
Динамический: да
-
net_msg_max
¶
Since version 1.10.1.
To handle messages, Tarantool allocates fibers.
To prevent fiber overhead from affecting the whole system,
Tarantool restricts how many messages the fibers handle,
so that some pending requests are blocked.
В мощных системах увеличьте значение net_msg_max
, и планировщик немедленно приступит к обработке отложенных запросов.
В более слабых системах уменьшите значение net_msg_max
, чтобы снизить загрузку, хотя это и займет некоторое время, поскольку планировщик будет ожидать завершения уже запущенных запросов.
When net_msg_max
is reached,
Tarantool suspends processing of incoming packages until it
has processed earlier messages. This is not a direct restriction of
the number of fibers that handle network messages, rather it
is a system-wide restriction of channel bandwidth.
This in turn causes restriction of the number of incoming
network messages that the
transaction processor thread
handles, and therefore indirectly affects the fibers that handle
network messages.
(The number of fibers is smaller than the number of messages because
messages can be released as soon as they are delivered, while
incoming requests might not be processed until some time after delivery.)
Для стандартных систем подойдет значение, используемое по умолчанию (768).
Тип: целое число
По умолчанию: 768
Environment variable: TT_NET_MSG_MAX
Динамический: да
-
readahead
¶
Since version 1.6.2.
The size of the read-ahead buffer associated with a client connection. The
larger the buffer, the more memory an active connection consumes and the
more requests can be read from the operating system buffer in a single
system call. The rule of thumb is to make sure the buffer can contain at
least a few dozen requests. Therefore, if a typical tuple in a request is
large, e.g. a few kilobytes or even megabytes, the read-ahead buffer size
should be increased. If batched request processing is not used, it’s prudent
to leave this setting at its default.
Тип: целое число
По умолчанию: 16320
Environment variable: TT_READAHEAD
Динамический: да
-
iproto_threads
¶
Since version 2.8.1.
The number of network threads.
There can be unusual workloads where the network thread
is 100% loaded and the transaction processor thread is not, so the network
thread is a bottleneck. In that case set iproto_threads
to 2 or more.
The operating system kernel will determine which connection goes to
which thread.
On typical systems, the default value (1) is correct.
Тип: целое число
По умолчанию: 1
Environment variable: TT_IPROTO_THREADS
Динамический: нет
Запись в журнал
This section provides information on how to configure options related to logging.
You can also use the log module to configure logging in your
application.
-
log_level
¶
Since version 1.6.2.
Specify the level of detail the log has. There are the following levels:
- 0 –
fatal
- 1 –
syserror
- 2 –
error
- 3 –
crit
- 4 –
warn
- 5 –
info
- 6 –
verbose
- 7 –
debug
By setting log_level
, you can enable logging of all events with severities above
or equal to the given level. Tarantool prints logs to the standard
error stream by default. This can be changed with the
log configuration parameter.
Type: integer, string
По умолчанию: 5
Environment variable: TT_LOG_LEVEL
Динамический: да
Примечание
Prior to Tarantool 1.7.5 there were only six levels and DEBUG
was
level 6. Starting with Tarantool 1.7.5, VERBOSE
is level 6 and DEBUG
is level 7.
VERBOSE
is a new level for monitoring repetitive events which would cause
too much log writing if INFO
were used instead.
-
log
¶
Since version 1.7.4.
By default, Tarantool sends the log to the standard error stream
(stderr
). If log
is specified, Tarantool can send the log to a:
- file
- pipe
- system logger
Example 1: sending the log to the tarantool.log
file.
box.cfg{log = 'tarantool.log'}
-- или
box.cfg{log = 'file:tarantool.log'}
This opens the file tarantool.log
for output on the server’s default
directory. If the log
string has no prefix or has the prefix «file:»,
then the string is interpreted as a file path.
Example 2: sending the log to a pipe.
box.cfg{log = '| cronolog tarantool.log'}
-- or
box.cfg{log = 'pipe: cronolog tarantool.log'}
This starts the program cronolog when the server starts, and
sends all log messages to the standard input (stdin
) of cronolog
.
If the log
string begins with „|“ or has the prefix «pipe:»,
then the string is interpreted as a Unix
pipeline.
Example 3: sending the log to syslog.
box.cfg{log = 'syslog:identity=tarantool'}
-- или
box.cfg{log = 'syslog:facility=user'}
-- или
box.cfg{log = 'syslog:identity=tarantool,facility=user'}
-- или
box.cfg{log = 'syslog:server=unix:/dev/log'}
If the log
string begins with «syslog:», then it is
interpreted as a message for the
syslogd program, which normally
is running in the background on any Unix-like platform.
The setting can be syslog:
, syslog:facility=...
, syslog:identity=...
,
syslog:server=...
, or a combination.
- The
syslog:identity
setting is an arbitrary string, which is placed at
the beginning of all messages. The default value is «tarantool».
- В настоящий момент настройка
syslog:facility
не учитывается, но будет использоваться в дальнейшем. Ее значением должно быть одно из ключевых слов syslog, которые сообщают программе syslogd, куда отправлять сообщение. Возможные значения: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7. По умолчанию: user.
- The
syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path beginning with «unix:», or an ipv4 port number.
The default socket value is: dev/log
(on Linux) or /var/run/syslog
(on macOS).
The default port value is: 514, the UDP port.
When logging to a file, Tarantool reopens the log on SIGHUP.
When log is a program, its PID is saved in the log.pid
variable. You need to send it a signal to rotate logs.
Тип: строка
По умолчанию: null
Environment variable: TT_LOG
Динамический: нет
-
log_nonblock
¶
Since version 1.7.4.
If log_nonblock
equals true, Tarantool does not block during logging
when the system is not ready for writing, and drops the message
instead. If log_level is high, and many
messages go to the log, setting log_nonblock
to true may improve
logging performance at the cost of some log messages getting lost.
This parameter has effect only if log is
configured to send logs to a pipe or system logger.
The default log_nonblock
value is nil, which means that
blocking behavior corresponds to the logger type:
- false for
stderr
and file loggers.
- true for a pipe and system logger.
This is a behavior change: in earlier versions of the Tarantool
server, the default value was true.
Тип: логический
По умолчанию: nil
Environment variable: TT_LOG_NONBLOCK
Динамический: нет
-
too_long_threshold
¶
Since version 1.6.2.
If processing a request takes longer than the given value (in seconds),
warn about it in the log. Has effect only if log_level is greater than or equal to 4 (WARNING).
Тип: число с плавающей запятой
По умолчанию: 0.5
Environment variable: TT_TOO_LONG_THRESHOLD
Динамический: да
-
log_format
¶
Since version 1.7.6.
Log entries have two possible formats:
- „plain“ (по умолчанию) или
- „json“ (более детально с JSON-метками).
Here is what a log entry looks like if box.cfg{log_format='plain'}
:
2017-10-16 11:36:01.508 [18081] main/101/interactive I> set 'log_format' configuration option to "plain"
Here is what a log entry looks like if box.cfg{log_format='json'}
:
{"time": "2017-10-16T11:36:17.996-0600",
"level": "INFO",
"message": "set 'log_format' configuration option to \"json\"",
"pid": 18081,|
"cord_name": "main",
"fiber_id": 101,
"fiber_name": "interactive",
"file": "builtin\/box\/load_cfg.lua",
"line": 317}
The log_format='plain'
entry has a time value, process ID,
cord name, fiber_id,
fiber_name,
log level, and message.
The log_format='json'
entry has the same fields along with their labels,
and in addition has the file name and line number of the Tarantool source.
Тип: строка
По умолчанию: „plain“
Environment variable: TT_LOG_FORMAT
Динамический: да
-
log_modules
¶
Since version 2.11.0.
Configure the specified log levels (log_level) for different modules.
You can specify a logging level for the following module types:
- Modules (files) that use the default logger.
Example: Set log levels for files that use the default logger.
- Modules that use custom loggers created using the log.new() function.
Example: Set log levels for modules that use custom loggers.
- The
tarantool
module that enables you to configure the logging level for Tarantool core messages. Specifically, it configures the logging level for messages logged from non-Lua code, including C modules.
Example: Set a log level for C modules.
Type: table
Default: blank
Environment variable: TT_LOG_MODULES
Динамический: да
Example 1: Set log levels for files that use the default logger
Suppose you have two identical modules placed by the following paths: test/logging/module1.lua
and test/logging/module2.lua
.
These modules use the default logger and look as follows:
return {
say_hello = function()
local log = require('log')
log.info('Info message from module1')
end
}
To load these modules in your application, you need to add the corresponding require
directives:
module1 = require('test.logging.module1')
module2 = require('test.logging.module2')
To configure logging levels, you need to provide module names corresponding to paths to these modules.
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function:
box_cfg = { log_modules = {
['test.logging.module1'] = 'verbose',
['test.logging.module2'] = 'error' }
}
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1.say_hello()
shows a message but module2.say_hello()
is swallowed:
-- Prints 'info' messages --
module1.say_hello()
--[[
[92617] main/103/interactive/test.logging.module1 I> Info message from module1
---
...
--]]
-- Swallows 'info' messages --
module2.say_hello()
--[[
---
...
--]]
Example 2: Set log levels for modules that use custom loggers
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the verbose
level for module1
and the error
level for module2
:
box_cfg = { log_level = 'warn',
log_modules = {
module1 = 'verbose',
module2 = 'error' }
}
To create custom loggers, call the log.new() function:
-- Creates new loggers --
module1_log = require('log').new('module1')
module2_log = require('log').new('module2')
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1_log.info()
shows a message but module2_log.info()
is swallowed:
-- Prints 'info' messages --
module1_log.info('Info message from module1')
--[[
[16300] main/103/interactive/module1 I> Info message from module1
---
...
--]]
-- Swallows 'debug' messages --
module1_log.debug('Debug message from module1')
--[[
---
...
--]]
-- Swallows 'info' messages --
module2_log.info('Info message from module2')
--[[
---
...
--]]
Example 3: Set a log level for C modules
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the info
level for the tarantool
module:
box_cfg = { log_level = 'warn',
log_modules = { tarantool = 'info' } }
The specified level affects messages logged from C modules:
ffi = require('ffi')
-- Prints 'info' messages --
ffi.C._say(ffi.C.S_INFO, nil, 0, nil, 'Info message from C module')
--[[
[6024] main/103/interactive I> Info message from C module
---
...
--]]
-- Swallows 'debug' messages --
ffi.C._say(ffi.C.S_DEBUG, nil, 0, nil, 'Debug message from C module')
--[[
---
...
--]]
The example above uses the LuaJIT ffi library to call C functions provided by the say
module.
This example illustrates how «rotation» works, that is, what happens when the server
instance is writing to a log and signals are used when archiving it.
Start with two terminal shells: Terminal #1 and Terminal #2.
In Terminal #1, start an interactive Tarantool session.
Then, use the log
property to send logs to Log_file
and
call log.info
to put a message in the log file.
box.cfg{log='Log_file'}
log = require('log')
log.info('Log Line #1')
In Terminal #2, use the mv
command to rename the log file to Log_file.bak
.
mv Log_file Log_file.bak
As a result, the next log message will go to Log_file.bak
.
Go back to Terminal #1 and put a message «Log Line #2» in the log file.
log.info('Log Line #2')
In Terminal #2, use ps
to find the process ID of the Tarantool instance.
ps -A | grep tarantool
In Terminal #2, execute kill -HUP
to send a SIGHUP signal to the Tarantool instance.
Tarantool will open Log_file
again, and the next log message will go to Log_file
.
kill -HUP process_id
The same effect could be accomplished by calling log.rotate.
In Terminal #1, put a message «Log Line #3» in the log file.
log.info('Log Line #3')
In Terminal #2, use less
to examine files.
Log_file.bak
will have the following lines …
2015-11-30 15:13:06.373 [27469] main/101/interactive I> Log Line #1`
2015-11-30 15:14:25.973 [27469] main/101/interactive I> Log Line #2`
… and Log_file
will look like this:
log file has been reopened
2015-11-30 15:15:32.629 [27469] main/101/interactive I> Log Line #3
Audit log
Enterprise Edition
Audit log features are available in the Enterprise Edition only.
The audit_*
parameters define configuration related to audit logging.
-
audit_extract_key
¶
Since: 3.0.0.
If set to true
, the audit subsystem extracts and prints only the primary key instead of full
tuples in DML events (space_insert
, space_replace
, space_delete
).
Otherwise, full tuples are logged.
The option may be useful in case tuples are big.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_AUDIT_EXTRACT_KEY
-
audit_filter
¶
Enable logging for a specified subset of audit events.
This option accepts the following values:
- Event names (for example,
password_change
). For details, see Audit log events.
- Event groups (for example,
audit
). For details, see Event groups.
The option contains either one value from Possible values
section (see below) or a combination of them.
To enable custom audit log events, specify the custom
value in this option.
The default value is compatibility
, which enables logging of all events available before 2.10.0.
Example
box.cfg{
audit_log = 'audit.log',
audit_filter = 'audit,auth,priv,password_change,access_denied'
}
Type: array
Possible values: „all“, „audit“, „auth“, „priv“, „ddl“, „dml“, „data_operations“, „compatibility“,
„audit_enable“, „auth_ok“, „auth_fail“, „disconnect“, „user_create“, „user_drop“, „role_create“, „role_drop“,
„user_disable“, „user_enable“, „user_grant_rights“, „role_grant_rights“, „role_revoke_rights“, „password_change“,
„access_denied“, „eval“, „call“, „space_select“, „space_create“, „space_alter“, „space_drop“, „space_insert“,
„space_replace“, „space_delete“, „custom“
Default: „compatibility“
Environment variable: TT_AUDIT_FILTER
-
audit_format
¶
Specify the format that is used for the audit log events – plain text, CSV or JSON format.
Plain text is used by default. This human-readable format can be efficiently compressed.
box.cfg{audit_log = 'audit.log', audit_format = 'plain'}
Example
remote: session_type:background module:common.admin.auth user: type:custom_tdg_audit tag:tdg_severity_INFO description:[5e35b406-4274-4903-857b-c80115275940] subj: "anonymous", msg: "Access granted to anonymous user"
The JSON format is more convenient to receive log events, analyze them and integrate them with other systems if needed.
box.cfg{audit_log = 'audit.log', audit_format = 'json'}
Example
{"time": "2022-11-17T21:55:49.880+0300", "remote": "", "session_type": "background", "module": "common.admin.auth", "user": "", "type": "custom_tdg_audit", "tag": "tdg_severity_INFO", "description": "[c26cd11a-3342-4ce6-8f0b-a4b222268b9d] subj: \"anonymous\", msg: \"Access granted to anonymous user\""}
Using the CSV format allows you to view audit log events in tabular form.
box.cfg{audit_log = 'audit.log', audit_format = 'csv'}
Example
2022-11-17T21:58:03.131+0300,,background,common.admin.auth,,,custom_tdg_audit,tdg_severity_INFO,"[b3dfe2a3-ec29-4e61-b747-eb2332c83b2e] subj: ""anonymous"", msg: ""Access granted to anonymous user"""
Тип: строка
Possible values: „json“, „csv“, „plain“
Default: „json“
Environment variable: TT_AUDIT_FORMAT
-
audit_log
¶
Enable audit logging and define the log location.
This option accepts a string value that allows you to define the log location.
The following locations are supported:
- File: to write audit logs to a file, specify a path to a file (with an optional
file
prefix)
- Pipeline: to start a program and write audit logs to it, specify a program name (with
|
or pipe
prefix)
- System log: to write audit logs to a system log, specify a message for
syslogd
(with syslog
prefix)
See the examples below.
By default, audit logging is disabled.
Example: Writing to a file
box.cfg{audit_log = 'audit_tarantool.log'}
-- or
box.cfg{audit_log = 'file:audit_tarantool.log'}
This opens the audit_tarantool.log
file for output in the server’s default directory.
If the audit_log
string has no prefix or the prefix file:
, the string is interpreted as a file path.
If you log to a file, Tarantool will reopen the audit log at SIGHUP.
Example: Sending to a pipeline
box.cfg{audit_log = '| cronolog audit_tarantool.log'}
-- or
box.cfg{audit_log = 'pipe: cronolog audit_tarantool.log'}'
This starts the cronolog program when the server starts
and sends all audit_log
messages to cronolog’s standard input (stdin
).
If the audit_log
string starts with „|“ or contains the prefix pipe:
,
the string is interpreted as a Unix pipeline.
If log is a program, check out its pid and send it a signal to rotate logs.
Example: Writing to a system log
Предупреждение
Below is an example of writing audit logs to a directory shared with the system logs.
Tarantool allows this option, but it is not recommended to do this to avoid difficulties
when working with audit logs. System and audit logs should be written separately.
To do this, create separate paths and specify them.
This sample configuration sends the audit log to syslog:
box.cfg{audit_log = 'syslog:identity=tarantool'}
-- or
box.cfg{audit_log = 'syslog:facility=user'}
-- or
box.cfg{audit_log = 'syslog:identity=tarantool,facility=user'}
-- or
box.cfg{audit_log = 'syslog:server=unix:/dev/log'}
If the audit_log
string starts with «syslog:»,
it is interpreted as a message for the syslogd program,
which normally runs in the background of any Unix-like platform.
The setting can be „syslog:“, „syslog:facility=…“, „syslog:identity=…“, „syslog:server=…“ or a combination.
The syslog:identity
setting is an arbitrary string that is placed at the beginning of all messages.
The default value is tarantool
.
The syslog:facility
setting is currently ignored, but will be used in the future.
The value must be one of the syslog keywords
that tell syslogd
where to send the message.
The possible values are auth
, authpriv
, cron
, daemon
, ftp
,
kern
, lpr
, mail
, news
, security
, syslog
, user
, uucp
,
local0
, local1
, local2
, local3
, local4
, local5
, local6
, local7
.
The default value is local7
.
The syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path starting with «unix:» or an ipv4 port number.
The default socket value is /dev/log
(on Linux) or /var/run/syslog
(on Mac OS).
The default port value is 514, which is the UDP port.
An example of a Tarantool audit log entry in the syslog:
09:32:52 tarantool_audit: {"time": "2024-02-08T09:32:52.190+0300", "uuid": "94454e46-9a0e-493a-bb9f-d59e44a43581", "severity": "INFO", "remote": "unix/:(socket)", "session_type": "console", "module": "tarantool", "user": "admin", "type": "space_create", "tag": "", "description": "Create space bands"}
Тип: строка
Possible values: see the string format above
Default: „nill“
Environment variable: TT_AUDIT_LOG
-
audit_nonblock
¶
Specify the logging behavior if the system is not ready to write.
If set to true
, Tarantool does not block during logging if the system is non-writable and writes a message instead.
Using this value may improve logging performance at the cost of losing some log messages.
Примечание
The option only has an effect if the audit_log is set to syslog
or pipe
.
Setting audit_nonblock
to true
is not allowed if the output is to a file.
In this case, set audit_nonblock
to false
.
Тип: логический
По умолчанию: true
Environment variable: TT_AUDIT_NONBLOCK
-
audit_spaces
¶
Since: 3.0.0.
The array of space names for which data operation events (space_select
, space_insert
, space_replace
,
space_delete
) should be logged. The array accepts string values.
If set to box.NULL, the data operation events are logged for all spaces.
Example
In the example, only the events of bands
and singers
spaces are logged:
box.cfg{
audit_spaces = 'bands,singers'
}
Type: array
Default: box.NULL
Environment variable: TT_AUDIT_SPACES
Authentication
Enterprise Edition
Authentication features are supported by the Enterprise Edition only.
- auth_delay
- auth_retries
- auth_type
- disable_guest
- password_min_length
- password_enforce_uppercase
- password_enforce_lowercase
- password_enforce_digits
- password_enforce_specialchars
- password_lifetime_days
- password_history_length
-
auth_delay
¶
Since 2.11.0.
Specify a period of time (in seconds) that a specific user should wait
for the next attempt after failed authentication.
With the configuration below, Tarantool refuses the authentication attempt if the previous
attempt was less than 5 seconds ago.
box.cfg{ auth_delay = 5 }
Тип: число
Default: 0
Environment variable: TT_AUTH_DELAY
Динамический: да
-
auth_retries
¶
Since 3.0.0.
Specify the maximum number of authentication retries allowed before auth_delay
is enforced.
The default value is 0, which means auth_delay
is enforced after the first failed authentication attempt.
The retry counter is reset after auth_delay
seconds since the first failed attempt.
For example, if a client tries to authenticate fewer than auth_retries
times within auth_delay
seconds, no authentication delay is enforced.
The retry counter is also reset after any successful authentication attempt.
Тип: число
Default: 0
Environment variable: TT_AUTH_RETRIES
Динамический: да
-
auth_type
¶
Since 2.11.0.
Specify an authentication protocol:
- „chap-sha1“: use the CHAP protocol to authenticate users with
SHA-1
hashing applied to passwords.
- „pap-sha256“: use PAP authentication with the
SHA256
hashing algorithm.
For new users, the box.schema.user.create method
will generate authentication data using PAP-SHA256
.
For existing users, you need to reset a password using
box.schema.user.passwd
to use the new authentication protocol.
Тип: строка
Default value: „chap-sha1“
Environment variable: TT_AUTH_TYPE
Динамический: да
-
disable_guest
¶
Since 2.11.0.
If true, disables access over remote connections
from unauthenticated or guest access users.
This option affects both
net.box and
replication connections.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_DISABLE_GUEST
Динамический: да
-
password_min_length
¶
Since 2.11.0.
Specify the minimum number of characters for a password.
The following example shows how to set the minimum password length to 10.
box.cfg{ password_min_length = 10 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_MIN_LENGTH
Динамический: да
-
password_enforce_uppercase
¶
Since 2.11.0.
If true, a password should contain uppercase letters (A-Z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_UPPERCASE
Динамический: да
-
password_enforce_lowercase
¶
Since 2.11.0.
If true, a password should contain lowercase letters (a-z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_LOWERCASE
Динамический: да
-
password_enforce_digits
¶
Since 2.11.0.
If true, a password should contain digits (0-9).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_DIGITS
Динамический: да
-
password_enforce_specialchars
¶
Since 2.11.0.
If true, a password should contain at least one special character (such as &|?!@$
).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARS
Динамический: да
-
password_lifetime_days
¶
Since 2.11.0.
Specify the maximum period of time (in days) a user can use the same password.
When this period ends, a user gets the «Password expired» error on a login attempt.
To restore access for such users, use box.schema.user.passwd.
Примечание
The default 0 value means that a password never expires.
The example below shows how to set a maximum password age to 365 days.
box.cfg{ password_lifetime_days = 365 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_LIFETIME_DAYS
Динамический: да
-
password_history_length
¶
Since 2.11.0.
Specify the number of unique new user passwords before an old password can be reused.
In the example below, a new password should differ from the last three passwords.
box.cfg{ password_history_length = 3 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_HISTORY_LENGTH
Динамический: да
Примечание
Tarantool uses the auth_history
field in the
box.space._user
system space to store user passwords.
Flight recorder
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶
Since 2.11.0.
Enable the flight recorder.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FLIGHTREC_ENABLED
Динамический: да
-
flightrec_logs_size
¶
Since 2.11.0.
Specify the size (in bytes) of the log storage.
You can set this option to 0
to disable the log storage.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_LOGS_SIZE
Динамический: да
-
flightrec_logs_max_msg_size
¶
Since 2.11.0.
Specify the maximum size (in bytes) of the log message.
The log message is truncated if its size exceeds this limit.
Тип: целое число
Default: 4096
Maximum: 16384
Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZE
Динамический: да
-
flightrec_logs_log_level
¶
Since 2.11.0.
Specify the level of detail the log has.
You can learn more about log levels from the log_level
option description.
Note that the flightrec_logs_log_level
value might differ from log_level
.
Тип: целое число
Default: 6
Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVEL
Динамический: да
-
flightrec_metrics_period
¶
Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump.
So, this value defines how much historical metrics data is collected up to the moment of crash.
The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое число
Default: 180
Environment variable: TT_FLIGHTREC_METRICS_PERIOD
Динамический: да
-
flightrec_metrics_interval
¶
Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics.
This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB,
you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: число
По умолчанию: 1.0
Minimum: 0.001
Environment variable: TT_FLIGHTREC_METRICS_INTERVAL
Динамический: да
-
flightrec_requests_size
¶
Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data.
You can set this parameter to 0
to disable a storage of requests and responses.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_REQUESTS_SIZE
Динамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
-
io_collect_interval
¶ Since version 1.4.9.
The instance will sleep for io_collect_interval seconds between iterations of the event loop. Can be used to reduce CPU load in deployments in which the number of client connections is large, but requests are not so frequent (for example, each connection issues just a handful of requests per second).
Тип: число с плавающей запятойПо умолчанию: nullEnvironment variable: TT_IO_COLLECT_INTERVALДинамический: да
-
net_msg_max
¶ Since version 1.10.1.
To handle messages, Tarantool allocates fibers. To prevent fiber overhead from affecting the whole system, Tarantool restricts how many messages the fibers handle, so that some pending requests are blocked.
В мощных системах увеличьте значение
net_msg_max
, и планировщик немедленно приступит к обработке отложенных запросов.В более слабых системах уменьшите значение
net_msg_max
, чтобы снизить загрузку, хотя это и займет некоторое время, поскольку планировщик будет ожидать завершения уже запущенных запросов.When
net_msg_max
is reached, Tarantool suspends processing of incoming packages until it has processed earlier messages. This is not a direct restriction of the number of fibers that handle network messages, rather it is a system-wide restriction of channel bandwidth. This in turn causes restriction of the number of incoming network messages that the transaction processor thread handles, and therefore indirectly affects the fibers that handle network messages. (The number of fibers is smaller than the number of messages because messages can be released as soon as they are delivered, while incoming requests might not be processed until some time after delivery.)Для стандартных систем подойдет значение, используемое по умолчанию (768).
Тип: целое числоПо умолчанию: 768Environment variable: TT_NET_MSG_MAXДинамический: да
-
readahead
¶ Since version 1.6.2.
The size of the read-ahead buffer associated with a client connection. The larger the buffer, the more memory an active connection consumes and the more requests can be read from the operating system buffer in a single system call. The rule of thumb is to make sure the buffer can contain at least a few dozen requests. Therefore, if a typical tuple in a request is large, e.g. a few kilobytes or even megabytes, the read-ahead buffer size should be increased. If batched request processing is not used, it’s prudent to leave this setting at its default.
Тип: целое числоПо умолчанию: 16320Environment variable: TT_READAHEADДинамический: да
-
iproto_threads
¶ Since version 2.8.1.
The number of network threads. There can be unusual workloads where the network thread is 100% loaded and the transaction processor thread is not, so the network thread is a bottleneck. In that case set
iproto_threads
to 2 or more. The operating system kernel will determine which connection goes to which thread.On typical systems, the default value (1) is correct.
Тип: целое числоПо умолчанию: 1Environment variable: TT_IPROTO_THREADSДинамический: нет
Запись в журнал
This section provides information on how to configure options related to logging.
You can also use the log module to configure logging in your
application.
-
log_level
¶
Since version 1.6.2.
Specify the level of detail the log has. There are the following levels:
- 0 –
fatal
- 1 –
syserror
- 2 –
error
- 3 –
crit
- 4 –
warn
- 5 –
info
- 6 –
verbose
- 7 –
debug
By setting log_level
, you can enable logging of all events with severities above
or equal to the given level. Tarantool prints logs to the standard
error stream by default. This can be changed with the
log configuration parameter.
Type: integer, string
По умолчанию: 5
Environment variable: TT_LOG_LEVEL
Динамический: да
Примечание
Prior to Tarantool 1.7.5 there were only six levels and DEBUG
was
level 6. Starting with Tarantool 1.7.5, VERBOSE
is level 6 and DEBUG
is level 7.
VERBOSE
is a new level for monitoring repetitive events which would cause
too much log writing if INFO
were used instead.
-
log
¶
Since version 1.7.4.
By default, Tarantool sends the log to the standard error stream
(stderr
). If log
is specified, Tarantool can send the log to a:
- file
- pipe
- system logger
Example 1: sending the log to the tarantool.log
file.
box.cfg{log = 'tarantool.log'}
-- или
box.cfg{log = 'file:tarantool.log'}
This opens the file tarantool.log
for output on the server’s default
directory. If the log
string has no prefix or has the prefix «file:»,
then the string is interpreted as a file path.
Example 2: sending the log to a pipe.
box.cfg{log = '| cronolog tarantool.log'}
-- or
box.cfg{log = 'pipe: cronolog tarantool.log'}
This starts the program cronolog when the server starts, and
sends all log messages to the standard input (stdin
) of cronolog
.
If the log
string begins with „|“ or has the prefix «pipe:»,
then the string is interpreted as a Unix
pipeline.
Example 3: sending the log to syslog.
box.cfg{log = 'syslog:identity=tarantool'}
-- или
box.cfg{log = 'syslog:facility=user'}
-- или
box.cfg{log = 'syslog:identity=tarantool,facility=user'}
-- или
box.cfg{log = 'syslog:server=unix:/dev/log'}
If the log
string begins with «syslog:», then it is
interpreted as a message for the
syslogd program, which normally
is running in the background on any Unix-like platform.
The setting can be syslog:
, syslog:facility=...
, syslog:identity=...
,
syslog:server=...
, or a combination.
- The
syslog:identity
setting is an arbitrary string, which is placed at
the beginning of all messages. The default value is «tarantool».
- В настоящий момент настройка
syslog:facility
не учитывается, но будет использоваться в дальнейшем. Ее значением должно быть одно из ключевых слов syslog, которые сообщают программе syslogd, куда отправлять сообщение. Возможные значения: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7. По умолчанию: user.
- The
syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path beginning with «unix:», or an ipv4 port number.
The default socket value is: dev/log
(on Linux) or /var/run/syslog
(on macOS).
The default port value is: 514, the UDP port.
When logging to a file, Tarantool reopens the log on SIGHUP.
When log is a program, its PID is saved in the log.pid
variable. You need to send it a signal to rotate logs.
Тип: строка
По умолчанию: null
Environment variable: TT_LOG
Динамический: нет
-
log_nonblock
¶
Since version 1.7.4.
If log_nonblock
equals true, Tarantool does not block during logging
when the system is not ready for writing, and drops the message
instead. If log_level is high, and many
messages go to the log, setting log_nonblock
to true may improve
logging performance at the cost of some log messages getting lost.
This parameter has effect only if log is
configured to send logs to a pipe or system logger.
The default log_nonblock
value is nil, which means that
blocking behavior corresponds to the logger type:
- false for
stderr
and file loggers.
- true for a pipe and system logger.
This is a behavior change: in earlier versions of the Tarantool
server, the default value was true.
Тип: логический
По умолчанию: nil
Environment variable: TT_LOG_NONBLOCK
Динамический: нет
-
too_long_threshold
¶
Since version 1.6.2.
If processing a request takes longer than the given value (in seconds),
warn about it in the log. Has effect only if log_level is greater than or equal to 4 (WARNING).
Тип: число с плавающей запятой
По умолчанию: 0.5
Environment variable: TT_TOO_LONG_THRESHOLD
Динамический: да
-
log_format
¶
Since version 1.7.6.
Log entries have two possible formats:
- „plain“ (по умолчанию) или
- „json“ (более детально с JSON-метками).
Here is what a log entry looks like if box.cfg{log_format='plain'}
:
2017-10-16 11:36:01.508 [18081] main/101/interactive I> set 'log_format' configuration option to "plain"
Here is what a log entry looks like if box.cfg{log_format='json'}
:
{"time": "2017-10-16T11:36:17.996-0600",
"level": "INFO",
"message": "set 'log_format' configuration option to \"json\"",
"pid": 18081,|
"cord_name": "main",
"fiber_id": 101,
"fiber_name": "interactive",
"file": "builtin\/box\/load_cfg.lua",
"line": 317}
The log_format='plain'
entry has a time value, process ID,
cord name, fiber_id,
fiber_name,
log level, and message.
The log_format='json'
entry has the same fields along with their labels,
and in addition has the file name and line number of the Tarantool source.
Тип: строка
По умолчанию: „plain“
Environment variable: TT_LOG_FORMAT
Динамический: да
-
log_modules
¶
Since version 2.11.0.
Configure the specified log levels (log_level) for different modules.
You can specify a logging level for the following module types:
- Modules (files) that use the default logger.
Example: Set log levels for files that use the default logger.
- Modules that use custom loggers created using the log.new() function.
Example: Set log levels for modules that use custom loggers.
- The
tarantool
module that enables you to configure the logging level for Tarantool core messages. Specifically, it configures the logging level for messages logged from non-Lua code, including C modules.
Example: Set a log level for C modules.
Type: table
Default: blank
Environment variable: TT_LOG_MODULES
Динамический: да
Example 1: Set log levels for files that use the default logger
Suppose you have two identical modules placed by the following paths: test/logging/module1.lua
and test/logging/module2.lua
.
These modules use the default logger and look as follows:
return {
say_hello = function()
local log = require('log')
log.info('Info message from module1')
end
}
To load these modules in your application, you need to add the corresponding require
directives:
module1 = require('test.logging.module1')
module2 = require('test.logging.module2')
To configure logging levels, you need to provide module names corresponding to paths to these modules.
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function:
box_cfg = { log_modules = {
['test.logging.module1'] = 'verbose',
['test.logging.module2'] = 'error' }
}
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1.say_hello()
shows a message but module2.say_hello()
is swallowed:
-- Prints 'info' messages --
module1.say_hello()
--[[
[92617] main/103/interactive/test.logging.module1 I> Info message from module1
---
...
--]]
-- Swallows 'info' messages --
module2.say_hello()
--[[
---
...
--]]
Example 2: Set log levels for modules that use custom loggers
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the verbose
level for module1
and the error
level for module2
:
box_cfg = { log_level = 'warn',
log_modules = {
module1 = 'verbose',
module2 = 'error' }
}
To create custom loggers, call the log.new() function:
-- Creates new loggers --
module1_log = require('log').new('module1')
module2_log = require('log').new('module2')
Given that module1
has the verbose
logging level and module2
has the error
level, calling module1_log.info()
shows a message but module2_log.info()
is swallowed:
-- Prints 'info' messages --
module1_log.info('Info message from module1')
--[[
[16300] main/103/interactive/module1 I> Info message from module1
---
...
--]]
-- Swallows 'debug' messages --
module1_log.debug('Debug message from module1')
--[[
---
...
--]]
-- Swallows 'info' messages --
module2_log.info('Info message from module2')
--[[
---
...
--]]
Example 3: Set a log level for C modules
In the example below, the box_cfg
variable contains logging settings that can be passed to the box.cfg()
function.
This example shows how to set the info
level for the tarantool
module:
box_cfg = { log_level = 'warn',
log_modules = { tarantool = 'info' } }
The specified level affects messages logged from C modules:
ffi = require('ffi')
-- Prints 'info' messages --
ffi.C._say(ffi.C.S_INFO, nil, 0, nil, 'Info message from C module')
--[[
[6024] main/103/interactive I> Info message from C module
---
...
--]]
-- Swallows 'debug' messages --
ffi.C._say(ffi.C.S_DEBUG, nil, 0, nil, 'Debug message from C module')
--[[
---
...
--]]
The example above uses the LuaJIT ffi library to call C functions provided by the say
module.
This example illustrates how «rotation» works, that is, what happens when the server
instance is writing to a log and signals are used when archiving it.
Start with two terminal shells: Terminal #1 and Terminal #2.
In Terminal #1, start an interactive Tarantool session.
Then, use the log
property to send logs to Log_file
and
call log.info
to put a message in the log file.
box.cfg{log='Log_file'}
log = require('log')
log.info('Log Line #1')
In Terminal #2, use the mv
command to rename the log file to Log_file.bak
.
mv Log_file Log_file.bak
As a result, the next log message will go to Log_file.bak
.
Go back to Terminal #1 and put a message «Log Line #2» in the log file.
log.info('Log Line #2')
In Terminal #2, use ps
to find the process ID of the Tarantool instance.
ps -A | grep tarantool
In Terminal #2, execute kill -HUP
to send a SIGHUP signal to the Tarantool instance.
Tarantool will open Log_file
again, and the next log message will go to Log_file
.
kill -HUP process_id
The same effect could be accomplished by calling log.rotate.
In Terminal #1, put a message «Log Line #3» in the log file.
log.info('Log Line #3')
In Terminal #2, use less
to examine files.
Log_file.bak
will have the following lines …
2015-11-30 15:13:06.373 [27469] main/101/interactive I> Log Line #1`
2015-11-30 15:14:25.973 [27469] main/101/interactive I> Log Line #2`
… and Log_file
will look like this:
log file has been reopened
2015-11-30 15:15:32.629 [27469] main/101/interactive I> Log Line #3
Audit log
Enterprise Edition
Audit log features are available in the Enterprise Edition only.
The audit_*
parameters define configuration related to audit logging.
-
audit_extract_key
¶
Since: 3.0.0.
If set to true
, the audit subsystem extracts and prints only the primary key instead of full
tuples in DML events (space_insert
, space_replace
, space_delete
).
Otherwise, full tuples are logged.
The option may be useful in case tuples are big.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_AUDIT_EXTRACT_KEY
-
audit_filter
¶
Enable logging for a specified subset of audit events.
This option accepts the following values:
- Event names (for example,
password_change
). For details, see Audit log events.
- Event groups (for example,
audit
). For details, see Event groups.
The option contains either one value from Possible values
section (see below) or a combination of them.
To enable custom audit log events, specify the custom
value in this option.
The default value is compatibility
, which enables logging of all events available before 2.10.0.
Example
box.cfg{
audit_log = 'audit.log',
audit_filter = 'audit,auth,priv,password_change,access_denied'
}
Type: array
Possible values: „all“, „audit“, „auth“, „priv“, „ddl“, „dml“, „data_operations“, „compatibility“,
„audit_enable“, „auth_ok“, „auth_fail“, „disconnect“, „user_create“, „user_drop“, „role_create“, „role_drop“,
„user_disable“, „user_enable“, „user_grant_rights“, „role_grant_rights“, „role_revoke_rights“, „password_change“,
„access_denied“, „eval“, „call“, „space_select“, „space_create“, „space_alter“, „space_drop“, „space_insert“,
„space_replace“, „space_delete“, „custom“
Default: „compatibility“
Environment variable: TT_AUDIT_FILTER
-
audit_format
¶
Specify the format that is used for the audit log events – plain text, CSV or JSON format.
Plain text is used by default. This human-readable format can be efficiently compressed.
box.cfg{audit_log = 'audit.log', audit_format = 'plain'}
Example
remote: session_type:background module:common.admin.auth user: type:custom_tdg_audit tag:tdg_severity_INFO description:[5e35b406-4274-4903-857b-c80115275940] subj: "anonymous", msg: "Access granted to anonymous user"
The JSON format is more convenient to receive log events, analyze them and integrate them with other systems if needed.
box.cfg{audit_log = 'audit.log', audit_format = 'json'}
Example
{"time": "2022-11-17T21:55:49.880+0300", "remote": "", "session_type": "background", "module": "common.admin.auth", "user": "", "type": "custom_tdg_audit", "tag": "tdg_severity_INFO", "description": "[c26cd11a-3342-4ce6-8f0b-a4b222268b9d] subj: \"anonymous\", msg: \"Access granted to anonymous user\""}
Using the CSV format allows you to view audit log events in tabular form.
box.cfg{audit_log = 'audit.log', audit_format = 'csv'}
Example
2022-11-17T21:58:03.131+0300,,background,common.admin.auth,,,custom_tdg_audit,tdg_severity_INFO,"[b3dfe2a3-ec29-4e61-b747-eb2332c83b2e] subj: ""anonymous"", msg: ""Access granted to anonymous user"""
Тип: строка
Possible values: „json“, „csv“, „plain“
Default: „json“
Environment variable: TT_AUDIT_FORMAT
-
audit_log
¶
Enable audit logging and define the log location.
This option accepts a string value that allows you to define the log location.
The following locations are supported:
- File: to write audit logs to a file, specify a path to a file (with an optional
file
prefix)
- Pipeline: to start a program and write audit logs to it, specify a program name (with
|
or pipe
prefix)
- System log: to write audit logs to a system log, specify a message for
syslogd
(with syslog
prefix)
See the examples below.
By default, audit logging is disabled.
Example: Writing to a file
box.cfg{audit_log = 'audit_tarantool.log'}
-- or
box.cfg{audit_log = 'file:audit_tarantool.log'}
This opens the audit_tarantool.log
file for output in the server’s default directory.
If the audit_log
string has no prefix or the prefix file:
, the string is interpreted as a file path.
If you log to a file, Tarantool will reopen the audit log at SIGHUP.
Example: Sending to a pipeline
box.cfg{audit_log = '| cronolog audit_tarantool.log'}
-- or
box.cfg{audit_log = 'pipe: cronolog audit_tarantool.log'}'
This starts the cronolog program when the server starts
and sends all audit_log
messages to cronolog’s standard input (stdin
).
If the audit_log
string starts with „|“ or contains the prefix pipe:
,
the string is interpreted as a Unix pipeline.
If log is a program, check out its pid and send it a signal to rotate logs.
Example: Writing to a system log
Предупреждение
Below is an example of writing audit logs to a directory shared with the system logs.
Tarantool allows this option, but it is not recommended to do this to avoid difficulties
when working with audit logs. System and audit logs should be written separately.
To do this, create separate paths and specify them.
This sample configuration sends the audit log to syslog:
box.cfg{audit_log = 'syslog:identity=tarantool'}
-- or
box.cfg{audit_log = 'syslog:facility=user'}
-- or
box.cfg{audit_log = 'syslog:identity=tarantool,facility=user'}
-- or
box.cfg{audit_log = 'syslog:server=unix:/dev/log'}
If the audit_log
string starts with «syslog:»,
it is interpreted as a message for the syslogd program,
which normally runs in the background of any Unix-like platform.
The setting can be „syslog:“, „syslog:facility=…“, „syslog:identity=…“, „syslog:server=…“ or a combination.
The syslog:identity
setting is an arbitrary string that is placed at the beginning of all messages.
The default value is tarantool
.
The syslog:facility
setting is currently ignored, but will be used in the future.
The value must be one of the syslog keywords
that tell syslogd
where to send the message.
The possible values are auth
, authpriv
, cron
, daemon
, ftp
,
kern
, lpr
, mail
, news
, security
, syslog
, user
, uucp
,
local0
, local1
, local2
, local3
, local4
, local5
, local6
, local7
.
The default value is local7
.
The syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path starting with «unix:» or an ipv4 port number.
The default socket value is /dev/log
(on Linux) or /var/run/syslog
(on Mac OS).
The default port value is 514, which is the UDP port.
An example of a Tarantool audit log entry in the syslog:
09:32:52 tarantool_audit: {"time": "2024-02-08T09:32:52.190+0300", "uuid": "94454e46-9a0e-493a-bb9f-d59e44a43581", "severity": "INFO", "remote": "unix/:(socket)", "session_type": "console", "module": "tarantool", "user": "admin", "type": "space_create", "tag": "", "description": "Create space bands"}
Тип: строка
Possible values: see the string format above
Default: „nill“
Environment variable: TT_AUDIT_LOG
-
audit_nonblock
¶
Specify the logging behavior if the system is not ready to write.
If set to true
, Tarantool does not block during logging if the system is non-writable and writes a message instead.
Using this value may improve logging performance at the cost of losing some log messages.
Примечание
The option only has an effect if the audit_log is set to syslog
or pipe
.
Setting audit_nonblock
to true
is not allowed if the output is to a file.
In this case, set audit_nonblock
to false
.
Тип: логический
По умолчанию: true
Environment variable: TT_AUDIT_NONBLOCK
-
audit_spaces
¶
Since: 3.0.0.
The array of space names for which data operation events (space_select
, space_insert
, space_replace
,
space_delete
) should be logged. The array accepts string values.
If set to box.NULL, the data operation events are logged for all spaces.
Example
In the example, only the events of bands
and singers
spaces are logged:
box.cfg{
audit_spaces = 'bands,singers'
}
Type: array
Default: box.NULL
Environment variable: TT_AUDIT_SPACES
Authentication
Enterprise Edition
Authentication features are supported by the Enterprise Edition only.
- auth_delay
- auth_retries
- auth_type
- disable_guest
- password_min_length
- password_enforce_uppercase
- password_enforce_lowercase
- password_enforce_digits
- password_enforce_specialchars
- password_lifetime_days
- password_history_length
-
auth_delay
¶
Since 2.11.0.
Specify a period of time (in seconds) that a specific user should wait
for the next attempt after failed authentication.
With the configuration below, Tarantool refuses the authentication attempt if the previous
attempt was less than 5 seconds ago.
box.cfg{ auth_delay = 5 }
Тип: число
Default: 0
Environment variable: TT_AUTH_DELAY
Динамический: да
-
auth_retries
¶
Since 3.0.0.
Specify the maximum number of authentication retries allowed before auth_delay
is enforced.
The default value is 0, which means auth_delay
is enforced after the first failed authentication attempt.
The retry counter is reset after auth_delay
seconds since the first failed attempt.
For example, if a client tries to authenticate fewer than auth_retries
times within auth_delay
seconds, no authentication delay is enforced.
The retry counter is also reset after any successful authentication attempt.
Тип: число
Default: 0
Environment variable: TT_AUTH_RETRIES
Динамический: да
-
auth_type
¶
Since 2.11.0.
Specify an authentication protocol:
- „chap-sha1“: use the CHAP protocol to authenticate users with
SHA-1
hashing applied to passwords.
- „pap-sha256“: use PAP authentication with the
SHA256
hashing algorithm.
For new users, the box.schema.user.create method
will generate authentication data using PAP-SHA256
.
For existing users, you need to reset a password using
box.schema.user.passwd
to use the new authentication protocol.
Тип: строка
Default value: „chap-sha1“
Environment variable: TT_AUTH_TYPE
Динамический: да
-
disable_guest
¶
Since 2.11.0.
If true, disables access over remote connections
from unauthenticated or guest access users.
This option affects both
net.box and
replication connections.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_DISABLE_GUEST
Динамический: да
-
password_min_length
¶
Since 2.11.0.
Specify the minimum number of characters for a password.
The following example shows how to set the minimum password length to 10.
box.cfg{ password_min_length = 10 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_MIN_LENGTH
Динамический: да
-
password_enforce_uppercase
¶
Since 2.11.0.
If true, a password should contain uppercase letters (A-Z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_UPPERCASE
Динамический: да
-
password_enforce_lowercase
¶
Since 2.11.0.
If true, a password should contain lowercase letters (a-z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_LOWERCASE
Динамический: да
-
password_enforce_digits
¶
Since 2.11.0.
If true, a password should contain digits (0-9).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_DIGITS
Динамический: да
-
password_enforce_specialchars
¶
Since 2.11.0.
If true, a password should contain at least one special character (such as &|?!@$
).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARS
Динамический: да
-
password_lifetime_days
¶
Since 2.11.0.
Specify the maximum period of time (in days) a user can use the same password.
When this period ends, a user gets the «Password expired» error on a login attempt.
To restore access for such users, use box.schema.user.passwd.
Примечание
The default 0 value means that a password never expires.
The example below shows how to set a maximum password age to 365 days.
box.cfg{ password_lifetime_days = 365 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_LIFETIME_DAYS
Динамический: да
-
password_history_length
¶
Since 2.11.0.
Specify the number of unique new user passwords before an old password can be reused.
In the example below, a new password should differ from the last three passwords.
box.cfg{ password_history_length = 3 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_HISTORY_LENGTH
Динамический: да
Примечание
Tarantool uses the auth_history
field in the
box.space._user
system space to store user passwords.
Flight recorder
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶
Since 2.11.0.
Enable the flight recorder.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FLIGHTREC_ENABLED
Динамический: да
-
flightrec_logs_size
¶
Since 2.11.0.
Specify the size (in bytes) of the log storage.
You can set this option to 0
to disable the log storage.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_LOGS_SIZE
Динамический: да
-
flightrec_logs_max_msg_size
¶
Since 2.11.0.
Specify the maximum size (in bytes) of the log message.
The log message is truncated if its size exceeds this limit.
Тип: целое число
Default: 4096
Maximum: 16384
Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZE
Динамический: да
-
flightrec_logs_log_level
¶
Since 2.11.0.
Specify the level of detail the log has.
You can learn more about log levels from the log_level
option description.
Note that the flightrec_logs_log_level
value might differ from log_level
.
Тип: целое число
Default: 6
Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVEL
Динамический: да
-
flightrec_metrics_period
¶
Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump.
So, this value defines how much historical metrics data is collected up to the moment of crash.
The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое число
Default: 180
Environment variable: TT_FLIGHTREC_METRICS_PERIOD
Динамический: да
-
flightrec_metrics_interval
¶
Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics.
This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB,
you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: число
По умолчанию: 1.0
Minimum: 0.001
Environment variable: TT_FLIGHTREC_METRICS_INTERVAL
Динамический: да
-
flightrec_requests_size
¶
Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data.
You can set this parameter to 0
to disable a storage of requests and responses.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_REQUESTS_SIZE
Динамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
This section provides information on how to configure options related to logging. You can also use the log module to configure logging in your application.
-
log_level
¶ Since version 1.6.2.
Specify the level of detail the log has. There are the following levels:
- 0 –
fatal
- 1 –
syserror
- 2 –
error
- 3 –
crit
- 4 –
warn
- 5 –
info
- 6 –
verbose
- 7 –
debug
By setting
log_level
, you can enable logging of all events with severities above or equal to the given level. Tarantool prints logs to the standard error stream by default. This can be changed with the log configuration parameter.Type: integer, stringПо умолчанию: 5Environment variable: TT_LOG_LEVELДинамический: даПримечание
Prior to Tarantool 1.7.5 there were only six levels and
DEBUG
was level 6. Starting with Tarantool 1.7.5,VERBOSE
is level 6 andDEBUG
is level 7.VERBOSE
is a new level for monitoring repetitive events which would cause too much log writing ifINFO
were used instead.- 0 –
-
log
¶ Since version 1.7.4.
By default, Tarantool sends the log to the standard error stream (
stderr
). Iflog
is specified, Tarantool can send the log to a:- file
- pipe
- system logger
Example 1: sending the log to the
tarantool.log
file.box.cfg{log = 'tarantool.log'} -- или box.cfg{log = 'file:tarantool.log'}
This opens the file
tarantool.log
for output on the server’s default directory. If thelog
string has no prefix or has the prefix «file:», then the string is interpreted as a file path.Example 2: sending the log to a pipe.
box.cfg{log = '| cronolog tarantool.log'} -- or box.cfg{log = 'pipe: cronolog tarantool.log'}
This starts the program cronolog when the server starts, and sends all log messages to the standard input (
stdin
) ofcronolog
. If thelog
string begins with „|“ or has the prefix «pipe:», then the string is interpreted as a Unix pipeline.Example 3: sending the log to syslog.
box.cfg{log = 'syslog:identity=tarantool'} -- или box.cfg{log = 'syslog:facility=user'} -- или box.cfg{log = 'syslog:identity=tarantool,facility=user'} -- или box.cfg{log = 'syslog:server=unix:/dev/log'}
If the
log
string begins with «syslog:», then it is interpreted as a message for the syslogd program, which normally is running in the background on any Unix-like platform. The setting can besyslog:
,syslog:facility=...
,syslog:identity=...
,syslog:server=...
, or a combination.- The
syslog:identity
setting is an arbitrary string, which is placed at the beginning of all messages. The default value is «tarantool». - В настоящий момент настройка
syslog:facility
не учитывается, но будет использоваться в дальнейшем. Ее значением должно быть одно из ключевых слов syslog, которые сообщают программе syslogd, куда отправлять сообщение. Возможные значения: auth, authpriv, cron, daemon, ftp, kern, lpr, mail, news, security, syslog, user, uucp, local0, local1, local2, local3, local4, local5, local6, local7. По умолчанию: user. - The
syslog:server
setting is the locator for the syslog server. It can be a Unix socket path beginning with «unix:», or an ipv4 port number. The default socket value is:dev/log
(on Linux) or/var/run/syslog
(on macOS). The default port value is: 514, the UDP port.
When logging to a file, Tarantool reopens the log on SIGHUP. When log is a program, its PID is saved in the log.pid variable. You need to send it a signal to rotate logs.
Тип: строкаПо умолчанию: nullEnvironment variable: TT_LOGДинамический: нет
-
log_nonblock
¶ Since version 1.7.4.
If
log_nonblock
equals true, Tarantool does not block during logging when the system is not ready for writing, and drops the message instead. If log_level is high, and many messages go to the log, settinglog_nonblock
to true may improve logging performance at the cost of some log messages getting lost.This parameter has effect only if log is configured to send logs to a pipe or system logger. The default
log_nonblock
value is nil, which means that blocking behavior corresponds to the logger type:- false for
stderr
and file loggers. - true for a pipe and system logger.
This is a behavior change: in earlier versions of the Tarantool server, the default value was true.
Тип: логическийПо умолчанию: nilEnvironment variable: TT_LOG_NONBLOCKДинамический: нет- false for
-
too_long_threshold
¶ Since version 1.6.2.
If processing a request takes longer than the given value (in seconds), warn about it in the log. Has effect only if log_level is greater than or equal to 4 (WARNING).
Тип: число с плавающей запятойПо умолчанию: 0.5Environment variable: TT_TOO_LONG_THRESHOLDДинамический: да
-
log_format
¶ Since version 1.7.6.
Log entries have two possible formats:
- „plain“ (по умолчанию) или
- „json“ (более детально с JSON-метками).
Here is what a log entry looks like if
box.cfg{log_format='plain'}
:2017-10-16 11:36:01.508 [18081] main/101/interactive I> set 'log_format' configuration option to "plain"
Here is what a log entry looks like if
box.cfg{log_format='json'}
:{"time": "2017-10-16T11:36:17.996-0600", "level": "INFO", "message": "set 'log_format' configuration option to \"json\"", "pid": 18081,| "cord_name": "main", "fiber_id": 101, "fiber_name": "interactive", "file": "builtin\/box\/load_cfg.lua", "line": 317}
The
log_format='plain'
entry has a time value, process ID, cord name, fiber_id, fiber_name, log level, and message.The
log_format='json'
entry has the same fields along with their labels, and in addition has the file name and line number of the Tarantool source.Тип: строкаПо умолчанию: „plain“Environment variable: TT_LOG_FORMATДинамический: да
-
log_modules
¶ Since version 2.11.0.
Configure the specified log levels (log_level) for different modules.
You can specify a logging level for the following module types:
- Modules (files) that use the default logger. Example: Set log levels for files that use the default logger.
- Modules that use custom loggers created using the log.new() function. Example: Set log levels for modules that use custom loggers.
- The
tarantool
module that enables you to configure the logging level for Tarantool core messages. Specifically, it configures the logging level for messages logged from non-Lua code, including C modules. Example: Set a log level for C modules.
Type: tableDefault: blankEnvironment variable: TT_LOG_MODULESДинамический: даExample 1: Set log levels for files that use the default logger
Suppose you have two identical modules placed by the following paths:
test/logging/module1.lua
andtest/logging/module2.lua
. These modules use the default logger and look as follows:return { say_hello = function() local log = require('log') log.info('Info message from module1') end }
To load these modules in your application, you need to add the corresponding
require
directives:module1 = require('test.logging.module1') module2 = require('test.logging.module2')
To configure logging levels, you need to provide module names corresponding to paths to these modules. In the example below, the
box_cfg
variable contains logging settings that can be passed to thebox.cfg()
function:box_cfg = { log_modules = { ['test.logging.module1'] = 'verbose', ['test.logging.module2'] = 'error' } }
Given that
module1
has theverbose
logging level andmodule2
has theerror
level, callingmodule1.say_hello()
shows a message butmodule2.say_hello()
is swallowed:-- Prints 'info' messages -- module1.say_hello() --[[ [92617] main/103/interactive/test.logging.module1 I> Info message from module1 --- ... --]] -- Swallows 'info' messages -- module2.say_hello() --[[ --- ... --]]
Example 2: Set log levels for modules that use custom loggers
In the example below, the
box_cfg
variable contains logging settings that can be passed to thebox.cfg()
function. This example shows how to set theverbose
level formodule1
and theerror
level formodule2
:box_cfg = { log_level = 'warn', log_modules = { module1 = 'verbose', module2 = 'error' } }
To create custom loggers, call the log.new() function:
-- Creates new loggers -- module1_log = require('log').new('module1') module2_log = require('log').new('module2')
Given that
module1
has theverbose
logging level andmodule2
has theerror
level, callingmodule1_log.info()
shows a message butmodule2_log.info()
is swallowed:-- Prints 'info' messages -- module1_log.info('Info message from module1') --[[ [16300] main/103/interactive/module1 I> Info message from module1 --- ... --]] -- Swallows 'debug' messages -- module1_log.debug('Debug message from module1') --[[ --- ... --]] -- Swallows 'info' messages -- module2_log.info('Info message from module2') --[[ --- ... --]]
Example 3: Set a log level for C modules
In the example below, the
box_cfg
variable contains logging settings that can be passed to thebox.cfg()
function. This example shows how to set theinfo
level for thetarantool
module:box_cfg = { log_level = 'warn', log_modules = { tarantool = 'info' } }
The specified level affects messages logged from C modules:
ffi = require('ffi') -- Prints 'info' messages -- ffi.C._say(ffi.C.S_INFO, nil, 0, nil, 'Info message from C module') --[[ [6024] main/103/interactive I> Info message from C module --- ... --]] -- Swallows 'debug' messages -- ffi.C._say(ffi.C.S_DEBUG, nil, 0, nil, 'Debug message from C module') --[[ --- ... --]]
The example above uses the LuaJIT ffi library to call C functions provided by the
say
module.
This example illustrates how «rotation» works, that is, what happens when the server instance is writing to a log and signals are used when archiving it.
Start with two terminal shells: Terminal #1 and Terminal #2.
In Terminal #1, start an interactive Tarantool session. Then, use the
log
property to send logs toLog_file
and calllog.info
to put a message in the log file.box.cfg{log='Log_file'} log = require('log') log.info('Log Line #1')
In Terminal #2, use the
mv
command to rename the log file toLog_file.bak
.mv Log_file Log_file.bak
As a result, the next log message will go to
Log_file.bak
.Go back to Terminal #1 and put a message «Log Line #2» in the log file.
log.info('Log Line #2')
In Terminal #2, use
ps
to find the process ID of the Tarantool instance.ps -A | grep tarantool
In Terminal #2, execute
kill -HUP
to send a SIGHUP signal to the Tarantool instance. Tarantool will openLog_file
again, and the next log message will go toLog_file
.kill -HUP process_id
The same effect could be accomplished by calling log.rotate.
In Terminal #1, put a message «Log Line #3» in the log file.
log.info('Log Line #3')
In Terminal #2, use
less
to examine files.Log_file.bak
will have the following lines …2015-11-30 15:13:06.373 [27469] main/101/interactive I> Log Line #1` 2015-11-30 15:14:25.973 [27469] main/101/interactive I> Log Line #2`
… and
Log_file
will look like this:log file has been reopened 2015-11-30 15:15:32.629 [27469] main/101/interactive I> Log Line #3
Audit log
Enterprise Edition
Audit log features are available in the Enterprise Edition only.
The audit_*
parameters define configuration related to audit logging.
-
audit_extract_key
¶
Since: 3.0.0.
If set to true
, the audit subsystem extracts and prints only the primary key instead of full
tuples in DML events (space_insert
, space_replace
, space_delete
).
Otherwise, full tuples are logged.
The option may be useful in case tuples are big.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_AUDIT_EXTRACT_KEY
-
audit_filter
¶
Enable logging for a specified subset of audit events.
This option accepts the following values:
- Event names (for example,
password_change
). For details, see Audit log events.
- Event groups (for example,
audit
). For details, see Event groups.
The option contains either one value from Possible values
section (see below) or a combination of them.
To enable custom audit log events, specify the custom
value in this option.
The default value is compatibility
, which enables logging of all events available before 2.10.0.
Example
box.cfg{
audit_log = 'audit.log',
audit_filter = 'audit,auth,priv,password_change,access_denied'
}
Type: array
Possible values: „all“, „audit“, „auth“, „priv“, „ddl“, „dml“, „data_operations“, „compatibility“,
„audit_enable“, „auth_ok“, „auth_fail“, „disconnect“, „user_create“, „user_drop“, „role_create“, „role_drop“,
„user_disable“, „user_enable“, „user_grant_rights“, „role_grant_rights“, „role_revoke_rights“, „password_change“,
„access_denied“, „eval“, „call“, „space_select“, „space_create“, „space_alter“, „space_drop“, „space_insert“,
„space_replace“, „space_delete“, „custom“
Default: „compatibility“
Environment variable: TT_AUDIT_FILTER
-
audit_format
¶
Specify the format that is used for the audit log events – plain text, CSV or JSON format.
Plain text is used by default. This human-readable format can be efficiently compressed.
box.cfg{audit_log = 'audit.log', audit_format = 'plain'}
Example
remote: session_type:background module:common.admin.auth user: type:custom_tdg_audit tag:tdg_severity_INFO description:[5e35b406-4274-4903-857b-c80115275940] subj: "anonymous", msg: "Access granted to anonymous user"
The JSON format is more convenient to receive log events, analyze them and integrate them with other systems if needed.
box.cfg{audit_log = 'audit.log', audit_format = 'json'}
Example
{"time": "2022-11-17T21:55:49.880+0300", "remote": "", "session_type": "background", "module": "common.admin.auth", "user": "", "type": "custom_tdg_audit", "tag": "tdg_severity_INFO", "description": "[c26cd11a-3342-4ce6-8f0b-a4b222268b9d] subj: \"anonymous\", msg: \"Access granted to anonymous user\""}
Using the CSV format allows you to view audit log events in tabular form.
box.cfg{audit_log = 'audit.log', audit_format = 'csv'}
Example
2022-11-17T21:58:03.131+0300,,background,common.admin.auth,,,custom_tdg_audit,tdg_severity_INFO,"[b3dfe2a3-ec29-4e61-b747-eb2332c83b2e] subj: ""anonymous"", msg: ""Access granted to anonymous user"""
Тип: строка
Possible values: „json“, „csv“, „plain“
Default: „json“
Environment variable: TT_AUDIT_FORMAT
-
audit_log
¶
Enable audit logging and define the log location.
This option accepts a string value that allows you to define the log location.
The following locations are supported:
- File: to write audit logs to a file, specify a path to a file (with an optional
file
prefix)
- Pipeline: to start a program and write audit logs to it, specify a program name (with
|
or pipe
prefix)
- System log: to write audit logs to a system log, specify a message for
syslogd
(with syslog
prefix)
See the examples below.
By default, audit logging is disabled.
Example: Writing to a file
box.cfg{audit_log = 'audit_tarantool.log'}
-- or
box.cfg{audit_log = 'file:audit_tarantool.log'}
This opens the audit_tarantool.log
file for output in the server’s default directory.
If the audit_log
string has no prefix or the prefix file:
, the string is interpreted as a file path.
If you log to a file, Tarantool will reopen the audit log at SIGHUP.
Example: Sending to a pipeline
box.cfg{audit_log = '| cronolog audit_tarantool.log'}
-- or
box.cfg{audit_log = 'pipe: cronolog audit_tarantool.log'}'
This starts the cronolog program when the server starts
and sends all audit_log
messages to cronolog’s standard input (stdin
).
If the audit_log
string starts with „|“ or contains the prefix pipe:
,
the string is interpreted as a Unix pipeline.
If log is a program, check out its pid and send it a signal to rotate logs.
Example: Writing to a system log
Предупреждение
Below is an example of writing audit logs to a directory shared with the system logs.
Tarantool allows this option, but it is not recommended to do this to avoid difficulties
when working with audit logs. System and audit logs should be written separately.
To do this, create separate paths and specify them.
This sample configuration sends the audit log to syslog:
box.cfg{audit_log = 'syslog:identity=tarantool'}
-- or
box.cfg{audit_log = 'syslog:facility=user'}
-- or
box.cfg{audit_log = 'syslog:identity=tarantool,facility=user'}
-- or
box.cfg{audit_log = 'syslog:server=unix:/dev/log'}
If the audit_log
string starts with «syslog:»,
it is interpreted as a message for the syslogd program,
which normally runs in the background of any Unix-like platform.
The setting can be „syslog:“, „syslog:facility=…“, „syslog:identity=…“, „syslog:server=…“ or a combination.
The syslog:identity
setting is an arbitrary string that is placed at the beginning of all messages.
The default value is tarantool
.
The syslog:facility
setting is currently ignored, but will be used in the future.
The value must be one of the syslog keywords
that tell syslogd
where to send the message.
The possible values are auth
, authpriv
, cron
, daemon
, ftp
,
kern
, lpr
, mail
, news
, security
, syslog
, user
, uucp
,
local0
, local1
, local2
, local3
, local4
, local5
, local6
, local7
.
The default value is local7
.
The syslog:server
setting is the locator for the syslog server.
It can be a Unix socket path starting with «unix:» or an ipv4 port number.
The default socket value is /dev/log
(on Linux) or /var/run/syslog
(on Mac OS).
The default port value is 514, which is the UDP port.
An example of a Tarantool audit log entry in the syslog:
09:32:52 tarantool_audit: {"time": "2024-02-08T09:32:52.190+0300", "uuid": "94454e46-9a0e-493a-bb9f-d59e44a43581", "severity": "INFO", "remote": "unix/:(socket)", "session_type": "console", "module": "tarantool", "user": "admin", "type": "space_create", "tag": "", "description": "Create space bands"}
Тип: строка
Possible values: see the string format above
Default: „nill“
Environment variable: TT_AUDIT_LOG
-
audit_nonblock
¶
Specify the logging behavior if the system is not ready to write.
If set to true
, Tarantool does not block during logging if the system is non-writable and writes a message instead.
Using this value may improve logging performance at the cost of losing some log messages.
Примечание
The option only has an effect if the audit_log is set to syslog
or pipe
.
Setting audit_nonblock
to true
is not allowed if the output is to a file.
In this case, set audit_nonblock
to false
.
Тип: логический
По умолчанию: true
Environment variable: TT_AUDIT_NONBLOCK
-
audit_spaces
¶
Since: 3.0.0.
The array of space names for which data operation events (space_select
, space_insert
, space_replace
,
space_delete
) should be logged. The array accepts string values.
If set to box.NULL, the data operation events are logged for all spaces.
Example
In the example, only the events of bands
and singers
spaces are logged:
box.cfg{
audit_spaces = 'bands,singers'
}
Type: array
Default: box.NULL
Environment variable: TT_AUDIT_SPACES
Authentication
Enterprise Edition
Authentication features are supported by the Enterprise Edition only.
- auth_delay
- auth_retries
- auth_type
- disable_guest
- password_min_length
- password_enforce_uppercase
- password_enforce_lowercase
- password_enforce_digits
- password_enforce_specialchars
- password_lifetime_days
- password_history_length
-
auth_delay
¶
Since 2.11.0.
Specify a period of time (in seconds) that a specific user should wait
for the next attempt after failed authentication.
With the configuration below, Tarantool refuses the authentication attempt if the previous
attempt was less than 5 seconds ago.
box.cfg{ auth_delay = 5 }
Тип: число
Default: 0
Environment variable: TT_AUTH_DELAY
Динамический: да
-
auth_retries
¶
Since 3.0.0.
Specify the maximum number of authentication retries allowed before auth_delay
is enforced.
The default value is 0, which means auth_delay
is enforced after the first failed authentication attempt.
The retry counter is reset after auth_delay
seconds since the first failed attempt.
For example, if a client tries to authenticate fewer than auth_retries
times within auth_delay
seconds, no authentication delay is enforced.
The retry counter is also reset after any successful authentication attempt.
Тип: число
Default: 0
Environment variable: TT_AUTH_RETRIES
Динамический: да
-
auth_type
¶
Since 2.11.0.
Specify an authentication protocol:
- „chap-sha1“: use the CHAP protocol to authenticate users with
SHA-1
hashing applied to passwords.
- „pap-sha256“: use PAP authentication with the
SHA256
hashing algorithm.
For new users, the box.schema.user.create method
will generate authentication data using PAP-SHA256
.
For existing users, you need to reset a password using
box.schema.user.passwd
to use the new authentication protocol.
Тип: строка
Default value: „chap-sha1“
Environment variable: TT_AUTH_TYPE
Динамический: да
-
disable_guest
¶
Since 2.11.0.
If true, disables access over remote connections
from unauthenticated or guest access users.
This option affects both
net.box and
replication connections.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_DISABLE_GUEST
Динамический: да
-
password_min_length
¶
Since 2.11.0.
Specify the minimum number of characters for a password.
The following example shows how to set the minimum password length to 10.
box.cfg{ password_min_length = 10 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_MIN_LENGTH
Динамический: да
-
password_enforce_uppercase
¶
Since 2.11.0.
If true, a password should contain uppercase letters (A-Z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_UPPERCASE
Динамический: да
-
password_enforce_lowercase
¶
Since 2.11.0.
If true, a password should contain lowercase letters (a-z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_LOWERCASE
Динамический: да
-
password_enforce_digits
¶
Since 2.11.0.
If true, a password should contain digits (0-9).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_DIGITS
Динамический: да
-
password_enforce_specialchars
¶
Since 2.11.0.
If true, a password should contain at least one special character (such as &|?!@$
).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARS
Динамический: да
-
password_lifetime_days
¶
Since 2.11.0.
Specify the maximum period of time (in days) a user can use the same password.
When this period ends, a user gets the «Password expired» error on a login attempt.
To restore access for such users, use box.schema.user.passwd.
Примечание
The default 0 value means that a password never expires.
The example below shows how to set a maximum password age to 365 days.
box.cfg{ password_lifetime_days = 365 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_LIFETIME_DAYS
Динамический: да
-
password_history_length
¶
Since 2.11.0.
Specify the number of unique new user passwords before an old password can be reused.
In the example below, a new password should differ from the last three passwords.
box.cfg{ password_history_length = 3 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_HISTORY_LENGTH
Динамический: да
Примечание
Tarantool uses the auth_history
field in the
box.space._user
system space to store user passwords.
Flight recorder
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶
Since 2.11.0.
Enable the flight recorder.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FLIGHTREC_ENABLED
Динамический: да
-
flightrec_logs_size
¶
Since 2.11.0.
Specify the size (in bytes) of the log storage.
You can set this option to 0
to disable the log storage.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_LOGS_SIZE
Динамический: да
-
flightrec_logs_max_msg_size
¶
Since 2.11.0.
Specify the maximum size (in bytes) of the log message.
The log message is truncated if its size exceeds this limit.
Тип: целое число
Default: 4096
Maximum: 16384
Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZE
Динамический: да
-
flightrec_logs_log_level
¶
Since 2.11.0.
Specify the level of detail the log has.
You can learn more about log levels from the log_level
option description.
Note that the flightrec_logs_log_level
value might differ from log_level
.
Тип: целое число
Default: 6
Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVEL
Динамический: да
-
flightrec_metrics_period
¶
Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump.
So, this value defines how much historical metrics data is collected up to the moment of crash.
The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое число
Default: 180
Environment variable: TT_FLIGHTREC_METRICS_PERIOD
Динамический: да
-
flightrec_metrics_interval
¶
Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics.
This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB,
you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: число
По умолчанию: 1.0
Minimum: 0.001
Environment variable: TT_FLIGHTREC_METRICS_INTERVAL
Динамический: да
-
flightrec_requests_size
¶
Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data.
You can set this parameter to 0
to disable a storage of requests and responses.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_REQUESTS_SIZE
Динамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
Enterprise Edition
Audit log features are available in the Enterprise Edition only.
The audit_*
parameters define configuration related to audit logging.
-
audit_extract_key
¶ Since: 3.0.0.
If set to
true
, the audit subsystem extracts and prints only the primary key instead of full tuples in DML events (space_insert
,space_replace
,space_delete
). Otherwise, full tuples are logged. The option may be useful in case tuples are big.Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_AUDIT_EXTRACT_KEY
-
audit_filter
¶ Enable logging for a specified subset of audit events. This option accepts the following values:
- Event names (for example,
password_change
). For details, see Audit log events. - Event groups (for example,
audit
). For details, see Event groups.
The option contains either one value from
Possible values
section (see below) or a combination of them.To enable custom audit log events, specify the
custom
value in this option.The default value is
compatibility
, which enables logging of all events available before 2.10.0.Example
box.cfg{ audit_log = 'audit.log', audit_filter = 'audit,auth,priv,password_change,access_denied' }
Type: arrayPossible values: „all“, „audit“, „auth“, „priv“, „ddl“, „dml“, „data_operations“, „compatibility“, „audit_enable“, „auth_ok“, „auth_fail“, „disconnect“, „user_create“, „user_drop“, „role_create“, „role_drop“, „user_disable“, „user_enable“, „user_grant_rights“, „role_grant_rights“, „role_revoke_rights“, „password_change“, „access_denied“, „eval“, „call“, „space_select“, „space_create“, „space_alter“, „space_drop“, „space_insert“, „space_replace“, „space_delete“, „custom“Default: „compatibility“Environment variable: TT_AUDIT_FILTER- Event names (for example,
-
audit_format
¶ Specify the format that is used for the audit log events – plain text, CSV or JSON format.
Plain text is used by default. This human-readable format can be efficiently compressed.
box.cfg{audit_log = 'audit.log', audit_format = 'plain'}
Example
remote: session_type:background module:common.admin.auth user: type:custom_tdg_audit tag:tdg_severity_INFO description:[5e35b406-4274-4903-857b-c80115275940] subj: "anonymous", msg: "Access granted to anonymous user"
The JSON format is more convenient to receive log events, analyze them and integrate them with other systems if needed.
box.cfg{audit_log = 'audit.log', audit_format = 'json'}
Example
{"time": "2022-11-17T21:55:49.880+0300", "remote": "", "session_type": "background", "module": "common.admin.auth", "user": "", "type": "custom_tdg_audit", "tag": "tdg_severity_INFO", "description": "[c26cd11a-3342-4ce6-8f0b-a4b222268b9d] subj: \"anonymous\", msg: \"Access granted to anonymous user\""}
Using the CSV format allows you to view audit log events in tabular form.
box.cfg{audit_log = 'audit.log', audit_format = 'csv'}
Example
2022-11-17T21:58:03.131+0300,,background,common.admin.auth,,,custom_tdg_audit,tdg_severity_INFO,"[b3dfe2a3-ec29-4e61-b747-eb2332c83b2e] subj: ""anonymous"", msg: ""Access granted to anonymous user"""
Тип: строкаPossible values: „json“, „csv“, „plain“Default: „json“Environment variable: TT_AUDIT_FORMAT
-
audit_log
¶ Enable audit logging and define the log location.
This option accepts a string value that allows you to define the log location. The following locations are supported:
- File: to write audit logs to a file, specify a path to a file (with an optional
file
prefix) - Pipeline: to start a program and write audit logs to it, specify a program name (with
|
orpipe
prefix) - System log: to write audit logs to a system log, specify a message for
syslogd
(withsyslog
prefix)
See the examples below.
By default, audit logging is disabled.
Example: Writing to a file
box.cfg{audit_log = 'audit_tarantool.log'} -- or box.cfg{audit_log = 'file:audit_tarantool.log'}
This opens the
audit_tarantool.log
file for output in the server’s default directory. If theaudit_log
string has no prefix or the prefixfile:
, the string is interpreted as a file path.If you log to a file, Tarantool will reopen the audit log at SIGHUP.
Example: Sending to a pipeline
box.cfg{audit_log = '| cronolog audit_tarantool.log'} -- or box.cfg{audit_log = 'pipe: cronolog audit_tarantool.log'}'
This starts the cronolog program when the server starts and sends all
audit_log
messages to cronolog’s standard input (stdin
). If theaudit_log
string starts with „|“ or contains the prefixpipe:
, the string is interpreted as a Unix pipeline.If log is a program, check out its pid and send it a signal to rotate logs.
Example: Writing to a system log
Предупреждение
Below is an example of writing audit logs to a directory shared with the system logs. Tarantool allows this option, but it is not recommended to do this to avoid difficulties when working with audit logs. System and audit logs should be written separately. To do this, create separate paths and specify them.
This sample configuration sends the audit log to syslog:
box.cfg{audit_log = 'syslog:identity=tarantool'} -- or box.cfg{audit_log = 'syslog:facility=user'} -- or box.cfg{audit_log = 'syslog:identity=tarantool,facility=user'} -- or box.cfg{audit_log = 'syslog:server=unix:/dev/log'}
If the
audit_log
string starts with «syslog:», it is interpreted as a message for the syslogd program, which normally runs in the background of any Unix-like platform. The setting can be „syslog:“, „syslog:facility=…“, „syslog:identity=…“, „syslog:server=…“ or a combination.The
syslog:identity
setting is an arbitrary string that is placed at the beginning of all messages. The default value istarantool
.The
syslog:facility
setting is currently ignored, but will be used in the future. The value must be one of the syslog keywords that tellsyslogd
where to send the message. The possible values areauth
,authpriv
,cron
,daemon
,ftp
,kern
,lpr
,mail
,news
,security
,syslog
,user
,uucp
,local0
,local1
,local2
,local3
,local4
,local5
,local6
,local7
. The default value islocal7
.The
syslog:server
setting is the locator for the syslog server. It can be a Unix socket path starting with «unix:» or an ipv4 port number. The default socket value is/dev/log
(on Linux) or/var/run/syslog
(on Mac OS). The default port value is 514, which is the UDP port.An example of a Tarantool audit log entry in the syslog:
09:32:52 tarantool_audit: {"time": "2024-02-08T09:32:52.190+0300", "uuid": "94454e46-9a0e-493a-bb9f-d59e44a43581", "severity": "INFO", "remote": "unix/:(socket)", "session_type": "console", "module": "tarantool", "user": "admin", "type": "space_create", "tag": "", "description": "Create space bands"}
Тип: строкаPossible values: see the string format aboveDefault: „nill“Environment variable: TT_AUDIT_LOG- File: to write audit logs to a file, specify a path to a file (with an optional
-
audit_nonblock
¶ Specify the logging behavior if the system is not ready to write. If set to
true
, Tarantool does not block during logging if the system is non-writable and writes a message instead. Using this value may improve logging performance at the cost of losing some log messages.Примечание
The option only has an effect if the audit_log is set to
syslog
orpipe
.Setting
audit_nonblock
totrue
is not allowed if the output is to a file. In this case, setaudit_nonblock
tofalse
.Тип: логическийПо умолчанию: trueEnvironment variable: TT_AUDIT_NONBLOCK
-
audit_spaces
¶ Since: 3.0.0.
The array of space names for which data operation events (
space_select
,space_insert
,space_replace
,space_delete
) should be logged. The array accepts string values. If set to box.NULL, the data operation events are logged for all spaces.Example
In the example, only the events of
bands
andsingers
spaces are logged:box.cfg{ audit_spaces = 'bands,singers' }
Type: arrayDefault: box.NULLEnvironment variable: TT_AUDIT_SPACES
Authentication
Enterprise Edition
Authentication features are supported by the Enterprise Edition only.
- auth_delay
- auth_retries
- auth_type
- disable_guest
- password_min_length
- password_enforce_uppercase
- password_enforce_lowercase
- password_enforce_digits
- password_enforce_specialchars
- password_lifetime_days
- password_history_length
-
auth_delay
¶
Since 2.11.0.
Specify a period of time (in seconds) that a specific user should wait
for the next attempt after failed authentication.
With the configuration below, Tarantool refuses the authentication attempt if the previous
attempt was less than 5 seconds ago.
box.cfg{ auth_delay = 5 }
Тип: число
Default: 0
Environment variable: TT_AUTH_DELAY
Динамический: да
-
auth_retries
¶
Since 3.0.0.
Specify the maximum number of authentication retries allowed before auth_delay
is enforced.
The default value is 0, which means auth_delay
is enforced after the first failed authentication attempt.
The retry counter is reset after auth_delay
seconds since the first failed attempt.
For example, if a client tries to authenticate fewer than auth_retries
times within auth_delay
seconds, no authentication delay is enforced.
The retry counter is also reset after any successful authentication attempt.
Тип: число
Default: 0
Environment variable: TT_AUTH_RETRIES
Динамический: да
-
auth_type
¶
Since 2.11.0.
Specify an authentication protocol:
- „chap-sha1“: use the CHAP protocol to authenticate users with
SHA-1
hashing applied to passwords.
- „pap-sha256“: use PAP authentication with the
SHA256
hashing algorithm.
For new users, the box.schema.user.create method
will generate authentication data using PAP-SHA256
.
For existing users, you need to reset a password using
box.schema.user.passwd
to use the new authentication protocol.
Тип: строка
Default value: „chap-sha1“
Environment variable: TT_AUTH_TYPE
Динамический: да
-
disable_guest
¶
Since 2.11.0.
If true, disables access over remote connections
from unauthenticated or guest access users.
This option affects both
net.box and
replication connections.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_DISABLE_GUEST
Динамический: да
-
password_min_length
¶
Since 2.11.0.
Specify the minimum number of characters for a password.
The following example shows how to set the minimum password length to 10.
box.cfg{ password_min_length = 10 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_MIN_LENGTH
Динамический: да
-
password_enforce_uppercase
¶
Since 2.11.0.
If true, a password should contain uppercase letters (A-Z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_UPPERCASE
Динамический: да
-
password_enforce_lowercase
¶
Since 2.11.0.
If true, a password should contain lowercase letters (a-z).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_LOWERCASE
Динамический: да
-
password_enforce_digits
¶
Since 2.11.0.
If true, a password should contain digits (0-9).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_DIGITS
Динамический: да
-
password_enforce_specialchars
¶
Since 2.11.0.
If true, a password should contain at least one special character (such as &|?!@$
).
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARS
Динамический: да
-
password_lifetime_days
¶
Since 2.11.0.
Specify the maximum period of time (in days) a user can use the same password.
When this period ends, a user gets the «Password expired» error on a login attempt.
To restore access for such users, use box.schema.user.passwd.
Примечание
The default 0 value means that a password never expires.
The example below shows how to set a maximum password age to 365 days.
box.cfg{ password_lifetime_days = 365 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_LIFETIME_DAYS
Динамический: да
-
password_history_length
¶
Since 2.11.0.
Specify the number of unique new user passwords before an old password can be reused.
In the example below, a new password should differ from the last three passwords.
box.cfg{ password_history_length = 3 }
Тип: целое число
Default: 0
Environment variable: TT_PASSWORD_HISTORY_LENGTH
Динамический: да
Примечание
Tarantool uses the auth_history
field in the
box.space._user
system space to store user passwords.
Flight recorder
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶
Since 2.11.0.
Enable the flight recorder.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FLIGHTREC_ENABLED
Динамический: да
-
flightrec_logs_size
¶
Since 2.11.0.
Specify the size (in bytes) of the log storage.
You can set this option to 0
to disable the log storage.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_LOGS_SIZE
Динамический: да
-
flightrec_logs_max_msg_size
¶
Since 2.11.0.
Specify the maximum size (in bytes) of the log message.
The log message is truncated if its size exceeds this limit.
Тип: целое число
Default: 4096
Maximum: 16384
Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZE
Динамический: да
-
flightrec_logs_log_level
¶
Since 2.11.0.
Specify the level of detail the log has.
You can learn more about log levels from the log_level
option description.
Note that the flightrec_logs_log_level
value might differ from log_level
.
Тип: целое число
Default: 6
Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVEL
Динамический: да
-
flightrec_metrics_period
¶
Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump.
So, this value defines how much historical metrics data is collected up to the moment of crash.
The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое число
Default: 180
Environment variable: TT_FLIGHTREC_METRICS_PERIOD
Динамический: да
-
flightrec_metrics_interval
¶
Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics.
This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB,
you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: число
По умолчанию: 1.0
Minimum: 0.001
Environment variable: TT_FLIGHTREC_METRICS_INTERVAL
Динамический: да
-
flightrec_requests_size
¶
Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data.
You can set this parameter to 0
to disable a storage of requests and responses.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_REQUESTS_SIZE
Динамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
Enterprise Edition
Authentication features are supported by the Enterprise Edition only.
- auth_delay
- auth_retries
- auth_type
- disable_guest
- password_min_length
- password_enforce_uppercase
- password_enforce_lowercase
- password_enforce_digits
- password_enforce_specialchars
- password_lifetime_days
- password_history_length
-
auth_delay
¶ Since 2.11.0.
Specify a period of time (in seconds) that a specific user should wait for the next attempt after failed authentication.
With the configuration below, Tarantool refuses the authentication attempt if the previous attempt was less than 5 seconds ago.
box.cfg{ auth_delay = 5 }
Тип: числоDefault: 0Environment variable: TT_AUTH_DELAYДинамический: да
-
auth_retries
¶ Since 3.0.0.
Specify the maximum number of authentication retries allowed before
auth_delay
is enforced. The default value is 0, which meansauth_delay
is enforced after the first failed authentication attempt.The retry counter is reset after
auth_delay
seconds since the first failed attempt. For example, if a client tries to authenticate fewer thanauth_retries
times withinauth_delay
seconds, no authentication delay is enforced. The retry counter is also reset after any successful authentication attempt.Тип: числоDefault: 0Environment variable: TT_AUTH_RETRIESДинамический: да
-
auth_type
¶ Since 2.11.0.
Specify an authentication protocol:
- „chap-sha1“: use the CHAP protocol to authenticate users with
SHA-1
hashing applied to passwords. - „pap-sha256“: use PAP authentication with the
SHA256
hashing algorithm.
For new users, the box.schema.user.create method will generate authentication data using
PAP-SHA256
. For existing users, you need to reset a password using box.schema.user.passwd to use the new authentication protocol.Тип: строкаDefault value: „chap-sha1“Environment variable: TT_AUTH_TYPEДинамический: да- „chap-sha1“: use the CHAP protocol to authenticate users with
-
disable_guest
¶ Since 2.11.0.
If true, disables access over remote connections from unauthenticated or guest access users. This option affects both net.box and replication connections.
Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_DISABLE_GUESTДинамический: да
-
password_min_length
¶ Since 2.11.0.
Specify the minimum number of characters for a password.
The following example shows how to set the minimum password length to 10.
box.cfg{ password_min_length = 10 }
Тип: целое числоDefault: 0Environment variable: TT_PASSWORD_MIN_LENGTHДинамический: да
-
password_enforce_uppercase
¶ Since 2.11.0.
If true, a password should contain uppercase letters (A-Z).
Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_PASSWORD_ENFORCE_UPPERCASEДинамический: да
-
password_enforce_lowercase
¶ Since 2.11.0.
If true, a password should contain lowercase letters (a-z).
Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_PASSWORD_ENFORCE_LOWERCASEДинамический: да
-
password_enforce_digits
¶ Since 2.11.0.
If true, a password should contain digits (0-9).
Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_PASSWORD_ENFORCE_DIGITSДинамический: да
-
password_enforce_specialchars
¶ Since 2.11.0.
If true, a password should contain at least one special character (such as
&|?!@$
).Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_PASSWORD_ENFORCE_SPECIALCHARSДинамический: да
-
password_lifetime_days
¶ Since 2.11.0.
Specify the maximum period of time (in days) a user can use the same password. When this period ends, a user gets the «Password expired» error on a login attempt. To restore access for such users, use box.schema.user.passwd.
Примечание
The default 0 value means that a password never expires.
The example below shows how to set a maximum password age to 365 days.
box.cfg{ password_lifetime_days = 365 }
Тип: целое числоDefault: 0Environment variable: TT_PASSWORD_LIFETIME_DAYSДинамический: да
-
password_history_length
¶ Since 2.11.0.
Specify the number of unique new user passwords before an old password can be reused.
In the example below, a new password should differ from the last three passwords.
box.cfg{ password_history_length = 3 }
Тип: целое числоDefault: 0Environment variable: TT_PASSWORD_HISTORY_LENGTHДинамический: даПримечание
Tarantool uses the
auth_history
field in the box.space._user system space to store user passwords.
Flight recorder
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶
Since 2.11.0.
Enable the flight recorder.
Тип: логический
По умолчанию: false (ложь)
Environment variable: TT_FLIGHTREC_ENABLED
Динамический: да
-
flightrec_logs_size
¶
Since 2.11.0.
Specify the size (in bytes) of the log storage.
You can set this option to 0
to disable the log storage.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_LOGS_SIZE
Динамический: да
-
flightrec_logs_max_msg_size
¶
Since 2.11.0.
Specify the maximum size (in bytes) of the log message.
The log message is truncated if its size exceeds this limit.
Тип: целое число
Default: 4096
Maximum: 16384
Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZE
Динамический: да
-
flightrec_logs_log_level
¶
Since 2.11.0.
Specify the level of detail the log has.
You can learn more about log levels from the log_level
option description.
Note that the flightrec_logs_log_level
value might differ from log_level
.
Тип: целое число
Default: 6
Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVEL
Динамический: да
-
flightrec_metrics_period
¶
Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump.
So, this value defines how much historical metrics data is collected up to the moment of crash.
The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое число
Default: 180
Environment variable: TT_FLIGHTREC_METRICS_PERIOD
Динамический: да
-
flightrec_metrics_interval
¶
Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics.
This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB,
you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: число
По умолчанию: 1.0
Minimum: 0.001
Environment variable: TT_FLIGHTREC_METRICS_INTERVAL
Динамический: да
-
flightrec_requests_size
¶
Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data.
You can set this parameter to 0
to disable a storage of requests and responses.
Тип: целое число
Default: 10485760
Environment variable: TT_FLIGHTREC_REQUESTS_SIZE
Динамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
Enterprise Edition
The flight recorder is available in the Enterprise Edition only.
- flightrec_enabled
- flightrec_logs_size
- flightrec_logs_max_msg_size
- flightrec_logs_log_level
- flightrec_metrics_period
- flightrec_metrics_interval
- flightrec_requests_size
- flightrec_requests_max_req_size
- flightrec_requests_max_res_size
-
flightrec_enabled
¶ Since 2.11.0.
Enable the flight recorder.
Тип: логическийПо умолчанию: false (ложь)Environment variable: TT_FLIGHTREC_ENABLEDДинамический: да
-
flightrec_logs_size
¶ Since 2.11.0.
Specify the size (in bytes) of the log storage. You can set this option to
0
to disable the log storage.Тип: целое числоDefault: 10485760Environment variable: TT_FLIGHTREC_LOGS_SIZEДинамический: да
-
flightrec_logs_max_msg_size
¶ Since 2.11.0.
Specify the maximum size (in bytes) of the log message. The log message is truncated if its size exceeds this limit.
Тип: целое числоDefault: 4096Maximum: 16384Environment variable: TT_FLIGHTREC_LOGS_MAX_MSG_SIZEДинамический: да
-
flightrec_logs_log_level
¶ Since 2.11.0.
Specify the level of detail the log has. You can learn more about log levels from the log_level option description. Note that the
flightrec_logs_log_level
value might differ fromlog_level
.Тип: целое числоDefault: 6Environment variable: TT_FLIGHTREC_LOGS_LOG_LEVELДинамический: да
-
flightrec_metrics_period
¶ Since 2.11.0.
Specify the time period (in seconds) that defines how long metrics are stored from the moment of dump. So, this value defines how much historical metrics data is collected up to the moment of crash. The frequency of metric dumps is defined by flightrec_metrics_interval.
Тип: целое числоDefault: 180Environment variable: TT_FLIGHTREC_METRICS_PERIODДинамический: да
-
flightrec_metrics_interval
¶ Since 2.11.0.
Specify the time interval (in seconds) that defines the frequency of dumping metrics. This value shouldn’t exceed flightrec_metrics_period.
Примечание
Given that the average size of a metrics entry is 2 kB, you can estimate the size of the metrics storage as follows:
(flightrec_metrics_period / flightrec_metrics_interval) * 2 kB
Тип: числоПо умолчанию: 1.0Minimum: 0.001Environment variable: TT_FLIGHTREC_METRICS_INTERVALДинамический: да
-
flightrec_requests_size
¶ Since 2.11.0.
Specify the size (in bytes) of storage for the request and response data. You can set this parameter to
0
to disable a storage of requests and responses.Тип: целое числоDefault: 10485760Environment variable: TT_FLIGHTREC_REQUESTS_SIZEДинамический: да
Обратная связь
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶
Since version 1.10.1.
Whether to send feedback.
Если задано значение true
, обратная связь будет отправлена, как описано выше. Если задано значение false
, обратная связь не отправляется.
Тип: логический
По умолчанию: true
Environment variable: TT_FEEDBACK_ENABLED
Динамический: да
-
feedback_host
¶
Since version 1.10.1.
The address to which the packet is sent.
Usually the recipient is Tarantool, but it can be any URL.
Тип: строка
Default: https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOST
Динамический: да
-
feedback_interval
¶
Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятой
По умолчанию: 3600
Environment variable: TT_FEEDBACK_INTERVAL
Динамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
By default, a Tarantool daemon sends a small packet
once per hour, to https://feedback.tarantool.io
.
The packet contains three values from box.info:
box.info.version
, box.info.uuid
, and box.info.cluster_uuid
.
By changing the feedback configuration parameters, users can
adjust or turn off this feature.
-
feedback_enabled
¶ Since version 1.10.1.
Whether to send feedback.
Если задано значение
true
, обратная связь будет отправлена, как описано выше. Если задано значениеfalse
, обратная связь не отправляется.Тип: логическийПо умолчанию: trueEnvironment variable: TT_FEEDBACK_ENABLEDДинамический: да
-
feedback_host
¶ Since version 1.10.1.
The address to which the packet is sent. Usually the recipient is Tarantool, but it can be any URL.
Тип: строкаDefault:https://feedback.tarantool.io
Environment variable: TT_FEEDBACK_HOSTДинамический: да
-
feedback_interval
¶ Since version 1.10.1.
The number of seconds between sendings, usually 3600 (1 hour).
Тип: число с плавающей запятойПо умолчанию: 3600Environment variable: TT_FEEDBACK_INTERVALДинамический: да
Устаревшие параметры
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶
Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶
Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶
Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логический
По умолчанию: true
Динамический: нет
-
panic_on_wal_error
¶
Устаревший, заменен параметром force_recovery.
Тип: логический
По умолчанию: true
Динамический: да
-
replication_source
¶
Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶
Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памяти memtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.
Тип: число с плавающей запятой
По умолчанию: 1.0
Динамический: нет
-
slab_alloc_maximal
¶
Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶
Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶
Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶
Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶
Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶
Deprecated in favor of
wal_max_size.
The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶
Deprecated in Tarantool v2.11 in favor of
election_fencing_mode.
The parameter does not allow using the strict
fencing mode. Setting to true
is equivalent to setting the soft
election_fencing_mode.
Setting to false
is equivalent to setting the off
election_fencing_mode.
Тип: логический
По умолчанию: true
Environment variable: TT_ELECTION_FENCING_ENABLED
Динамический: да
Данные параметры объявлены устаревшими с версии Tarantool 1.7.4:
- logger
- logger_nonblock
- panic_on_snap_error,
- panic_on_wal_error
- replication_source
- slab_alloc_arena
- slab_alloc_maximal
- slab_alloc_minimal
- snap_dir
- snapshot_count
- snapshot_period
- rows_per_wal,
- election_fencing_enabled
-
logger
¶ Устаревший, заменен параметром log. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
logger_nonblock
¶ Устаревший, заменен параметром log_nonblock. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
panic_on_snap_error
¶ Устаревший, заменен параметром force_recovery.
Если при чтении файла снимка произошла ошибка (при запуске экземпляра сервера), прервать выполнение.
Тип: логическийПо умолчанию: trueДинамический: нет
-
panic_on_wal_error
¶ Устаревший, заменен параметром force_recovery.
Тип: логическийПо умолчанию: trueДинамический: да
-
replication_source
¶ Устаревший, заменен параметром replication. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_arena
¶ Устаревший, заменен параметром memtx_memory.
Количество памяти, которое Tarantool выделяет для фактического хранения кортежей, в гигабайтах. При достижении предельного значения запросы вставки INSERT или обновления UPDATE выполняться не будут, выдавая ошибку
ER_MEMORY_ISSUE
. Сервер не выходит за установленный предел памятиmemtx_memory
при распределении кортежей, но есть дополнительная память, которая используется для хранения индексов и информации о подключении. В зависимости от рабочей конфигурации и загрузки, Tarantool может потреблять на 20% больше установленного предела.Тип: число с плавающей запятойПо умолчанию: 1.0Динамический: нет
-
slab_alloc_maximal
¶ Устаревший, заменен параметром memtx_max_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
slab_alloc_minimal
¶ Устаревший, заменен параметром memtx_min_tuple_size. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snap_dir
¶ Устаревший, заменен параметром memtx_dir. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_period
¶ Устаревший, заменен параметром checkpoint_interval. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
snapshot_count
¶ Устаревший, заменен параметром checkpoint_count. Параметр был лишь переименован, его тип, значения и семантика остались прежними.
-
rows_per_wal
¶ Deprecated in favor of wal_max_size. The parameter does not allow to properly limit size of WAL logs.
-
election_fencing_enabled
¶ Deprecated in Tarantool v2.11 in favor of election_fencing_mode.
The parameter does not allow using the
strict
fencing mode. Setting totrue
is equivalent to setting thesoft
election_fencing_mode. Setting tofalse
is equivalent to setting theoff
election_fencing_mode.Тип: логическийПо умолчанию: trueEnvironment variable: TT_ELECTION_FENCING_ENABLEDДинамический: да