From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp45.i.mail.ru (smtp45.i.mail.ru [94.100.177.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id D71B24696C3 for ; Tue, 28 Apr 2020 15:24:02 +0300 (MSK) References: <77CF6795-FDF3-4C54-89EF-0CD7F55F1A09@corp.mail.ru> From: Aleksandr Lyapunov Message-ID: <0c51df15-0d43-04af-9cf6-2b2a1d7004e3@tarantool.org> Date: Tue, 28 Apr 2020 15:24:00 +0300 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format="flowed" Content-Transfer-Encoding: 8bit Content-Language: en-US Subject: Re: [Tarantool-discussions] Synch replication: tests List-Id: Tarantool development process List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladislav Shpilevoy , "s.ostanevich" , Mons Anderson , =?UTF-8?B?0J3QuNC60L7Qu9Cw0Lkg0JrQsNGA0LvQvtCy?= , Yukhin Kirill , Serge Petrenko , tarantool-discussions@dev.tarantool.org (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 где М - число узлов в кластере. > Непонятно, что этому препятствует. Защиты никакой нет. Если у нас фулмеш, > и два мастера считают себя лидерами, и пишут неконфликтующие транзакции, то > все реплики будут спокойно применять их обоих, как и при нынешнем мастер-мастере. > У реплики нет никакого понятия "принадлежности" какому-либо кворуму с > определенным лидером.