From: Serge Petrenko <sergepetrenko@tarantool.org> To: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>, tarantool-patches@dev.tarantool.org, gorcunov@gmail.com Subject: Re: [Tarantool-patches] [PATCH v2 09/11] raft: introduce state machine Date: Mon, 21 Sep 2020 11:34:20 +0300 [thread overview] Message-ID: <3fd85d58-8346-5080-4c53-5a9900e54ded@tarantool.org> (raw) In-Reply-To: <9c8db026-60e1-5079-e884-7770cdfae0d7@tarantool.org> 21.09.2020 11:22, Serge Petrenko пишет: > > 19.09.2020 18:49, Vladislav Shpilevoy пишет: >> Here is a new version of the patch after some squashes. >> >> ==================== >> raft: introduce state machine >> The commit is a core part of Raft implementation. It >> introduces >> the Raft state machine implementation and its integration into the >> instance's life cycle. >> The implementation follows the protocol to the letter >> except a few >> important details. >> Firstly, the original Raft assumes, that all nodes share >> the same >> log record numbers. In Tarantool they are called LSNs. But in case >> of Tarantool each node has its own LSN in its own component of >> vclock. That makes the election messages a bit heavier, because >> the nodes need to send and compare complete vclocks of each other >> instead of a single number like in the original Raft. But logic >> becomes simpler. Because in the original Raft there is a problem >> of uncertainty about what to do with records of an old leader >> right after a new leader is elected. They could be rolled back or >> confirmed depending on circumstances. The issue disappears when >> vclock is used. >> Secondly, leader election works differently during cluster >> bootstrap, until number of bootstrapped replicas becomes >= >> election quorum. That arises from specifics of replicas bootstrap >> and order of systems initialization. In short: during bootstrap a >> leader election may use a smaller election quorum than the >> configured one. See more details in the code. >> Part of #1146 > > Consider these fixes for applier vclock segfault pushed on top of the > branch. I've split the patch in two and placed the commits on top of `raft: relay status updates to followers` and `raft: introduce state machine` > > src/box/box.cc | 6 +----- > src/box/raft.c | 12 +++++++++--- > 2 files changed, 10 insertions(+), 8 deletions(-) > > diff --git a/src/box/box.cc b/src/box/box.cc > index c5dcbd959..1169f2cd5 100644 > --- a/src/box/box.cc > +++ b/src/box/box.cc > @@ -2160,11 +2160,7 @@ box_process_subscribe(struct ev_io *io, struct > xrow_header *header) > * should be 0. > */ > struct raft_request req; > - /* > - * Omit the candidate vclock, since we've just sent it in > - * subscribe response. > - */ > - raft_serialize_for_network(&req, NULL); > + raft_serialize_for_network(&req, &vclock); > xrow_encode_raft(&row, &fiber()->gc, &req); > coio_write_xrow(io, &row); > } > diff --git a/src/box/raft.c b/src/box/raft.c > index 7b7ef9c1c..45783f0e3 100644 > --- a/src/box/raft.c > +++ b/src/box/raft.c > @@ -130,8 +130,6 @@ raft_new_random_election_shift(void) > static inline bool > raft_can_vote_for(const struct vclock *v) > { > - if (v == NULL) > - return false; > int cmp = vclock_compare_ignore0(v, &replicaset.vclock); > return cmp == 0 || cmp == 1; > } > @@ -369,6 +367,12 @@ raft_process_msg(const struct raft_request *req, > uint32_t source) > "candidate"); > break; > } > + /* Can't vote when vclock is unknown. */ > + if (req->vclock == NULL) { > + say_info("RAFT: vote request is skipped - " > + "missing candidate vclock."); > + break; > + } > /* Can't vote for too old or incomparable nodes. */ > if (!raft_can_vote_for(req->vclock)) { > say_info("RAFT: vote request is skipped - " > @@ -858,8 +862,10 @@ raft_serialize_for_network(struct raft_request > *req, struct vclock *vclock) > req->state = raft.state; > /* > * Raft does not own vclock, so it always expects it passed > externally. > + * Vclock is sent out only by candidate instances. > */ > - req->vclock = vclock; > + if (req->state == RAFT_STATE_CANDIDATE) > + req->vclock = vclock; > } > > void -- Serge Petrenko
next prev parent reply other threads:[~2020-09-21 8:34 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-09 23:16 [Tarantool-patches] [PATCH v2 00/11] dRaft Vladislav Shpilevoy 2020-09-09 23:16 ` [Tarantool-patches] [PATCH v2 01/11] applier: store instance_id in struct applier Vladislav Shpilevoy 2020-09-14 9:38 ` Serge Petrenko 2020-09-19 15:44 ` Vladislav Shpilevoy 2020-09-21 6:23 ` Serge Petrenko 2020-09-09 23:16 ` [Tarantool-patches] [PATCH v2 10/11] raft: introduce box.info.raft Vladislav Shpilevoy 2020-09-14 9:42 ` Serge Petrenko 2020-09-09 23:16 ` [Tarantool-patches] [PATCH v2 11/11] [tosquash] raft: a swarm of minor fixes Vladislav Shpilevoy 2020-09-14 10:13 ` Serge Petrenko 2020-09-09 23:16 ` [Tarantool-patches] [PATCH v2 02/11] box: introduce summary RO flag Vladislav Shpilevoy 2020-09-09 23:16 ` [Tarantool-patches] [PATCH v2 03/11] wal: don't touch box.cfg.wal_dir more than once Vladislav Shpilevoy 2020-09-09 23:16 ` [Tarantool-patches] [PATCH v2 04/11] replication: track registered replica count Vladislav Shpilevoy 2020-09-09 23:16 ` [Tarantool-patches] [PATCH v2 05/11] [wip] box: do not register outgoing connections Vladislav Shpilevoy 2020-09-09 23:16 ` [Tarantool-patches] [PATCH v2 06/11] raft: introduce persistent raft state Vladislav Shpilevoy 2020-09-09 23:16 ` [Tarantool-patches] [PATCH v2 07/11] raft: introduce box.cfg.raft_* options Vladislav Shpilevoy 2020-09-09 23:16 ` [Tarantool-patches] [PATCH v2 08/11] raft: relay status updates to followers Vladislav Shpilevoy 2020-09-20 17:17 ` Vladislav Shpilevoy 2020-09-21 7:13 ` Serge Petrenko 2020-09-21 10:50 ` Serge Petrenko 2020-09-21 22:47 ` Vladislav Shpilevoy 2020-09-22 8:48 ` Serge Petrenko 2020-09-21 22:47 ` Vladislav Shpilevoy 2020-09-22 8:47 ` Serge Petrenko 2020-09-09 23:17 ` [Tarantool-patches] [PATCH v2 09/11] raft: introduce state machine Vladislav Shpilevoy 2020-09-19 15:49 ` Vladislav Shpilevoy 2020-09-19 15:50 ` Vladislav Shpilevoy 2020-09-21 8:20 ` Serge Petrenko 2020-09-21 8:22 ` Serge Petrenko 2020-09-21 8:34 ` Serge Petrenko [this message] 2020-09-21 22:47 ` Vladislav Shpilevoy 2020-09-22 8:49 ` Serge Petrenko 2020-09-22 22:48 ` Vladislav Shpilevoy 2020-09-23 9:59 ` Serge Petrenko 2020-09-23 20:31 ` Vladislav Shpilevoy 2020-09-24 9:34 ` Serge Petrenko 2020-09-19 15:58 ` [Tarantool-patches] [PATCH v2 12/11] dRaft Vladislav Shpilevoy 2020-09-19 15:59 ` Vladislav Shpilevoy 2020-09-21 7:24 ` Serge Petrenko 2020-09-21 22:48 ` [Tarantool-patches] [PATCH v2 12/11] raft: add tests Vladislav Shpilevoy 2020-09-30 10:56 ` [Tarantool-patches] [PATCH v2 00/11] dRaft Kirill Yukhin
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=3fd85d58-8346-5080-4c53-5a9900e54ded@tarantool.org \ --to=sergepetrenko@tarantool.org \ --cc=gorcunov@gmail.com \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v2 09/11] raft: introduce state machine' \ /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