Автоматические выборы лидера

Выборы лидера и синхронная репликация

В Tarantool используется модификация Raft — алгоритма синхронной репликации и автоматических выборов лидера. Полное описание алгоритма Raft можно прочитать в соответствующем документе.

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

Процесс выборов лидера

Автоматические выборы лидера в Tarantool гарантируют, что в каждый момент времени в наборе реплик будет максимум один лидер — узел, доступный для записи. Все остальные узлы будут принимать исключительно запросы на чтение.

Когда функция выборов включена, жизненный цикл набора реплик разделен на так называемые термы (term). Каждый терм описывается монотонно растущим числом. После первой загрузки узла значение его терма равно 1. Когда узел обнаруживает, что не является лидером и при этом лидера в наборе реплик уже какое-то время нет, он увеличивает значение своего терма и начинает новый тур выборов.

Leader election happens via votes. The node, which started the election, votes for itself and sends vote requests to other nodes. Upon receiving vote requests, a node votes for the first of them, and then cannot do anything in the same term but wait for a leader being elected.

The node that collected a quorum of votes defined by the replication_synchro_quorum parameter becomes the leader and notifies other nodes about that. Also, a split vote can happen when no nodes received a quorum of votes. In this case, after a random timeout, each node increases its term and starts a new election round if no new vote request with a greater term arrives during this time period. Eventually, a leader is elected.

If any unfinalized synchronous transactions are left from the previous leader, the new leader finalises them automatically.

All the non-leader nodes are called followers. The nodes that start a new election round are called candidates. The elected leader sends heartbeats to the non-leader nodes to let them know it is alive.

In case there are no heartbeats for the period of replication_timeout * 4, a non-leader node starts a new election if the following conditions are met:

• The node has a quorum of connections to other cluster members.
• None of these cluster members can see the leader node.

Terms and votes are persisted by each instance to preserve certain Raft guarantees.

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

Необходимо, чтобы все узлы, включенные в процесс выборов, были соединены попарно и образовывали полную ячеистую топологию (full mesh). Для передачи запросов, связанных с голосованием, и других внутренних сообщений требуется прямая связь между узлами.

In the classic Raft algorithm, a leader doesn’t track its connectivity to the rest of the cluster. Once the leader is elected, it considers itself in the leader position until receiving a new term from another cluster node. This can lead to the split situation if the other nodes elect a new leader upon losing the connectivity to the previous one.

The issue is resolved in Tarantool version 2.10.0 by introducing the leader fencing mode. The mode can be switched on and off by the election_fencing_enabled configuration parameter. When the fencing is on, the leader resigns its leadership if it has less than the 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. Fencing applies to the instances that have the election_mode set to «candidate» or «manual».

There can still be a situation when a replica set has two leaders working independently (so called split-brain). It can happen, for example, if a user mistakenly lowered the replication_synchro_quorum below N / 2 + 1. In this situation, to preserve the data integrity, if an instance detects the split-brain anomaly in the incoming replication data, it breaks the connection with the instance sending the data and writes the ER_SPLIT_BRAIN error in the log.

Eventually, there will be two sets of nodes with the diverged data, and any node from one set is disconnected from any node from the other set with the ER_SPLIT_BRAIN error.

Once noticing the error, a user can choose any representative from each of the sets and inspect the data on them. To correlate the data, the user should remove it from the nodes of one set, and reconnect them to the nodes from the other set that have the correct data.

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

Числовые значения термов также выполняют функцию своеобразного фильтра. Например, если на двух узлах включена функция выборов и значение терма node1 меньше значения терма node2, то узел node2 не будет принимать транзакций от узла node1.

Настройка

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 или больше, то разделение голосов поровну невозможно.

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

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