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 12A3F6EC5D; Mon, 5 Apr 2021 19:15:42 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 12A3F6EC5D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1617639342; bh=0+8s+NrTcmvsZtnExWOyP41O3pGrWvKETftc25+J2t4=; h=Date:To:References:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=hIFzjmqfIGY6H25CIDM3ZwLFV8x+Ni9nYT7uFUKsTi2sZ2EelBfyEucrjJuw5puwE szLuFmETzWsvIzEkBVkHnb27MZoP5jCC6B8R0sHppylEr7vEmBgD2Nv5QYXCZFtP9e /JKWcl3VeEAo8zcPAzut1NAswcqUeq0UO4MXX1jI= Received: from smtp53.i.mail.ru (smtp53.i.mail.ru [94.100.177.113]) (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 37A5F6EC5D for ; Mon, 5 Apr 2021 19:15:40 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 37A5F6EC5D Received: by smtp53.i.mail.ru with esmtpa (envelope-from ) id 1lTRt5-0003XV-Hx; Mon, 05 Apr 2021 19:15:39 +0300 Date: Mon, 5 Apr 2021 16:15:39 +0000 To: Serge Petrenko Message-ID: <20210405161539.jmsyjasmy7ykilnz@tarantool.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: NeoMutt/20170113 (1.7.2) X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9ED7173E37F4E32947A0146560F8BA709498CFB6209D8582A182A05F538085040893336C2CA263DB41E6D4DAE9A530ED370C7B40740B6E7CE0EF8C9373300D74C X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE78FB0D5613E12B2E0EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637FBDDB35DE4C816078638F802B75D45FF914D58D5BE9E6BC131B5C99E7648C95C16EE06F5A270FE6ABB6962D9D8E90321FFF6084C3D82701AA471835C12D1D9774AD6D5ED66289B5278DA827A17800CE74601F13E4625331C9FA2833FD35BB23D2EF20D2F80756B5F868A13BD56FB6657A471835C12D1D977725E5C173C3A84C31E02C13459908652117882F4460429728AD0CFFFB425014E868A13BD56FB6657D81D268191BDAD3DC09775C1D3CA48CF6DF1F3F6B22E83C7BA3038C0950A5D36C8A9BA7A39EFB766EC990983EF5C0329BA3038C0950A5D36D5E8D9A59859A8B67C2979BA483085F376E601842F6C81A1F004C906525384307823802FF610243DF43C7A68FF6260569E8FC8737B5C2249EC8D19AE6D49635B68655334FD4449CB9ECD01F8117BC8BEAAAE862A0553A39223F8577A6DFFEA7CDDB9BF3B882869D543847C11F186F3C59DAA53EE0834AAEE X-C1DE0DAB: 0D63561A33F958A5312750FBCFD95D3764B56C1D17E7A2D55AC8269A409946BAD59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA7502E6951B79FF9A3F410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34F6110710A6CC527F2AE509796A358BD697580021F89131AE06366915A97D4254905F5DC1047F26571D7E09C32AA3244C2352824697929D841CD2A1A589C681AAF26BFA4C8A6946B8927AC6DF5659F194 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojM00ve/f+0olbSST0a2+RAg== X-Mailru-Sender: 05EB39F83D09414F9B5D7F52D7CDFDD2C5FBA89D460A45E10E746D4841D7EB23A043B3526AE48F2FCA16B95394F0DD5CE99530A0C0F27B5268329DCED823713783C0E760C018FF54112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok 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: Kirill Yukhin via Tarantool-patches Reply-To: Kirill Yukhin Cc: tarantool-patches@dev.tarantool.org, v.shpilevoy@tarantool.org Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" Hello, On 24 мар 15:24, Serge Petrenko via Tarantool-patches 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. > > Changes in v2: > - Make applier transactional on final join stage > - Remove guards for rollback during final join on master side > - Some refactoring in preparation to #5874 > > https://github.com/tarantool/tarantool/issues/5566 > https://github.com/tarantool/tarantool/tree/sp/gh-5566-final-join-synchro-v2 I've checked your patchset into 2.6, 2.7 and master. -- Regards, Kirill Yukhin