From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTP id 249A92BB7B for ; Thu, 11 Apr 2019 03:32:58 -0400 (EDT) Received: from turing.freelists.org ([127.0.0.1]) by localhost (turing.freelists.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I22LTB68uz_6 for ; Thu, 11 Apr 2019 03:32:58 -0400 (EDT) Received: from smtp29.i.mail.ru (smtp29.i.mail.ru [94.100.177.89]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by turing.freelists.org (Avenir Technologies Mail Multiplex) with ESMTPS id CE77B29130 for ; Thu, 11 Apr 2019 03:32:57 -0400 (EDT) Received: by smtp29.i.mail.ru with esmtpa (envelope-from ) id 1hEUCd-0008Vv-TP for tarantool-patches@freelists.org; Thu, 11 Apr 2019 10:32:56 +0300 Date: Thu, 11 Apr 2019 10:32:55 +0300 From: Konstantin Osipov Subject: [tarantool-patches] Re: [PATCH 2/2] replication: fix garbage collection logic Message-ID: <20190411073255.GB31100@chai> References: <24d1ce5202869981a2182ff1c7947d7d4914bb5b.1554829366.git.vdavydov.dev@gmail.com> <44bdf3f4affee3c95cf9b23add24c30dece44151.1554829366.git.vdavydov.dev@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44bdf3f4affee3c95cf9b23add24c30dece44151.1554829366.git.vdavydov.dev@gmail.com> Sender: tarantool-patches-bounce@freelists.org Errors-to: tarantool-patches-bounce@freelists.org Reply-To: tarantool-patches@freelists.org List-Help: List-Unsubscribe: List-software: Ecartis version 1.0.0 List-Id: tarantool-patches List-Subscribe: List-Owner: List-post: List-Archive: To: tarantool-patches@freelists.org * 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. I still think we need a special compare function, which ignores one specified dimension, and we should change vclock_compare in recover_remaining_wals and this vclock_compare to use it. This dimension is the server id of replica we're feeding wals to. The logic is that we should not bother with feeding replica its own changes, and depend on having these changes. This will make vclocks comparable even if replica has local changes, and master has local changes, and some of the xlogs which predate these changes are already missing. -- Konstantin Osipov, Moscow, Russia, +7 903 626 22 32 http://tarantool.io - www.twitter.com/kostja_osipov