From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Date: Thu, 11 Apr 2019 14:01:26 +0300 From: Vladimir Davydov Subject: Re: [tarantool-patches] Re: [PATCH 2/2] replication: fix garbage collection logic Message-ID: <20190411110126.6k3lf3arjzgo5wyh@esperanza> References: <24d1ce5202869981a2182ff1c7947d7d4914bb5b.1554829366.git.vdavydov.dev@gmail.com> <44bdf3f4affee3c95cf9b23add24c30dece44151.1554829366.git.vdavydov.dev@gmail.com> <20190411073255.GB31100@chai> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190411073255.GB31100@chai> To: Konstantin Osipov Cc: tarantool-patches@freelists.org List-ID: On Thu, Apr 11, 2019 at 10:32:55AM +0300, Konstantin Osipov wrote: > * Vladimir Davydov [19/04/09 20:09]: > > Currently, the garbage collector works with vclock signatures and > > doesn't take into account vclock components. This works as long as > > the caller (i.e. relay) makes sure that it doesn't advance a consumer > > associated with a replica unless its acknowledged vclock is greater > > than or equal to the vclock of a WAL file fed to it. The bug is that > > it does not - it only compares vclock signatures. As a result, if > > a replica has some local changes or changes pulled from other members > > of the cluster, which render its signature greater, the master may > > remove files that are still needed by the replica, permanently breaking > > replication and requiring rebootstrap. > > > > I guess the proper fix would be teaching the garbage collector > > operate on vclock components rather than signatures, but it's rather > > difficult to implement. This patch is a quick fix, which simply > > replaces vclock signature comparison in relay with vclock_compare. > > This patch is OK to push. Pushed to master, 2.1, 1.10.