Re: [Tarantool-patches] [PATCH v3 2/4] recovery: allow to ignore rows coming from a certain instance

[Serge Petrenko <sergepetrenko@tarantool.org>]

> 19 февр. 2020 г., в 11:52, Konstantin Osipov <kostja.osipov@gmail.com> написал(а):
> 
> * Serge Petrenko <sergepetrenko@tarantool.org> [20/02/19 11:45]:
>>> This is a strange way to mute rows from self. Why not set vclock
>>> component to infinity as I suggested multiple times? Why not
>>> respond to me with objection if my suggestion  can not be done?
>> 
>> I responded with a patch, so now we can discuss both your and my suggestions.
> 
> No, we can't. You responded with a patch for your suggestion, but
> not for mine. So we compare apples and oranges here. Just like
> with Ilya's patch, which only half way captured my suggestion in
> his "alternatives".
> 
> In the end I'm not even sure you got it right.



> 
>> If I understood you correctly, you suggested to set replica self lsn to infinity
>> (on master side), so that recovery on masters side would skip replicas rows.
>> 

Does it look like I got it right from my answer?

>> I tried your approach and initialized recovery with vclock[replica_id] = INT64_MAX.
>> This does allow you to skip replica’s rows, but this breaks vclock signature, which will
>> overflow immediately. vclock signatures are used to order gc consumers, gc
>> consumer corresponding to a replica gets its vclock from relay recovery.
>> Ok, you could suggest to reset vclock[replica_id] to some meaningful value, but where
>> do you get this value from? You cannot do gc message vclock[replica_id] =
>> replica ack vclock[replica_id], because replica may have some rows you still
>> don’t have. Then replica ack vclock signature may get too big and you will delete
>> other logs containing your changes.
>> You also cannot set gc vclock[replica_id] to 0, because it will hold logs, not needed by
>> replica for too long.
> 
> Please send a patch and we'll be able to discuss where it went
> wrong for you.

Ok

> 
> 
> -- 
> Konstantin Osipov, Moscow, Russia


--
Serge Petrenko
sergepetrenko@tarantool.org