[Tarantool-discussions] Synch replication: tests

s.ostanevich s.ostanevich at corp.mail.ru
Tue Apr 28 18:51:36 MSK 2020 

Сорри за месс - отвечу сюда.

> On 28 Apr 2020, at 15:24, Aleksandr Lyapunov <alyapunov at tarantool.org> wrote:
> 
> (3)
> Мне всё-таки ужасно не нравится предложенно поведение, когда мы роллбечим транзакцию и закрываем соедининие с пользователем. Если Монса это устраивает, то остальных это может взбесить. Меня не пугают транзакции-сироты, меня пугнает что тарантул игнорит пользователя. В соединении с пользователем могут быть несколько запросов, получается они все будут проигнорированы.. Ох не простят нас.
> 
> (4)
> напоминаю, что в тесты неплохо было бы добавить server_id и lsn.
> 
> (5)
> В перспективе я так понимаю лидер должен выбираться автоматически. Надо не забыть сделать так, чтобы пользователь об этом смог узнать.
> И хочется зафиксировать, что вообще-то мы любой запрос можем роутить к лидеру и тогда у нас будет всё консистентно. Пока мы понимаем, что роутить RO запросы вредно для перфа, а на RW мы вообще не подписывались, так что пока можно забить. Но вообще - можно, ничему не противоречит.
> 

Я за то, чтобы у нас был API для реализации выборов и алгоритм - а работать он может извне. Тогда пользователь может его поменять “под себя”.


> 
> On 4/26/20 8:16 PM, Vladislav Shpilevoy wrote:
>> Привет! Спасибо за тесты!
>> 
>> Почему это не в tarantool-discussions, или не хотя бы в server-dev? Здесь
>> явно не все участники 4842.
>> 
>> Не хватает вводных данных - откуда эти вопросы появились.
>> И не хватает других подходов, которые мы обсуждали, и почему
>> они не подошли. Здесь я вижу только один.
>> 

Да, про другие подходы - это была Сашина идея “применять всё” и не иметь confirm в вале, соответственно. Ответ было таков, что это по факту наш нынешний асинк. 

>> On 26/04/2020 16:13, s.ostanevich wrote:
>>> Начнем терминов
>>> I. Лидер всегда один и все транзакции рассылаются только если они были применены на лидере
>>> II. Кворум репликации N означает число узлов, включая мастер, на которых применены данные транзакции (очевидно, N > 1)
>>> III. Запись confirm в WALе любой реплики означает, что положительный ответ пользователю отослан и (II) выполнено
>> На самом деле это ничего не значит, так как лидер после записи confirm
>> и его отсылки не реплику мог все еще не успеть ответить пользователю,
>> если WAL-тред долго не отвечат tx-треду.

Если confirm доехал - значит был кворум. Иначе confirm не пишется даже лидером. Про ответ пользователю - согласен, не означает.

>> 
>>> Ситуация 1: лидер собрал кворум, ответил пользователю, но до реплик confirm не доехал
>>> 
>>> Выбираем лидера:
>>> 1. Удостоверяемся, что в кластере как минимум N реплик - иначе требование кворума выполнить впредь не удастся
>>> 2. Получив все vclock реплик выбираем лидером ту, у которой LSN максимальный
>> Какой LSN? Их 32 на каждом инстансе. Я так понимаю, LSN в компоненте vclock
>> старого лидера? Откуда внешний инструмент помнит, где часть vclock от старого
>> лидера? История, кто был последним лидером, и с каким replica_id, должна храниться
>> где-то? Не понял пока.

Всех лидеров назначает внешний координатор, он всегда в курсе кто “сейчас”.

>> 
>>> 3. Лидер производит поиск транзакции, для которой мог быть отправлен положительный пользователю
>>> а) лидер имеет максимальный LSN - значит у него последний confirm, сперва выбираем транзакцию, для которой этот confirm согласно (III)
>> "Согласно (III)" что? Этого не понял. Либо не хватает запятой после confirm?
>> 
>>> б) далее проводим поиск старшего LSN, который есть на N-1 репликах, поскольку лидер тоже его имел согласно (I)
>> Что из этого автоматика, а что интерфейс для внешнего оркестратора?
>> 
>>> 4. Рассылаем confirm на выбранный LSN - это либо уже имеющийся в WAL лидера из 3.а или выбранный в 3.б - для него пишем confirm себе в WAL
>>> 5. При непустом undo log пишем rollback на самую старую транзакцию в undo log
> (1)
> Насчет восстановления после смерти мастера, "поиск старшего LSN, который есть на N-1 репликах."
> Тут я вижу логическую ошибку. Попробую на примере.
> Кластер 5 машин, лидер + 4 реплики, кворум N = 3.
> Транзакция записана на лидер, реплику 1 и 2, кворум, лидер пишет себе confirm и юзеру ОК.
> Теперь умирает лидер и реплика 1. OK успевает доехать до юзера, confirm - ни до кого (или до реплики 1).
> Остаются 3 узла - реплики 2, 3 и 4. Достаточно для выборов, выбирается реплика 2.
> Теперь внимание, транзакция есть только на одной живой ноде, что меньше, чем N-1 и её сейчас предлагается роллбечить.
> И тогда мы получим ситуацию OK + откачено.
> Решение - я уже давно говорю - после выбора лидера НЕ НАДО ничего откатывать, надо доконфёрмить недоконфёрмнутое.

