[Tarantool-discussions] Synch replication: tests

[Aleksandr Lyapunov]

(3)
Мне всё-таки ужасно не нравится предложенно поведение, когда мы 
роллбечим транзакцию и закрываем соедининие с пользователем. Если Монса 
это устраивает, то остальных это может взбесить. Меня не пугают 
транзакции-сироты, меня пугнает что тарантул игнорит пользователя. В 
соединении с пользователем могут быть несколько запросов, получается они 
все будут проигнорированы.. Ох не простят нас.

(4)
напоминаю, что в тесты неплохо было бы добавить server_id и lsn.

(5)
В перспективе я так понимаю лидер должен выбираться автоматически. Надо 
не забыть сделать так, чтобы пользователь об этом смог узнать.
И хочется зафиксировать, что вообще-то мы любой запрос можем роутить к 
лидеру и тогда у нас будет всё консистентно. Пока мы понимаем, что 
роутить RO запросы вредно для перфа, а на RW мы вообще не подписывались, 
так что пока можно забить. Но вообще - можно, ничему не противоречит.


On 4/26/20 8:16 PM, Vladislav Shpilevoy wrote:
> Привет! Спасибо за тесты!
>
> Почему это не в tarantool-discussions, или не хотя бы в server-dev? Здесь
> явно не все участники 4842.
>
> Не хватает вводных данных - откуда эти вопросы появились.
> И не хватает других подходов, которые мы обсуждали, и почему
> они не подошли. Здесь я вижу только один.
>
> On 26/04/2020 16:13, s.ostanevich wrote:
>> Начнем терминов
>> I. Лидер всегда один и все транзакции рассылаются только если они были применены на лидере
>> II. Кворум репликации N означает число узлов, включая мастер, на которых применены данные транзакции (очевидно, N > 1)
>> III. Запись confirm в WALе любой реплики означает, что положительный ответ пользователю отослан и (II) выполнено
> На самом деле это ничего не значит, так как лидер после записи confirm
> и его отсылки не реплику мог все еще не успеть ответить пользователю,
> если WAL-тред долго не отвечат tx-треду.
>
>> Ситуация 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 + откачено.
Решение - я уже давно говорю - после выбора лидера НЕ НАДО ничего 
откатывать, надо доконфёрмить недоконфёрмнутое.
>> 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 нет?
>
>>     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 части? Этот вопрос
> становится не очевиден, когда новый лидер должен доделать работу
> за старым.
>
>> Экс-Лидер	Лидер	Реплика 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) - она идёт нахрен.
>
>> Защита от split-brain.
>>
>> Выборы нового лидера требуют наличие кворума (пункт 1 выборов) реплик.
>> При этом для продолжения функционирования текущего лидера также требуется кворум реплик.
>> Из (I) следует, что у реплика не может участвовать в обоих кворумах. Для обеспечения этого необходимо условие N > M/2 где М - число узлов в кластере.
> Непонятно, что этому препятствует. Защиты никакой нет. Если у нас фулмеш,
> и два мастера считают себя лидерами, и пишут неконфликтующие транзакции, то
> все реплики будут спокойно применять их обоих, как и при нынешнем мастер-мастере.
> У реплики нет никакого понятия "принадлежности" какому-либо кворуму с
> определенным лидером.