Tarantool development patches archive
 help / color / mirror / Atom feed
From: "Sergey Petrenko" <sergepetrenko@tarantool.org>
To: "Konstantin Osipov" <kostja.osipov@gmail.com>
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:48:34 +0300	[thread overview]
Message-ID: <1577454514.172951629@f509.i.mail.ru> (raw)
In-Reply-To: <20191227133127.GA29577@atlas>

[-- Attachment #1: Type: text/plain, Size: 2468 bytes --]




>Пятница, 27 декабря 2019, 16:31 +03:00 от Konstantin Osipov <kostja.osipov@gmail.com>:
>
>* 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.
Yes, master sends snapshot rows with id 0 and 0 lsn, but this doesn't
interfere with my change, AFAICS.

>
>
>> 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.
Both places where vclock_compare ignores 0 component are on
anon replica side. First place is checking whether we are in sync with
master, the second place is finding replicaset leader.

>
>
>The anonymous replica would still have to find  a legal slot in
>vclock for its own changes, but this would be a standard slot. 
If I understand you correctly, this implies some kind of replica id remapping.
Otherwise no one guarantees that a non-anonymous instance with same id
won't be added later. Also we can use anonymous replicas in a cluster with
32 "normal" replicas. Where to find a valid slot then?
>
>
>-- 
>Konstantin Osipov, Moscow, Russia


-- 
Sergey Petrenko

[-- Attachment #2: Type: text/html, Size: 3787 bytes --]

  reply	other threads:[~2019-12-27 13:48 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
2019-12-27 13:48           ` Sergey Petrenko [this message]
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=1577454514.172951629@f509.i.mail.ru \
    --to=sergepetrenko@tarantool.org \
    --cc=kostja.osipov@gmail.com \
    --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