From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp34.i.mail.ru (smtp34.i.mail.ru [94.100.177.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id C8E01469719 for ; Wed, 19 Feb 2020 11:57:43 +0300 (MSK) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) From: Serge Petrenko In-Reply-To: <20200219085254.GB6538@atlas> Date: Wed, 19 Feb 2020 11:57:42 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <1C823375-D749-4A76-960D-2B45FD987A80@tarantool.org> References: <257cb279bd1b62ef6ff98aa4fa7226ba1bf3b2d0.1582046958.git.sergepetrenko@tarantool.org> <20200218190324.GB20569@atlas> <93920A98-9B17-43AB-86C2-494161FC032B@tarantool.org> <20200219085254.GB6538@atlas> Subject: Re: [Tarantool-patches] [PATCH v3 2/4] recovery: allow to ignore rows coming from a certain instance List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , Vladislav Shpilevoy , Alexander Turenko Cc: tarantool-patches@dev.tarantool.org > 19 =D1=84=D0=B5=D0=B2=D1=80. 2020 =D0=B3., =D0=B2 11:52, Konstantin = Osipov =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB= (=D0=B0): >=20 > * Serge Petrenko [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? >>=20 >> I responded with a patch, so now we can discuss both your and my = suggestions. >=20 > 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". >=20 > In the end I'm not even sure you got it right. >=20 >> 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. >>=20 Does it look like I got it right from my answer? >> I tried your approach and initialized recovery with = vclock[replica_id] =3D INT64_MAX. >> This does allow you to skip replica=E2=80=99s 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] =3D >> replica ack vclock[replica_id], because replica may have some rows = you still >> don=E2=80=99t 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. >=20 > Please send a patch and we'll be able to discuss where it went > wrong for you. Ok >=20 >=20 > --=20 > Konstantin Osipov, Moscow, Russia -- Serge Petrenko sergepetrenko@tarantool.org