Какую проблему решает совместный консенсус двух конфигураций при изменении состава узлов кластера?
Совместный консенсус предотвращает ситуацию, в которой старая и новая конфигурации одновременно считают свои кворумы независимыми и принимают противоречивые решения. На переходном этапе операция должна быть подтверждена кворумом, учитывающим обе конфигурации, поэтому кворумы старого и нового состава сохраняют пересечение.
Фиксированный состав консенсусного кластера предполагает, что правила формирования кворума не меняются во время работы. При добавлении или удалении узлов это предположение нарушается: разные узлы могут применять разные правила подсчёта большинства.
Подход с совместной конфигурацией появился как решение проблемы безопасного изменения членства без остановки кластера. Он позволяет разделить изменение на переходный этап и финальную конфигурацию, сохранив свойства единственности решения и согласованного порядка записей.
Рассмотрим кластер из трёх узлов, который заменяют на кластер из пяти. Если старые узлы сразу начнут считать кворумом два узла, а новые — три, сеть может разделиться так, что каждая сторона соберёт собственное большинство по своей конфигурации.
Тогда одна сторона способна принять запись, а другая — другую запись для той же позиции журнала. После восстановления связи возникнет конфликт, который нельзя безопасно разрешить простым выбором более свежей версии: обе стороны могли считать свои решения подтверждёнными.
Сначала вводится совместная конфигурация, содержащая старый и новый состав. Запись считается подтверждённой только при выполнении условий кворума для обеих конфигураций: её должны подтвердить большинство старых узлов и большинство новых узлов.
После того как совместная конфигурация зафиксирована в журнале и применена узлами, можно записать финальную новую конфигурацию. С этого момента используется только её кворум, а старые узлы могут быть безопасно удалены из состава.
Ключевой инвариант состоит в пересечении кворумов. Любой кворум, который мог подтвердить запись до изменения состава, пересекается с любым кворумом, который может подтвердить запись после изменения. Общий узел хранит информацию о прежнем решении и не позволяет согласованно выбрать другую запись для той же позиции.
Важно отличать изменение членства от обычного добавления реплики. Новая реплика может сначала догнать журнал и только затем стать участником кворума. Если включить неподготовленный узел в состав слишком рано, подтверждение операций может замедлиться или стать невозможным.
Совместная конфигурация не устраняет сетевые разделения и не гарантирует доступность при произвольном отказе узлов. Она лишь сохраняет безопасность перехода; доступность по-прежнему зависит от того, существует ли кворум в обеих конфигурациях и успевают ли узлы обмениваться сообщениями.
Кластер из пяти узлов нужно расширить до семи, потому что выросла нагрузка на чтение и требуется дополнительная отказоустойчивость. Рассматривались два варианта: немедленно заменить конфигурацию на семь узлов или провести переход через совместную конфигурацию.
Мгновенная замена проще, но опасна: часть узлов может остаться со старым составом и принять решение по старому правилу большинства, пока другая часть уже использует новое. Вариант с полной остановкой кластера безопаснее концептуально, но приводит к простою и усложняет эксплуатацию.
Выбрана совместная конфигурация. Новые узлы сначала синхронизировали журнал, затем кластер зафиксировал переходную конфигурацию, а после подтверждения её устойчивости — финальный состав из семи узлов. Записи не дублировались между независимыми кворумами, однако во время перехода задержка подтверждения выросла из-за необходимости учитывать две группы узлов.
Нет, недостаточно рассуждать только о пересечении кворума старой и новой конфигурации. Нужно, чтобы каждая запись переходного периода подтверждалась одновременно большинством старого и большинством нового состава. Иначе можно получить два кворума, каждый из которых пересекается с другой конфигурацией формально, но не обеспечивает общего узла между двумя конкурирующими решениями.
Нет. Сначала новая конфигурация должна стать согласованной частью журнала, а узлы должны обработать её в соответствии с протоколом. Если старые узлы убрать до завершения перехода, кластер может потерять доступный кворум или нарушить условия, на которых основана безопасность изменения членства.
Он может стать узким местом доступности: для подтверждения записи требуется его участие, но он не способен корректно обработать актуальный журнал. Поэтому на практике новый узел обычно сначала работает как не участвующая в голосовании реплика, получает необходимую часть состояния, а затем переводится в голосующий состав. Это повышает вероятность успешного перехода, но требует дополнительного времени и сетевого трафика.