Managing leader elections

Настройка

box.cfg({
    election_mode = <string>,
    election_timeout = <seconds>,
    replication_timeout = <seconds>,
    replication_synchro_quorum = <count>,
    election_fencing_enabled = <boolean>
})

• election_mode — определяет роль узла в процессе выборов лидера. Подробное описание параметра приводится в справочнике по настройке.
• election_timeout — задает промежуток времени между турами в случае разделения голосов и последующих перевыборов. Подробное описание параметра приводится в справочнике по настройке.
• replication_timeout – reuse of the 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. Default value is 1. The leader is considered dead if it hasn’t sent any heartbeats for the period of replication_timeout * 4.
• replication_synchro_quorum — параметр репликации replication_synchro_quorum, используемый для настройки кворума. Значение по умолчанию — 1, то есть каждый узел, проголосовав за себя, немедленно становится лидером. Лучше всего задать этому параметру значение (<размер кластера> / 2) + 1. В противном случае нет гарантий, что в каждый момент времени в кластере будет только один лидер.
• election_fencing_enabled – switches the leader fencing mode on and off. For the details, refer to the option description in the configuration reference.

Важно также понимать, что статус лидера — не единственное, что требуется узлу, чтобы быть доступным для записи. Параметр read_only на узле-лидере должен иметь значение false (box.cfg{read_only = false}). Необходимо также, чтобы выполнялось условие, заданное параметром replication_connect_quorum (box.cfg{replication_connect_quorum = <count>}), или же этот параметр должен быть отключен (box.cfg{replication_connect_quorum = 0}).

Ничто не мешает задать для параметра read_only значение true, но это сделает лидера недоступным для записи. На сам процесс выборов параметр никак не влияет, поэтому голосовать и быть лидером может даже экземпляр, доступный только для чтения.

Мониторинг

Чтобы отслеживать текущий статус узла в выборах лидера, можно использовать функцию box.info.election. Подробные сведения читайте в описании функции.

Пример:

tarantool> box.info.election
---
- state: follower
  vote: 0
  leader: 0
  term: 1
...

Журнальные записи о выборах на основе алгоритма Raft отмечаются префиксом RAFT:. В журнал вносятся такие события, как обработка новых сообщений Raft, изменение статуса узла, голосование, увеличение значения терма и пр.

Важные замечания

Механизм выборов лидера не будет корректно работать, если кворум меньше <размер кластера> / 2 или равен этому значению, поскольку в этом случае два лидера могут быть избраны одновременно.

Допустим, есть пять узлов. Если значение кворума — 2, то node1 и node2 оба могут проголосовать за node1. При этом node3 и node4 оба могут проголосовать за node5. Тогда выборы выиграют и node1, и node5. Но если в качестве значения кворума установлено большинство, то есть (<размер кластера> / 2) + 1 или больше, то разделение голосов поровну невозможно.

Это особенно актуально при добавлении узлов в кластер. Прежде чем вводить новый узел, рекомендуется обновить значение кворума на всех существующих экземплярах.

Если использовать автоматические выборы лидера без синхронной репликации, может наступить рассогласование данных. При асинхронной репликации успешные выборы нового лидера не означают, что прежний лидер немедленно сложит с себя полномочия. Он по-прежнему будет считать себя активным лидером, принимать запросы от клиентов и совершать транзакции. Асинхронные транзакции, минуя кворум реплик, будут успешно проходить коммиты. При этом синхронные транзакции будут приводить к ошибке, поскольку для их коммита не удастся собрать кворум: большинство реплик будут отвергать транзакции, передаваемые прежним лидером, поскольку уже был избран новый.