Алгоритм Raft стал весьма популярен в последние годы. Описание алгоритма достаточно ясно, имплементации появляются во все большем количестве проектов. Однако все выглядит хорошо на бумаге — будь то математика или рекламные статьи, а при практическом применении все оказывается сложнее.

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

Итак, на практике мы ожидали от Raft следующего.

Во-первых, кластер должен оставаться доступным и на запись и на чтение при частичной потере связности в сети. Канонический Raft не даёт таких гарантий, и это привело к инциденту в Cloudflare в 2020, когда одна из реплик не видела лидера и на протяжении 6,5 часов постоянно устраивала новые выборы, не давая лидеру поработать хоть сколько-нибудь.

Решение проблемы с доступностью кластера при частичной потере связности создает еще одну: при определенных условиях кластер будет неспособен выбрать нового лидера даже при наличии достаточного количества живых и соединенных между собой узлов, в то время, как предыдущий лидер уже не имеет достаточного количества живых соединений и более неспособен произвести запись. Чтобы это исправить, необходимо, чтобы лидер “слагал полномочия” в случае потери кворума живых соединений. Кроме этого, добровольное снятие полномочий позволяет обеспечить уникальность лидера в кластере: к моменту, когда будет выбран новый лидер, старый лидер уже сложит полномочия.

В конце концов, хочется, чтобы после смерти старого лидера кластер стал снова доступен на запись (выбрав нового лидера) максимально быстро (через 10-15 секунд).