При этом текущий лидер, оставшийся в меньшинстве, должен вообще свернуть деятельность. Даже ридонли.
Добавим сюда еще транзакцию, которая доехала до выжившей 2, но не попала на 1. Про нее старый лидер пока не получил confirm. Однако ее уже распространит новый лидер - причем, на кворум. Таким образом, старый лидер будет ридонли “врать” что не было такого, а оно есть.


>>> 6. Начинаем раздавать WAL
>>> 
>>> Пример 1, N=3
>>> Часть реплик ответила, лидер успел записать два подтверждения, но не разослал.
>> Просьба избегать сложного форматирования текста в письме. Иначе это сложно
>> комментировать.
>> 
>>> Лидер (мертв)	Реплика 1	Реплика 2	Реплика 3
>>> Tx1	Tx1	Tx1	Tx1
>>> Tx2	Tx2	Tx2	
>>> Tx3			
>>> Conf1			
>>> Tx4			
>>> Tx5			
>>> Conf2			
>>> Tx 6			
>>> Tx 7			
>>> 
>>> 
>>> 1. 3(число нод) >= 3(N)
>>> 2. Реплика 2 - лидер
>>> 3. а) LSN = 0
>> Что означает LSN 0? Что ни одного confirm нет?

да, не встретили ни одного confirm.
>> 
>>>    b) LSN = 2
>>> 4. confirm 2
>>> Экс-Лидер	Лидер	Реплика 2	Реплика 3
>> Выше было сказано, что лидером становится реплика 2, но здесь
>> это реплика 1, и confirm-ы, судя по этой таблице, пишет она.
>> Что-то не так.

Описка, сорри

>> 
>>> Tx1	Tx1	Tx1	Tx1
>>> Tx2	Tx2	Tx2	
>>> Tx3	Conf2		
>>> Conf1			
>>> Tx4			
>>> Tx5			
>>> Conf2			
>>> Tx6			
>>> Tx7			
>>> 
>>> 
>>> 5. undo log пуст - ничего не делаем
>>> 6. раздаем WAL
>>> Экс-Лидер	Реплика 1	Реплика 2	Реплика 3
>>> Tx1	Tx1	Tx1	Tx1
>>> Tx2	Tx2	Tx2	Tx2
>>> Tx3	Conf2	Conf2	Conf2
>>> Conf1			
>>> Tx4			
>>> Tx5			
>>> Conf2			
>>> Tx6			
>>> Tx7			
>>> 
>>> 
>>> 
>>> Пример 2 - те же, там же, часть confirm доехала
>>> 
>>> 
>>> Лидер(мертв)	Реплика 1	Реплика 2	Реплика 3
>>> Tx1	Tx1	Tx1	Tx1
>>> Tx2	Tx2	Tx2	Tx2
>>> Tx3	Tx3	Tx3	Tx3
>>> Conf1	Conf1		Conf1
>>> Tx4	Tx4		Tx4
>>> Tx5	Tx5		
>>> Conf2			
>>> Tx6			
>>> Tx7			
>>> 
>>> 
>>> 1. 3 >= 3
>>> 2. Реплика 1 - лидер
>>> 3. а) LSN = 1
>>>    б) LSN = 4
>>> 4. Confirm 4
>>> 5. Rollback 5
>> Что конкретно делает rollback? У нас 32 LSN компоненты в vclock.
>> Что rollback должен в себе содержать? Все 32 части? Этот вопрос
>> становится не очевиден, когда новый лидер должен доделать работу
>> за старым.
>> 

Rollback должен содержать [ID, LSN] транзакции. То есть, новый лидер может заставить отказаться от транзакций, что повисли без подтверждения кворумом. 

