From: Aleksandr Lyapunov <alyapunov@tarantool.org> To: "Vladislav Shpilevoy" <v.shpilevoy@tarantool.org>, "s.ostanevich" <s.ostanevich@corp.mail.ru>, "Mons Anderson" <v.perepelitsa@corp.mail.ru>, "Николай Карлов" <nikolay.karlov@corp.mail.ru>, "Yukhin Kirill" <k.yukhin@corp.mail.ru>, "Serge Petrenko" <sergepetrenko@tarantool.org>, tarantool-discussions@dev.tarantool.org Subject: Re: [Tarantool-discussions] Synch replication: tests Date: Tue, 28 Apr 2020 15:24:00 +0300 [thread overview] Message-ID: <0c51df15-0d43-04af-9cf6-2b2a1d7004e3@tarantool.org> (raw) In-Reply-To: <bcf561b0-6438-e6c5-b9bd-af284469e1b5@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 где М - число узлов в кластере. > Непонятно, что этому препятствует. Защиты никакой нет. Если у нас фулмеш, > и два мастера считают себя лидерами, и пишут неконфликтующие транзакции, то > все реплики будут спокойно применять их обоих, как и при нынешнем мастер-мастере. > У реплики нет никакого понятия "принадлежности" какому-либо кворуму с > определенным лидером.
next parent reply other threads:[~2020-04-28 12:24 UTC|newest] Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <77CF6795-FDF3-4C54-89EF-0CD7F55F1A09@corp.mail.ru> [not found] ` <bcf561b0-6438-e6c5-b9bd-af284469e1b5@tarantool.org> 2020-04-28 12:24 ` Aleksandr Lyapunov [this message] 2020-04-28 15:51 ` s.ostanevich
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=0c51df15-0d43-04af-9cf6-2b2a1d7004e3@tarantool.org \ --to=alyapunov@tarantool.org \ --cc=k.yukhin@corp.mail.ru \ --cc=nikolay.karlov@corp.mail.ru \ --cc=s.ostanevich@corp.mail.ru \ --cc=sergepetrenko@tarantool.org \ --cc=tarantool-discussions@dev.tarantool.org \ --cc=v.perepelitsa@corp.mail.ru \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-discussions] Synch replication: tests' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox