testing_project/Documentation: how-to/replication/repl_leader_elect — Russian @ Weblate: tarantool> box.info.election ---

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
	Starting from version :doc:`2.6.1 </release/2.6.1>`, Tarantool has the built-in functionality managing automated leader election in a replica set. Learn more about the :ref:`concept of leader election <repl_leader_elect>`.
	Configuration	Настройка
	box.cfg({ election_mode = <string>, election_fencing_mode = <string>, election_timeout = <seconds>, replication_timeout = <seconds>, replication_synchro_quorum = <count> })	box.cfg({ election_mode = <string>, election_timeout = <seconds>, replication_timeout = <seconds>, replication_synchro_quorum = <count>, })
	``election_mode`` -- specifies the role of a node in the leader election process. For the details, refer to the :ref:`option description <cfg_replication-election_mode>` in the configuration reference.	``election_mode`` — определяет роль узла в процессе выборов лидера. Подробное :ref:`описание параметра <cfg_replication-election_mode>` приводится в справочнике по настройке.
	``election_fencing_mode`` -- specifies the :ref:`leader fencing mode <repl_leader_elect_fencing>`. For the details, refer to the :ref:`option description <cfg_replication-election_fencing_mode>` in the configuration reference.	``election_mode`` — определяет роль узла в процессе выборов лидера. Подробное :ref:`описание параметра <cfg_replication-election_mode>` приводится в справочнике по настройке.
	``election_timeout`` -- specifies the timeout between election rounds if the previous round ended up with a split vote. For the details, refer to the :ref:`option description <cfg_replication-election_timeout>` in the configuration reference.	``election_timeout`` — задает промежуток времени между турами в случае разделения голосов и последующих перевыборов. Подробное :ref:`описание параметра <cfg_replication-election_timeout>` приводится в справочнике по настройке.
	``replication_timeout`` -- reuse of the :ref:`replication_timeout <cfg_replication-replication_timeout>` configuration option for the purpose of the leader election process. Heartbeats sent by an active leader have a timeout after which a new election starts. Heartbeats are sent once per <replication_timeout> seconds. The default value is ``1``. The leader is considered dead if it hasn't sent any heartbeats for the period of ``replication_timeout * 4``.	``replication_timeout`` — параметр репликации :ref:`replication_timeout <cfg_replication-replication_timeout>`, используемый для выборов лидера. Активный лидер отправляет сообщения контрольного сигнала каждые <replication_timeout> секунд. Значение параметра по умолчанию — ``1``. Если лидер не отправляет сообщений контрольного сигнала в течение ``<replication_timeout> * 4`` секунд, он считается недоступным (dead) и начинаются новые выборы.
	``replication_synchro_quorum`` -- reuse of the :ref:`replication_synchro_quorum <cfg_replication-replication_synchro_quorum>` option for the purpose of configuring the election quorum. The default value is ``1``, meaning that each node becomes a leader immediately after voting for itself. It is best to set up this option value to the ``(<cluster size> / 2) + 1``. Otherwise, there is no guarantee that there is only one leader at a time.	``replication_synchro_quorum`` — параметр репликации :ref:`replication_synchro_quorum <cfg_replication-replication_synchro_quorum>`, используемый для настройки кворума. Значение по умолчанию — ``1``, то есть каждый узел, проголосовав за себя, немедленно становится лидером. Лучше всего задать этому параметру значение ``(<размер кластера> / 2) + 1``. В противном случае нет гарантий, что в каждый момент времени в кластере будет только один лидер.
	It is important to know that being a leader is not the only requirement for a node to be writable. The leader should also satisfy the following requirements:
	The :ref:`read_only <cfg_basic-read_only>` option is set to ``false``.
	The leader shouldn't be in the orphan state.
	Nothing prevents you from setting the ``read_only`` option to ``true``, but the leader just won't be writable then. The option doesn't affect the election process itself, so a read-only instance can still vote and become a leader.	Ничто не мешает задать для параметра ``read_only`` значение ``true``, но это сделает лидера недоступным для записи. На сам процесс выборов параметр никак не влияет, поэтому голосовать и быть лидером может даже экземпляр, доступный только для чтения.
	Monitoring	Мониторинг
	To monitor the current state of a node regarding the leader election, you can use the ``box.info.election`` function. For details, refer to the :doc:`function description </reference/reference_lua/box_info/election>`.	Чтобы отслеживать текущий статус узла в выборах лидера, можно использовать функцию ``box.info.election``. Подробные сведения читайте в :doc:`описании функции </reference/reference_lua/box_info/election>`.
	Example:	Пример:
	tarantool> box.info.election --- - state: follower vote: 0 leader: 0 term: 1 ...	tarantool> box.info.election --- - state: follower vote: 0 leader: 0 term: 1 ...
	The Raft-based election implementation logs all its actions with the ``RAFT:`` prefix. The actions are new Raft message handling, node state changing, voting, and term bumping.	Журнальные записи о выборах на основе алгоритма Raft отмечаются префиксом ``RAFT:``. В журнал вносятся такие события, как обработка новых сообщений Raft, изменение статуса узла, голосование, увеличение значения терма и пр.
	Important notes	Важные замечания
	Leader election doesn't work correctly if the election quorum is set to less or equal than ``<cluster size> / 2`` because in that case, a split vote can lead to a state when two leaders are elected at once.	Механизм выборов лидера не будет корректно работать, если кворум меньше ``<размер кластера> / 2`` или равен этому значению, поскольку в этом случае два лидера могут быть избраны одновременно.
	For example, suppose there are five nodes. When the quorum is set to ``2``, ``node1`` and ``node2`` can both vote for ``node1``. ``node3`` and ``node4`` can both vote for ``node5``. In this case, ``node1`` and ``node5`` both win the election. When the quorum is set to the cluster majority, that is ``(<cluster size> / 2) + 1`` or greater, the split vote is impossible.	Допустим, есть пять узлов. Если значение кворума — ``2``, то ``node1`` и ``node2`` оба могут проголосовать за ``node1``. При этом ``node3`` и ``node4`` оба могут проголосовать за ``node5``. Тогда выборы выиграют и ``node1``, и ``node5``. Но если в качестве значения кворума установлено большинство, то есть ``(<размер кластера> / 2) + 1`` или больше, то разделение голосов поровну невозможно.
	That should be considered when adding new nodes. If the majority value is changing, it's better to update the quorum on all the existing nodes before adding a new one.	Это особенно актуально при добавлении узлов в кластер. Прежде чем вводить новый узел, рекомендуется обновить значение кворума на всех существующих экземплярах.
	Also, the automated leader election doesn't bring many benefits in terms of data safety when used without :ref:`synchronous replication <repl_sync>`. If the replication is asynchronous and a new leader gets elected, the old leader is still active and considers itself the leader. In such case, nothing stops it from accepting requests from clients and making transactions. Non-synchronous transactions are successfully committed because they are not checked against the quorum of replicas. Synchronous transactions fail because they are not able to collect the quorum -- most of the replicas reject these old leader's transactions since it is not a leader anymore.	Если использовать автоматические выборы лидера без :ref:`синхронной репликации <repl_sync>`, может наступить рассогласование данных. При асинхронной репликации успешные выборы нового лидера не означают, что прежний лидер немедленно сложит с себя полномочия. Он по-прежнему будет считать себя активным лидером, принимать запросы от клиентов и совершать транзакции. Асинхронные транзакции, минуя кворум реплик, будут успешно проходить коммиты. При этом синхронные транзакции будут приводить к ошибке, поскольку для их коммита не удастся собрать кворум: большинство реплик будут отвергать транзакции, передаваемые прежним лидером, поскольку уже был избран новый.