>>> Экс-Лидер	Лидер	Реплика 2	Реплика 3
>>> Tx1	Tx1	Tx1	Tx1
>>> Tx2	Tx2	Tx2	Tx2
>>> Tx3	Tx3	Tx3	Tx3
>>> Conf1	Conf1		Conf1
>>> Tx4	Tx4		Tx4
>>> Tx5	Tx5		
>>> Conf2	Conf4		
>>> Tx6	Rollback5		
>>> Tx7			
>>> 
>>> 
>>> 6. Раздаем
>>> 
>>> Экс-Лидер	Лидер	Реплика 2	Реплика 3
>>> Tx1	Tx1	Tx1	Tx1
>>> Tx2	Tx2	Tx2	Tx2
>>> Tx3	Tx3	Tx3	Tx3
>>> Conf1	Conf1	Conf1	Conf1
>>> Tx4	Tx4	Tx4	Tx4
>>> Tx5	Tx5	Tx5	Tx5
>>> Conf2	Conf4	Conf4	Conf4
>>> Tx6	Rollback5	Rollback5	Rollback5
>>> Tx7			
>>> 
>>> 
>>> 
>>> Пример 2*, экс-лидер нежданно вернулся
>>> Экс-Лидер	Лидер	Реплика 2	Реплика 3
>>> Tx1	Tx1	Tx1	Tx1
>>> Tx2	Tx2	Tx2	Tx2
>>> Tx3	Tx3	Tx3	Tx3
>>> Conf1	Conf1	Conf1	Conf1
>>> Tx4	Tx4	Tx4	Tx4
>>> Tx5	Tx5	Tx5	Tx5
>>> Conf2	Conf4	Conf4	Conf4
>>> Tx6	Rollback5	Rollback5	Rollback5
>>> Tx7	Tx10	Tx10	Tx10
>>> 	Tx11	Tx11	Tx11
>>> 	Conf10	Conf10	Conf10
>>> 
>>> 
>>> Так как мы успешно выбрали лидера, значит экс-лидер потерял кворум. В этом случае он должен стать простой репликой, подключаясь в кластер от нового лидера получит транзакции начиная с Conf4 - ее первую раздал лидер после назначения
>> Если речь про replication_quorum, то он его не потеряет.
>> Он поднимется, реплики подключатся, инстанс благополучно
>> запустится с read_only=false.
>> 
>>> Экс-Лидер	Лидер	Реплика 2	Реплика 3
>>> Tx1	Tx1	Tx1	Tx1
>>> Tx2	Tx2	Tx2	Tx2
>>> Tx3	Tx3	Tx3	Tx3
>>> Conf1	Conf1	Conf1	Conf1
>>> Tx4	Tx4	Tx4	Tx4
>>> Tx5	Tx5	Tx5	Tx5
>>> Conf2	Conf4	Conf4	Conf4
>>> Tx6	Rollback5	Rollback5	Rollback5
>>> Tx7	Tx10	Tx10	Tx10
>>> Conf4	Tx11	Tx11	Tx11
>>> Rollback5	Conf10	Conf10	Conf10
>>> Tx10			
>>> Tx11			
>>> Conf10			
>>> 
>>> 
>>> Итого у экс-лидера будет откат транзакций 7, 6 и 5, после чего применятся все транзакции нового лидера.
>> Это невозможно, тогда будут разные WAL-ы у старого лидера, ставшего репликой,
>> и нового лидера. Тогда это будет rejoin.
> (2)
> Очень хочется записать в RFC требование, что у всех нод должен быть одинаковый вал. Это необязательное требование, но должно сильно упростить нам жизнь.
> И тут же добавить правило, которое можно даже назвать чьим-то именем:
> если реплика хоть в чем-то умнее лидера (т.е. имеет больший LSN хотя бы по одному из server_id) - она идёт нахрен.

Это верно, такие инстансы в RAFTе откатывают WAL по одной транзакции. Для нас эквивалент - rollback. Осталось доказать, что если у реплики есть такой бОльший vclock[ID] то на него не было кворума. И тогда откат спасет.

>> 
>>> Защита от split-brain.
>>> 
>>> Выборы нового лидера требуют наличие кворума (пункт 1 выборов) реплик.
>>> При этом для продолжения функционирования текущего лидера также требуется кворум реплик.
>>> Из (I) следует, что у реплика не может участвовать в обоих кворумах. Для обеспечения этого необходимо условие N > M/2 где М - число узлов в кластере.
>> Непонятно, что этому препятствует. Защиты никакой нет. Если у нас фулмеш,
>> и два мастера считают себя лидерами, и пишут неконфликтующие транзакции, то
>> все реплики будут спокойно применять их обоих, как и при нынешнем мастер-мастере.
>> У реплики нет никакого понятия "принадлежности" какому-либо кворуму с
>> определенным лидером.

Вот именно поэтому “себя” считать нельзя. Только через координатора. Если ты потерял реплик бОльше, чем нужно для кворума - “я ухожу”.

More information about the Tarantool-discussions mailing list