Справочник по настройке
Примечание
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.
- sharding
- weights
- shard_index
- bucket_count
- collect_bucket_garbage_interval
- collect_lua_garbage
- sync_timeout
- rebalancer_disbalance_threshold
- rebalancer_max_receiving
- rebalancer_max_sending
- discovery_mode
- sched_move_quota
- sched_ref_quota
-
sharding
¶ Поле, которое определяет логическую топологию сегментированного кластера Tarantool.
Тип: таблицаПо умолчанию: false (ложь)Динамический: да
-
weights
¶ Поле, которое определяет конфигурацию относительного веса для каждой пары зон в наборе реплик.
Тип: таблицаПо умолчанию: false (ложь)Динамический: да
-
shard_index
¶ Название или id TREE-индекса по идентификатору сегмента. Спейсы без этого индекса не задействованы в шардированном кластере Tarantool и при необходимости могут быть использованы как обычные спейсы. Необходимо указать первую часть индекса, остальные части являются необязательными.
Тип: непустая строка или неотрицательное целое числоПо умолчанию: «bucket_id» (идентификатор сегмента)Динамический: нет
-
bucket_count
¶ Общее число сегментов в кластере.
Это число должно быть на несколько порядков больше, чем потенциальное число узлов кластера, учитывая потенциальное масштабирование в обозримом будущем.
Пример:
Если предполагаемое количество узлов равно M, тогда набор данных должен быть разделен на 100M или даже 1000M сегментов, в зависимости от запланированного масштабирования. Это число, безусловно, больше потенциального числа узлов кластера в проектируемой системе.
Следует помнить, что слишком большое число сегментов может привести к необходимости выделять больше памяти для хранения информации о маршрутизации. С другой стороны, недостаточное число сегментов может привести к снижению степени детализации при балансировке.
Тип: числоПо умолчанию: 3000Динамический: нет
-
collect_bucket_garbage_interval
¶ Deprecated since: 0.1.17.
Интервал между действиями сборщика мусора в секундах.
Тип: числоПо умолчанию: 0.5Динамический: да
-
collect_lua_garbage
¶ Deprecated since: 0.1.20.
Если задано значение true (правда), периодически вызывается Lua-функция
collectgarbage()
.Тип: логическийПо умолчанию: нетДинамический: да
-
sync_timeout
¶ Время ожидания синхронизации старого мастера с репликами перед сменой мастера. Используется при переключении мастера или при вызове функции
sync()
вручную.Тип: числоПо умолчанию: 1Динамический: да
-
rebalancer_disbalance_threshold
¶ A maximum bucket disbalance threshold, in percent. The disbalance is calculated for each replica set using the following formula:
|эталонное_число_сегментов - фактическое_число_сегментов| / эталонное_число_сегментов * 100
Тип: числоПо умолчанию: 1Динамический: да
-
rebalancer_max_receiving
¶ Максимальное количество сегментов, которые может получить параллельно один набор реплик. Это число должно быть ограничено, так как при добавлении нового набора реплик в кластер балансировщик отправляет очень большое количество сегментов из существующих наборов реплик в новый набор реплик. Это создает большую нагрузку на новый набор реплик.
Пример:
Предположим,
rebalancer_max_receiving
= 100, число сегментов вbucket_count
= 1000. Есть 3 набора реплик с 333, 333 и 334 сегментами соответственно. При добавлении нового набора репликэталонное_число_сегментов
становится равным 250. Вместо того, чтобы сразу получить все 250 сегментов, новый набор реплик получит последовательно 100, 100 и 50 сегментов.Тип: числоПо умолчанию: 100Динамический: да
-
rebalancer_max_sending
¶ Степень параллельности для параллельной балансировки.
Используется только для хранилищ, для роутеров игнорируется.
Максимальное значение:
15
.Тип: числоПо умолчанию: 1Динамический: да
-
discovery_mode
¶ Режим работы файбера обнаружения сегментов:
on
/off
/once
. Подробнее.Тип: строкаПо умолчанию: «on»Динамический: да
-
sched_move_quota
¶ A scheduler’s bucket move quota used by the rebalancer.
sched_move_quota
defines how many bucket moves can be done in a row if there are pending storage refs. Then, bucket moves are blocked and a router continues making map-reduce requests.See also: sched_ref_quota.
Тип: числоПо умолчанию: 1Динамический: да
-
sched_ref_quota
¶ A scheduler’s storage ref quota used by a router’s map-reduce API. For example, the vshard.router.map_callrw() function implements consistent map-reduce over the entire cluster.
sched_ref_quota
defines how many storage refs, therefore map-reduce requests, can be executed on the storage in a row if there are pending bucket moves. Then, storage refs are blocked and the rebalancer continues bucket moves.See also: sched_move_quota.
Тип: числоDefault: 300Динамический: да
-
uuid
¶ Уникальный идентификатор набора реплик.
Тип:По умолчанию:Динамическое:
-
weight
¶ Вес набора реплик. Для получения подробной информации см. раздел Вес набора реплик.
Тип:По умолчанию: 1Динамическое:
-
master
¶ Turns on automated master discovery in a replica set if set to
auto
. Applicable only to the configuration of a router; the storage configuration ignores this parameter.The parameter should be specified per replica set. The configuration is not compatible with a manual master selection.
Examples
Correct configuration:
config = { sharding = { <replicaset uuid> = { master = 'auto', replicas = {...}, }, ... }, ... }
Incorrect configuration:
config = { sharding = { <replicaset uuid> = { master = 'auto', replicas = { <replica uuid1> = { master = true, ... }, <replica uuid2> = { master = false, ... }, }, }, ... }, ... }
If the configuration is incorrect, it is not applied, and the
vshard.router.cfg()
call throws an error.If the
master
parameter is set toauto
for some replica sets, the router goes to these replica sets, discovers the master in each of them, and periodically checks if the master instance still has its master status. When the master in the replica set stops being a master, the router goes around all the nodes of the replica set to find out which one is the new master.Without this setting, the router cannot detect master nodes in the configured replica sets on its own. It relies only on how they are specified in the configuration. This becomes a problem when the master changes, and the change is not delivered to the router’s configuration: for instance, in case the router doesn’t rely on a central configuration provider or the provider cannot deliver a new configuration due to some reason.
Тип: строкаDefault:nil
Динамический: да