Tarantool development patches archive
 help / color / mirror / Atom feed
From: Konstantin Osipov <kostja@tarantool.org>
To: tarantool-patches@freelists.org
Subject: [tarantool-patches] Re: [PATCH 2/2] replication: fix garbage collection logic
Date: Thu, 11 Apr 2019 10:32:55 +0300	[thread overview]
Message-ID: <20190411073255.GB31100@chai> (raw)
In-Reply-To: <44bdf3f4affee3c95cf9b23add24c30dece44151.1554829366.git.vdavydov.dev@gmail.com>

* Vladimir Davydov <vdavydov.dev@gmail.com> [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

  reply	other threads:[~2019-04-11  7:32 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-09 17:07 [PATCH 1/2] Revert "replication: update replica gc state on subscribe" Vladimir Davydov
2019-04-09 17:07 ` [PATCH 2/2] replication: fix garbage collection logic Vladimir Davydov
2019-04-11  7:32   ` Konstantin Osipov [this message]
2019-04-11  8:25     ` [tarantool-patches] " Vladimir Davydov
2019-04-11 11:01     ` Vladimir Davydov
2019-04-11 10:25 ` [tarantool-patches] Re: [PATCH 1/2] Revert "replication: update replica gc state on subscribe" Konstantin Osipov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190411073255.GB31100@chai \
    --to=kostja@tarantool.org \
    --cc=tarantool-patches@freelists.org \
    --subject='[tarantool-patches] Re: [PATCH 2/2] replication: fix garbage collection logic' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox