Комментарии 6
Следующим шагом нужно применить все синхронные транзакции, которые не успел применить старый лидер. Нужно ждать их репликации на кворум узлов, а затем рассылать подтверждения этих транзакций.
Как новый лидер узнает о незавершенных транзакциях? Не может ли возникнуть ситуации, когда в слейве будет «потеряшка» — старая транзакция без подтверждения или отмены. Классическая проблема двухфазного коммита.
Я не совсем точно выразился в статье. Сейчас попробую объяснить более подробно.
Те транзакции старого лидера, которые есть на новом лидере, он разошлёт остальным, а затем подтвердит.
Всё, чего нет на лидере, но может быть на каких-то из слейвов, лидер попросит отменить. Ничего криминального в этом нет. Раз за лидера проголосовало большинство слейвов, значит у него есть все подтверждённые транзакции, и попросит отменить он как раз такие «потеряшки».
Можно еще уточнить: для достижения бОльшей надежности имеет смысл повышать кворум до N, или наоборот — стремиться к минимальному N/2+1?
Насчёт повышения кворума: при любом значении, большем или равном N/2 + 1, выполняются все гарантии, которые я озвучил в статье. То есть, в каждых выборах либо не побеждает никто, либо номинируется единственный лидер, причём у этого лидера точно есть все транзакции, которые подтвердил предыдущий лидер.
При этом, чем ближе кворум к N, тем выше шансы потерять доступность кластера на запись: если кворум N/2 + 1, кворум будет собираться при потере почти половины реплик; если же кворум N, то отказ любой из реплик приведёт к тому, что транзакции не смогут собирать кворум, и в выборах не сможет победить никто.
Надёжность при повышении кворума увеличивается только в том смысле, что перед подтверждением транзакции попадают на большее количество узлов.
Я всё же считаю, что оптимальное значение — N/2 + 1. Его достаточно для того, чтобы выполнялись все гарантии про единственность лидера и наличие на нём всех подтверждённых данных, и при этом такой кворум не накладывает слишком строгих ограничений на доступность реплик
Спасибо за статью!
У меня появилось несколько вопросов и предложений:
1) Подскажите, пожалуйста, какая логика применяется при падении реплики: она пытается максимально восстановить данные по своему журналу или она сразу при восстановлении копирует журнал мастера?
2) Рассмотрим репликасет из 3 инстансов, где у нас никогда не меняется мастер и транзакции всегда применяются (подтверждаются) только на 2 инстансах (мастере и ещё на одном инстансе). Я правильно понимаю, что может возникнуть ситуация, когда на оставшемся инстансе никогда не применяется транзакция (из-за какой-то аномалии) и при этом репликасет продолжает исправно функционировать?
Если мы используем follower-инстансы для распределения read-нагрузки, мы ведь всегда будем получать с этого аномального инстанса старые данные. Или даже если такой инстанс иногда применяет транзакции, он всё равно какие-то из них может пропустить, и клиент будет читать с него неполноценные таблицы.
3)
он [менеджер транзакиций для Memtx] появился в релизе 2.6 стараниями Александра Ляпунова, о чём тот расскажет в своей статье.
Мне кажется, можно прикрепить сюда ссылку на эту статью.
4) Подскажите, пожалуйста, что из себя представляет журнал Raft. Это какая-то отдельная in-memory структура? Я правильно понимаю, что vclock -- часть этой структуры?
5) Первое упоминание vclock встречается в подразделе 5, а пояснение "vclock — векторные часы; структура, ..." идёт в подразделе 6. Думаю, пояснение стоит разместить сразу после первого упоминания, чтобы читатели не ходили лишний раз в гугл.
6) В репозитории с примерами написано: "Synchronous replication and leader election are currently in beta state. You may get the latest tarantool version here".
Скажите, пожалуйста, на данный момент реализация Raft'a вышла из состояния бета-версии?
Raft в Tarantool. Как это работает и как этим пользоваться