<HTML><BODY><br><br><br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">
Пятница, 27 декабря 2019, 16:31 +03:00 от Konstantin Osipov <kostja.osipov@gmail.com>:<br><br><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15774534910654622786_BODY">* Sergey Petrenko <<a href="mailto:sergepetrenko@tarantool.org">sergepetrenko@tarantool.org</a>> [19/12/27 15:56]:<br>
> >Четверг, 26 декабря 2019, 8:03 +03:00 от Konstantin Osipov <<a href="mailto:kostja.osipov@gmail.com">kostja.osipov@gmail.com</a>>:<br>
> I couldn't find any code where id 0 is reserved.<br><br>
It is used in initial join.</div></div></div></div></blockquote><br>Yes, master sends snapshot rows with id 0 and 0 lsn, but this doesn't<br>interfere with my change, AFAICS.<br><br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15774534910654622786_BODY"><br><br>
> What do you mean by "the changes of expelled replicas"?<br><br>
Check the comment in replica_clear_id. Right now when you delete<br>
replica from _cluster, you keep its slot in vclock. The goal is to<br>
reuse it.<br><br>
> However, it's true that vclock comparisons are used in creating snapshots<br>
> and finding the latest xlog on recovery.<br>
> So an anonymous replica won't create new snapshots if the only new changes<br>
> are the one made on the anonymous replica. Some problems with recovery may<br>
> also exist. I don't know whether it's severe enough, but looks not so good.<br>
> Thanks for pointing this out!<br>
> <br>
> ><br>
> ><br>
> > A much safer bet would be to use a new special id number, like<br>
> > UINT64_MAX, and not change meaning of an existing id.<br>
> <br>
> This won't help IMO. We still have cases where this vclock component<br>
> should be ignored (replication) and cases where it should be taken into<br>
> account (checkpoint/xlog clock).<br>
> What about this change? I pushed it to the branch.<br>
> Also there's no need to fix vclock tests anymore.<br><br>
It is also a hack. It's best if all of the complexity of an<br>
anonymous replica resides on it and the master doesn't deal with<br>
it in any way. Refusing the connection from master with a proper<br>
error message seems to be simple & reliable way to do it without<br>
mangling vclock logic.</div></div></div></div></blockquote><br>Both places where vclock_compare ignores 0 component are on<br>anon replica side. First place is checking whether we are in sync with<br>master, the second place is finding replicaset leader.<br><br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15774534910654622786_BODY"><br><br>
The anonymous replica would still have to find a legal slot in<br>
vclock for its own changes, but this would be a standard slot. </div></div></div></div></blockquote><br>If I understand you correctly, this implies some kind of replica id remapping.<br>Otherwise no one guarantees that a non-anonymous instance with same id<br>won't be added later. Also we can use anonymous replicas in a cluster with<br>32 "normal" replicas. Where to find a valid slot then?<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15774534910654622786_BODY"><br><br>
-- <br>
Konstantin Osipov, Moscow, Russia<br></div></div></div></div></blockquote>
<br>
<br>-- <br>Sergey Petrenko<br></BODY></HTML>