From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from [87.239.111.99] (localhost [127.0.0.1]) by dev.tarantool.org (Postfix) with ESMTP id 7525E6F3C7; Fri, 26 Mar 2021 16:46:27 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 7525E6F3C7 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1616766387; bh=eyi8ZAW5o6SDaEfpY6r6s0U0xxQcMMIB9zD303sQ558=; h=Date:To:Cc:References:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=Ut1XSJZ0OxhcJwPZA5PYjyC/WezOvSshB3wHIcwn5I+WzcFcqgWw+QqfsQKZv77wO 9nX+yRsg1uhw00+5IrTr2NEO6dInXEC4RxGZ/5N5VWwuxwL/aV+Mm+QzO2vPFfiP/+ ftx/cX3SmQOTQIZ3yd/RV9axTlYkSqdZuRLAG2kE= Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 9398F6F3C7 for ; Fri, 26 Mar 2021 16:46:26 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 9398F6F3C7 Received: by mail-lf1-f41.google.com with SMTP id g8so7724373lfv.12 for ; Fri, 26 Mar 2021 06:46:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=LSBuUbMeuqt6UnMghJTtmbjJs1VcdGqslNJuOgwldrQ=; b=pYdibFv3AFvFzLc3SLaB98orSA4Lo2+RWeickvLbOwmRSYuAhdAnOnHWJrOJVngwHE Z98A00TTsvtXBcIGj9tR0293gDX7Wb6Qo0tI9oBXyB1/CValNz46HvJbrQ8Lx03B7SjH VSUQw8J+kZ+TaqNIRbnImB+qFMqXjYB5+8G8OdvMrULmzfOMij1sonJW2/pPUk4VzVQz Q6KeVq6ng00rDlxOTV9Igjm8olnl4dk01ZPrOGVkQMUbhAz6Ti+DGWVk/JO/tZjwKIl4 pbaNMNGeoe4ht6gjqcaCIp19PBkzda6818qpdg7bvGaJHNh0vFbG40UGpzBQODLlawFG R/bQ== X-Gm-Message-State: AOAM5338/PTmwL+K2Nidwg15au2I3f0VE0tt71qigFx5D6jido/sbGEQ 8mb/q9pmoYrEJ1GxSutOW9VV/wCg7h+5JQ== X-Google-Smtp-Source: ABdhPJzoR768+DJc4lxGY5NZLfrO/Qzscs0tuZgfXD1lDFF/b/CF8oxLV76AyQrJkae+j+Ctv/4Emg== X-Received: by 2002:ac2:5e6a:: with SMTP id a10mr8280525lfr.181.1616766385589; Fri, 26 Mar 2021 06:46:25 -0700 (PDT) Received: from grain.localdomain ([5.18.171.94]) by smtp.gmail.com with ESMTPSA id x13sm1176863ljj.4.2021.03.26.06.46.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 26 Mar 2021 06:46:24 -0700 (PDT) Received: by grain.localdomain (Postfix, from userid 1000) id A396A560179; Fri, 26 Mar 2021 16:46:23 +0300 (MSK) Date: Fri, 26 Mar 2021 16:46:23 +0300 To: Serge Petrenko Cc: v.shpilevoy@tarantool.org, tarantool-patches@dev.tarantool.org Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0.5 (2021-01-21) Subject: Re: [Tarantool-patches] [PATCH v2 0/7] applier: handle synchronous transactions during final X-BeenThere: tarantool-patches@dev.tarantool.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Cyrill Gorcunov via Tarantool-patches Reply-To: Cyrill Gorcunov Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On Wed, Mar 24, 2021 at 03:24:10PM +0300, Serge Petrenko wrote: > Initially this patches idea was to ignore synchronous rows on applier side and > make it so that there are no rolled back transactions in final join stream on > master side. > > Unfortunately, this easy fix didn't work. The reason for it is that once the > replica receives initial data, up to `start_vclock`, the final join stream has > to start right at `start_vclock` so that we do not lose any transactions. > > This means that once master encounters a synchro rollback and makes replica > retry final join to get rid of the rollback, it still has to send it together > with other data. And this rollback must be processed by applier to avoid > conflicts. > > In order to let applier process synchro requests (CONFIRM and ROLLBACK) we need > to make final join transactional, obviously. This is what this patchset does. > > An alternative would be to retry not only final, but also initial join every > time master receives a rollback during final join stage. This would be too > violent due to possibly huge data amounts being sent during initial join. I don't see any obvious problems in the series but I'm far from being replication expert, still Ack