From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 9E055469719 for ; Wed, 26 Feb 2020 13:23:21 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id q8so2408960ljj.11 for ; Wed, 26 Feb 2020 02:23:21 -0800 (PST) Date: Wed, 26 Feb 2020 13:23:19 +0300 From: Konstantin Osipov Message-ID: <20200226102319.GB15433@atlas> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Tarantool-patches] [PATCH v4 4/4] replication: do not relay rows coming from a remote instance back to it List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: sergepetrenko Cc: kirichenkoga@gmail.com, tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org * sergepetrenko [20/02/26 13:00]: > From: Serge Petrenko > > We have a mechanism for restoring rows originating from an instance that > suffered a sudden power loss: remote masters resend the isntance's rows > received before a certain point in time, defined by remote master vclock > at the moment of subscribe. > However, this is useful only on initial replication configuraiton, when > an instance has just recovered, so that it can receive what it has > relayed but haven't synced to disk. > In other cases, when an instance is operating normally and master-master > replication is configured, the mechanism described above may lead to > instance re-applying instance's own rows, coming from a master it has just > subscribed to. > To fix the problem do not relay rows coming from a remote instance, if > the instance has already recovered. > A comment like this also belongs to the code. Usually the patch that fixes a bug comes along with a test case for a bug, are you sure you can't submit one? > vclock_copy(&vclock, &replicaset.vclock); > + unsigned int id_mask = box_is_orphan() ? 0 : 1 << instance_id; box_is_orphan() fits the bill, so it's good enough. I would explain, however, that what we are really looking for here is whether or not the local WAL accepts writes. As soon as we started allowing writes to the local WAL, we don't want to get these writes from elsewhere. -- Konstantin Osipov, Moscow, Russia