testing_project/Documentation: book/admin/vshard_admin — Russian @ Weblate: cfg.rebalancer_max_sending = 5 vshard.storage.cfg(cfg, box.info.uuid)

The translation is temporarily closed for contributions due to maintenance, please come back later.
The translation was automatically locked due to following alerts: Could not merge the repository.

Zen

	English	Russian	Actions
	\|etalon_bucket_number - real_bucket_number\| / etalon_bucket_number * 100	\|эталонное_число_сегментов - текущее_число_сегментов\| / эталонное_число_сегментов * 100
	For example: The user specified the number of buckets is 3000, and weights of 3 replica sets are 1, 0.5, and 1.5. The resulting etalon numbers of buckets for the replica sets are: 1st replica set – 1000, 2nd replica set – 500, 3rd replica set – 1500.	Например: Пользователь указал, что количество сегментов = 3000, а вес 3 наборов реплик составляет 1, 0,5 и 1,5. В результате получаем следующее эталонное число сегментов для наборов реплик: 1 набор реплик – 1000, 2 набор реплик – 500, 3 набор реплик – 1500.
	This approach allows assigning a zero weight to a replica set, which initiates migration of its buckets to the remaining cluster nodes. It also allows adding a new zero-load replica set, which initiates migration of the buckets from the loaded replica sets to the zero-load replica set.	Такой подход позволяет назначить нулевой вес для набора реплик, который запускает миграцию сегментов на оставшиеся узлы кластера. Это также позволяет добавить новый набор реплик с нулевой нагрузкой, который запускает миграцию сегментов из загруженных наборов реплик в набор реплик с нулевой нагрузкой.
	A new zero-load replica set should be assigned a weight for rebalancing to start.	Новому набору реплик с нулевой нагрузкой следует присвоить вес, чтобы начать процесс балансировки.
	When a new shard is added, the configuration can be updated dynamically:	При добавлении нового шарда конфигурацию можно обновить динамически:
	The configuration should be updated on all the ``routers`` first, and then on all the ``storages``.	Конфигурацию следует сначала обновить на всех роутерах, а затем на всех хранилищах.
	The new shard becomes available for rebalancing in the ``storage`` layer.	Новый шард становится доступен для балансирования на уровне хранилища.
	As a result of rebalancing, buckets are migrated to the new shard.	В результате балансировки происходит миграция сегментов на новый шард.
	If a migrated bucket is requested, ``router`` receives an error code containing information about the new location of the bucket.	Если происходит запрос к перемещенному сегменту, ``роутер`` получает код ошибки с информацией о новом местонахождении сегмента.
	At this time, the new shard is already present in the ``router``'s pool of connections, so redirection is transparent for the application.	В это время новый шард уже включен в пул соединений ``роутера``, поэтому переадресация видима для приложения.
	Parallel rebalancing	Параллельная балансировка
	Originally, ``vshard`` had quite a simple ``rebalancer`` – one process on one node that calculated routes which should send buckets, how many, and to whom. The nodes applied these routes one by one sequentially.	Балансировщик в ``vshard`` первоначально был довольно прост: один процесс на одном узле, который рассчитывал маршруты отправки сегментов, сколько их отправлять и куда. Узлы применяли эти маршруты один за другим последовательно.
	Unfortunately, such a simple schema worked not fast enough, especially for Vinyl, where costs of reading disk were comparable with network costs. In fact, with Vinyl the ``rebalancer`` routes applier was sleeping most of the time.	К сожалению, такая простая схема работала недостаточно быстро, особенно для Vinyl'а, где затраты ресурсов на чтение диска были сопоставимы с сетевыми затратами. На самом деле, механизм применения маршрутов в балансировщике Vinyl'а большую часть времени был в режиме ожидания.
	Now each node can send multiple buckets in parallel in a round-robin manner to multiple destinations, or to just one.	Теперь каждый узел может параллельно посылать несколько сегментов по кругу в несколько пунктов назначения или всего в один.
	To set the degree of parallelism, a new option was added -- :ref:`rebalancer_max_sending <cfg_basic-rebalancer_max_sending>`. You can specify it in a storage configuration in the root table:	Чтобы определять степень параллельности, используется новая опция :ref:`rebalancer_max_sending <cfg_basic-rebalancer_max_sending>`. Задавать ее можно в конфигурации хранилища в корневой таблице:
	cfg.rebalancer_max_sending = 5 vshard.storage.cfg(cfg, box.info.uuid)	cfg.rebalancer_max_sending = 5 vshard.storage.cfg(cfg, box.info.uuid)
	In routers, this option is ignored.	Этот параметр не учитывается для роутеров.
	Specifying ``cfg.rebalancer_max_sending = N`` probably won't give N times speed up. It depends on network, disk, number of other fibers in the system.	Задав ``cfg.rebalancer_max_sending = N``, вы вряд ли получите N-кратное ускорение. На это влияют многие факторы: сеть, диск, количество других файберов в системе.
	Example #1:	Пример №1:
	You have 10 replica sets and a new one is added. Now all the 10 replica sets will try to send buckets to the new one.	У вас уже есть 10 наборов реплик, добавили новый. Теперь все 10 наборов реплик будут пытаться отправить сегменты на новый.
	Assume that each replica set can send up to 5 buckets at once. In that case, the new replica set will experience a rather big load of 50 buckets being downloaded at once. If the node needs to do some other work, perhaps such a big load is undesirable. Also too many parallel buckets can cause timeouts in the rebalancing process itself.	Предположим, каждый набор реплик может отправить до 5 сегментов одновременно. В этом случае будет довольно большая нагрузка на новый набор реплик: одновременная загрузка 50 сегментов. Если узлу нужно выполнить какую-то другую работу, возможно, такая большая нагрузка нежелательна. Кроме того, слишком большое количество параллельно загружаемых сегментов может привести к задержкам самого процесса балансировки.
	To fix the problem, you can set a lower value for ``rebalancer_max_sending`` for old replica sets, or decrease ``rebalancer_max_receiving`` for the new one. In the latter case some workers on old nodes will be throttled, and you will see that in the logs.	Чтобы исправить это, можно установить меньшее значение ``rebalancer_max_sending`` для старых наборов реплик или же уменьшить ``rebalancer_max_receiving`` для нового набора реплик. В последнем случае будет происходить управление загрузкой на старых узлах, и вы увидите это в логах.
	``rebalancer_max_sending`` is important, if you have restrictions for the maximal number of buckets that can be read-only at once in the cluster. As you remember, when a bucket is being sent, it does not accept new write requests.	Важно значение параметра ``rebalancer_max_sending``, если у вас есть ограничение на максимальное количество сегментов, которые могут быть одновременно доступны только для чтения в кластере. Как упоминалось выше, во время отправки сегмент не принимает новые запросов на запись.
	Example #2:	Пример №2:
	You have 100000 buckets and each bucket stores ~0.001% of your data. The cluster has 10 replica sets. And you never can afford > 0.1% of data locked on write. Then you should not set ``rebalancer_max_sending`` > 10 on these nodes. It guarantees that the rebalancer won't send more than 100 buckets at once in the whole cluster.	У вас есть 100 000 сегментов, и каждый сегмент хранит ~ 0,001% ваших данных. В кластере 10 наборов реплик. И нельзя позволить себе заблокировать для записи > 0,1% данных. Таким образом, не следует устанавливать значение ``rebalancer_max_sending`` > 10 на этих узлах. Тогда балансировщик не будет посылать более 100 сегментов одновременно по всему кластеру.
	If ``max_sending`` is too high and ``max_receiving`` is too low, then some buckets will try to get relocated – and will fail with that. This problem will consume network resources and time. It is important to configure these parameters to not conflict with each other.	Если значение ``max_sending`` задано слишком высоко, а ``max_receiving`` слишком низко, то некоторые сегменты будут пытаться переместиться -- и не смогут. При этом будут расходоваться сетевые ресурсы и время. Важно настроить эти параметры так, чтобы они не конфликтовали друг с другом.
	Replica set lock and bucket pin	Блокировка набора реплик и закрепление корзины
	A replica set lock makes a replica set invisible to the ``rebalancer``: a locked replica set can neither receive new buckets nor migrate its own buckets.	Блокировка набора реплик делает набор реплик невидимым для балансировщика: заблокированный набор реплик не может ни принимать новые сегменты, ни мигрировать собственные сегменты.
	A bucket pin blocks a specific bucket from migrating: a pinned bucket stays on the replica set to which it is pinned, until it is unpinned.	В результате закрепления сегмента определенный сегмент блокируется для миграции: закрепленный сегмент остается в наборе реплик, в котором он закреплен, до отмены закрепления.
	Pinning all replica set buckets is not equivalent to locking a replica set. Even if you pin all buckets, a non-locked replica set can still receive new buckets.	Закрепление всех сегментов в наборе реплик не означает блокирование набора реплик. Даже после закрепления всех сегментов незаблокированный набор реплик может принимать новые сегменты.
	Replica set lock is helpful, for example, to separate a replica set from production replica sets for testing, or to preserve some application metadata that must not be sharded for a while. A bucket pin is used for similar cases but in a smaller scope.	Блокировка набора реплик используется, к примеру, чтобы выделить для тестирования набор реплик из наборов реплик, используемых в производстве, или чтобы сохранить некоторые метаданные приложения, которые в течение некоторого времени не должны быть сегментированы. Закрепление сегмента используется в похожих случаях, но в меньшем масштабе.