From: Konstantin Osipov <kostja.osipov@gmail.com> To: Sergey Petrenko <sergepetrenko@tarantool.org> Cc: Vladislav Shpilevoy <v.shpilevoy@tarantool.org>, tarantool-patches <tarantool-patches@dev.tarantool.org> Subject: Re: [Tarantool-patches] [PATCH 4/5] vclock: ignore 0th component in comparisons. Date: Fri, 27 Dec 2019 16:31:27 +0300 [thread overview] Message-ID: <20191227133127.GA29577@atlas> (raw) In-Reply-To: <1577451369.509620710@f196.i.mail.ru> * Sergey Petrenko <sergepetrenko@tarantool.org> [19/12/27 15:56]: > >Четверг, 26 декабря 2019, 8:03 +03:00 от Konstantin Osipov <kostja.osipov@gmail.com>: > I couldn't find any code where id 0 is reserved. It is used in initial join. > What do you mean by "the changes of expelled replicas"? Check the comment in replica_clear_id. Right now when you delete replica from _cluster, you keep its slot in vclock. The goal is to reuse it. > However, it's true that vclock comparisons are used in creating snapshots > and finding the latest xlog on recovery. > So an anonymous replica won't create new snapshots if the only new changes > are the one made on the anonymous replica. Some problems with recovery may > also exist. I don't know whether it's severe enough, but looks not so good. > Thanks for pointing this out! > > > > > > > A much safer bet would be to use a new special id number, like > > UINT64_MAX, and not change meaning of an existing id. > > This won't help IMO. We still have cases where this vclock component > should be ignored (replication) and cases where it should be taken into > account (checkpoint/xlog clock). > What about this change? I pushed it to the branch. > Also there's no need to fix vclock tests anymore. It is also a hack. It's best if all of the complexity of an anonymous replica resides on it and the master doesn't deal with it in any way. Refusing the connection from master with a proper error message seems to be simple & reliable way to do it without mangling vclock logic. The anonymous replica would still have to find a legal slot in vclock for its own changes, but this would be a standard slot. -- Konstantin Osipov, Moscow, Russia
next prev parent reply other threads:[~2019-12-27 13:31 UTC|newest] Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-12-15 20:56 [Tarantool-patches] [PATCH 0/5] introduce anonymous replicas sergepetrenko 2019-12-15 20:58 ` [Tarantool-patches] [PATCH 1/5] box: update comment describing join protocol sergepetrenko 2019-12-22 17:58 ` Vladislav Shpilevoy 2019-12-23 21:12 ` Sergey Petrenko 2019-12-15 20:58 ` [Tarantool-patches] [PATCH 2/5] replication: do not decode replicaset uuid when processing a subscribe sergepetrenko 2019-12-15 20:58 ` [Tarantool-patches] [PATCH 3/5] applier: split join processing into two stages sergepetrenko 2019-12-22 17:59 ` Vladislav Shpilevoy 2019-12-23 22:10 ` Sergey Petrenko 2019-12-24 15:50 ` Vladislav Shpilevoy 2019-12-15 20:58 ` [Tarantool-patches] [PATCH 4/5] vclock: ignore 0th component in comparisons sergepetrenko 2019-12-22 17:59 ` Vladislav Shpilevoy 2019-12-23 21:26 ` Sergey Petrenko 2019-12-23 22:58 ` Sergey Petrenko 2019-12-26 4:43 ` Konstantin Osipov 2019-12-26 5:02 ` Konstantin Osipov 2019-12-27 12:56 ` Sergey Petrenko 2019-12-27 13:31 ` Konstantin Osipov [this message] 2019-12-27 13:48 ` Sergey Petrenko 2019-12-27 14:40 ` Konstantin Osipov 2019-12-15 20:58 ` [Tarantool-patches] [PATCH 5/5] replication: introduce anonymous replica sergepetrenko 2019-12-16 13:28 ` Serge Petrenko 2019-12-20 12:06 ` Serge Petrenko 2019-12-22 17:58 ` Vladislav Shpilevoy 2019-12-25 12:40 ` Sergey Petrenko 2019-12-25 18:23 ` Vladislav Shpilevoy 2019-12-26 16:08 ` Sergey Petrenko 2019-12-15 21:00 ` [Tarantool-patches] [PATCH 0/5] introduce anonymous replicas Sergey Petrenko 2019-12-18 7:49 ` Georgy Kirichenko 2019-12-20 12:07 ` Serge Petrenko 2019-12-20 12:17 ` Serge Petrenko 2019-12-22 17:59 ` Vladislav Shpilevoy
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=20191227133127.GA29577@atlas \ --to=kostja.osipov@gmail.com \ --cc=sergepetrenko@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --cc=v.shpilevoy@tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH 4/5] vclock: ignore 0th component in comparisons.' \ /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