From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp49.i.mail.ru (smtp49.i.mail.ru [94.100.177.109]) (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 147BE4696C3 for ; Thu, 23 Apr 2020 14:19:18 +0300 (MSK) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) From: Serge Petrenko In-Reply-To: <20200423095413.GE3072@uranus> Date: Thu, 23 Apr 2020 14:19:17 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <42CB7321-961C-4E58-A632-4326936882C3@tarantool.org> References: <20200422182810.79257-1-sergepetrenko@tarantool.org> <20200423094112.GD3072@uranus> <28487782-9C98-432A-95E1-A3583C96A564@tarantool.org> <20200423095413.GE3072@uranus> Subject: Re: [Tarantool-patches] [PATCH] applier: follow vclock to the last tx row List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Cyrill Gorcunov Cc: tarantool-patches@dev.tarantool.org, Vladislav Shpilevoy > 23 =D0=B0=D0=BF=D1=80. 2020 =D0=B3., =D0=B2 12:54, Cyrill Gorcunov = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >=20 > On Thu, Apr 23, 2020 at 12:53:30PM +0300, Serge Petrenko wrote: >>=20 >>> 23 =D0=B0=D0=BF=D1=80. 2020 =D0=B3., =D0=B2 12:41, Cyrill Gorcunov = =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(=D0=B0): >>>=20 >>> On Wed, Apr 22, 2020 at 09:28:10PM +0300, Serge Petrenko wrote: >>>> Since the introduction of transaction boundaries in replication >>>> protocol, appliers follow replicaset.applier.vclock to the lsn of = the >>>> first row in an arrived batch. This is enough and doesn't lead to = errors >>>> when replicating from other instances, respecting transaction = boundaries >>>> (instances with version 2.1.2 and up). However, if there's a 1.10 >>>> instance in 2.1.2+ cluster, it sends every single tx row as a = separate >>>> transaction, breaking the comparison with replicaset.applier.vclock = and >>>> making the applier apply part of the changes, it has already = applied >>>> when processing a full transaction coming from another 2.x = instance. >>>> Such behaviour leads to ER_TUPLE_FOUND errors in the scenario = described >>>> above. >>>> In order to guard from such cases, follow replicaset.applier.vclock = to >>>> the lsn of the last row in tx. >>>>=20 >>>> Closes #4924 > Reviewed-by: Cyrill Gorcunov >=20 > Thanks! @ChangeLog - fix possible ER_TUPLE_FOUND error when bootstrapping 2.2+ replicas in an 1.10/2.1.1 cluster (gh-4924) -- Serge Petrenko sergepetrenko@tarantool.org