>Пятница, 27 декабря 2019, 16:31 +03:00 от Konstantin Osipov : > >* 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