<HTML><BODY><br><br><br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">
        Среда, 25 декабря 2019, 21:23 +03:00 от Vladislav Shpilevoy <v.shpilevoy@tarantool.org>:<br><br><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15772981880161816383_BODY">Hi! Thanks for the fixes!</div></div></div></div></blockquote><br>Hi! Thanks for your answer!<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_15772981880161816383_BODY"><br>
                                 >> See 16 comments/questions below.<br>
>><br>
>> On 15/12/2019 21:58, sergepetrenko wrote:<br>
>>> This commit introduces anonymous replicas. Such replicas do not pollute<br>
>>> _cluster table (they can only be read-only and have a zero id in return).<br>
>>> An anonymous replica can be promoted to a normal one if needed.<br>
>><br>
>> 1. Do we need the promotion? Seems like it was not asked for, but we will<br>
>> need to support it forever in case we allow this now. Also it looks not<br>
>> even, when I can promote, but can't demote.<br>
> <br>
> Well, one of the use cases for anonymous replica, in my opinion, is a backup<br>
> instance, which can be promoted once one of the normal instances gets down.<br>
> (Almost like a hot standby instance).<br><br>
Fair, then lets keep it.<br><br>
> Regarding demotion, what if I add it later after giving it some thought?<br><br>
Sounds good.</div></div></div></div></blockquote><br>Opened a ticket. https://github.com/tarantool/tarantool/issues/4708<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_15772981880161816383_BODY"><br><br>
>>> +relay_final_join(io->fd, header->sync, &start_vclock, &stop_vclock);<br>
>>> +say_info("final data sent.");<br>
>>> +<br>
>>> +struct xrow_header row;<br>
>>> +/* Send end of WAL stream marker */<br>
>>> +xrow_encode_vclock_xc(&row, &replicaset.vclock);<br>
>>> +row.sync = header->sync;<br>
>>> +coio_write_xrow(io, &row);<br>
>>> +<br>
>>> +/*<br>
>>> + * Advance the WAL consumer state to the position where<br>
>>> + * FINAL JOIN ended and assign it to the replica.<br>
>>> + */<br>
>>> +gc_consumer_advance(gc, &stop_vclock);<br>
>>> +replica = replica_by_uuid(&instance_uuid);<br>
>>> +if (replica->gc != NULL)<br>
>>> +gc_consumer_unregister(replica->gc);<br>
>><br>
>> 9. How is that possible that the former anon replica has gc?<br>
> <br>
> Anon replica receives a gc registration in replica_set_id, which is called<br>
> above.<br><br>
I missed that, thanks. Then it looks ok.<br><br>
>>>  /** Vinyl run info stored in .index file */<br>
>>>  VY_INDEX_RUN_INFO = 100,<br>
>>> diff --git a/src/box/relay.cc b/src/box/relay.cc<br>
>>> index e849fcf4f..14644716d 100644<br>
>>> --- a/src/box/relay.cc<br>
>>> +++ b/src/box/relay.cc<br>
>>> @@ -569,11 +569,17 @@ relay_subscribe_f(va_list ap)<br>
>>>  cbus_pair("tx", relay->endpoint.name, &relay->tx_pipe,<br>
>>>    &relay->relay_pipe, NULL, NULL, cbus_process);<br>
>>><br>
>>> -/* Setup garbage collection trigger. */<br>
>>> +/*<br>
>>> + * Setup garbage collection trigger.<br>
>>> + * Not needed for anonymous replicas, since they<br>
>>> + * aren't registered with gc at all.<br>
>>> + */<br>
>><br>
>> 14. If a master does not register an anon replica as a gc consumer,<br>
>> it will remove xlogs even if the replica didn't get them yet. Not<br>
>> sure, if we want that behaviour. AFAIU, purpose of anon replicas<br>
>> is to break the limit on vlock size about 32 instances only.<br>
> <br>
> True, but if we do register replicas as gc consumers there is no way<br>
> to exclude them, so such a replica, in case of failure, will stall gc on master<br>
> forever. We need some mechanism, to remove anonymous replicas from gc<br>
> consumers. Normal replicas can be removed by deleting their entries from<br>
> _cluster, we cannot do this for anonymous replicas. And if we just remove<br>
> replica from gc consumer on every disconnect, there is no point in registering<br>
> it with gc at all, since the point of gc consumer, among others, is to wait for<br>
> dead replicas to reconnect and collect xlogs.<br><br>
How anon replicas are removed now? I mean when are they dropped automatically<br>
from the master? Is it done on each disconnect?</div></div></div></div></blockquote><br>
Yes, anon replicas are removed on each disconnect.<br>
<br>-- <br>Sergey Petrenko<br></BODY></HTML>