From: Konstantin Osipov <kostja.osipov@gmail.com>
To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [RFC] Quorum-based synchronous replication
Date: Thu, 14 May 2020 02:54:48 +0300 [thread overview]
Message-ID: <20200513235448.GC5698@atlas> (raw)
In-Reply-To: <78713377-806f-8cf6-efe0-5019f3d3e428@tarantool.org>
* Vladislav Shpilevoy <v.shpilevoy@tarantool.org> [20/05/14 00:42]:
> > Sure yes, if it restarted - then connection lost can't be unnoticed by
> > anyone, be it coordinator or cluster.
>
> Here comes another problem. Disconnect and restart have nothing to do with
> each other. The coordinator can loose connection without the peer leader
> restart. Just because it is network. Anything can happen. Moreover, while
> the coordinator does not have a connection, the leader can restart multiple
> times.
yes.
> We can't tell the coordinator rely on connectivity as a restart signal.
Well, we could demand that the leader always demotes itself after
restart. But the spec should be explicit about it and explain how
the election happens in this case, because it still may have the
longest WAL (but with some junk in it, thanks to lost confirms),
so after restart the leader may need to reconcile its wal with the
majority, fetching missing records back.
Once again, RAFT is very explicit about this. By default it
requires that the leader commit log is durable, i.e.
wal_mode=sync. This would kill performance. Implementations exist
which run in wal_mode=write (cassandra is one of them), but they know how to
repair the log at the leader before proceeding with the next
transaction. The reason I brought this up is that it's extremely
tricky, and confusing as hell if the election is external (agree
there should be an API, or better yet, abandon the idea of
external election, just have no election for now at all, assume
the leader never changes, and we only provide durability in
multi-master config), with no consistency guarantees (but eventual
one).
> > How a restart can be unnoticed, if it causes disconnection?
>
> Disconnection has nothing to do with restart. The coordinator itself may
> restart. Or it may loose connection to the leader temporarily. Or the
> leader may loose it without any restarts.
and yes.
--
Konstantin Osipov, Moscow, Russia
next prev parent reply other threads:[~2020-05-13 23:54 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-03 21:08 Sergey Ostanevich
2020-04-07 13:02 ` Aleksandr Lyapunov
2020-04-08 9:18 ` Sergey Ostanevich
2020-04-08 14:05 ` Konstantin Osipov
2020-04-08 15:06 ` Sergey Ostanevich
2020-04-14 12:58 ` Sergey Bronnikov
2020-04-14 14:43 ` Sergey Ostanevich
2020-04-15 11:09 ` sergos
2020-04-15 14:50 ` sergos
2020-04-16 7:13 ` Aleksandr Lyapunov
2020-04-17 10:10 ` Konstantin Osipov
2020-04-17 13:45 ` Sergey Ostanevich
2020-04-20 11:20 ` Serge Petrenko
2020-04-20 23:32 ` Vladislav Shpilevoy
2020-04-21 10:49 ` Sergey Ostanevich
2020-04-21 22:17 ` Vladislav Shpilevoy
2020-04-22 16:50 ` Sergey Ostanevich
2020-04-22 20:28 ` Vladislav Shpilevoy
2020-04-23 6:58 ` Konstantin Osipov
2020-04-23 9:14 ` Konstantin Osipov
2020-04-23 11:27 ` Sergey Ostanevich
2020-04-23 11:43 ` Konstantin Osipov
2020-04-23 15:11 ` Sergey Ostanevich
2020-04-23 20:39 ` Konstantin Osipov
2020-04-23 21:38 ` Vladislav Shpilevoy
2020-04-23 22:28 ` Konstantin Osipov
2020-04-30 14:50 ` Sergey Ostanevich
2020-05-06 8:52 ` Konstantin Osipov
2020-05-06 16:39 ` Sergey Ostanevich
2020-05-06 18:44 ` Konstantin Osipov
2020-05-12 15:55 ` Sergey Ostanevich
2020-05-12 16:42 ` Konstantin Osipov
2020-05-13 21:39 ` Vladislav Shpilevoy
2020-05-13 23:54 ` Konstantin Osipov [this message]
2020-05-14 20:38 ` Sergey Ostanevich
2020-05-20 20:59 ` Sergey Ostanevich
2020-05-25 23:41 ` Vladislav Shpilevoy
2020-05-27 21:17 ` Sergey Ostanevich
2020-06-09 16:19 ` Sergey Ostanevich
2020-06-11 15:17 ` Vladislav Shpilevoy
2020-06-12 20:31 ` Sergey Ostanevich
2020-05-13 21:36 ` Vladislav Shpilevoy
2020-05-13 23:45 ` Konstantin Osipov
2020-05-06 18:55 ` Konstantin Osipov
2020-05-06 19:10 ` Konstantin Osipov
2020-05-12 16:03 ` Sergey Ostanevich
2020-05-13 21:42 ` Vladislav Shpilevoy
2020-05-14 0:05 ` Konstantin Osipov
2020-05-07 23:01 ` Konstantin Osipov
2020-05-12 16:40 ` Sergey Ostanevich
2020-05-12 17:47 ` Konstantin Osipov
2020-05-13 21:34 ` Vladislav Shpilevoy
2020-05-13 23:31 ` Konstantin Osipov
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=20200513235448.GC5698@atlas \
--to=kostja.osipov@gmail.com \
--cc=tarantool-patches@dev.tarantool.org \
--cc=v.shpilevoy@tarantool.org \
--subject='Re: [Tarantool-patches] [RFC] Quorum-based synchronous replication' \
/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