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 920A46EC40; Mon, 27 Sep 2021 10:05:38 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 920A46EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1632726338; bh=bOoawTMwHXagKbxqXJe2i7U5s2bBPCQX6yIlGF3Adbg=; h=To:Cc:References:Date:In-Reply-To:Subject:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=fui8th42zx4XC/pMdedhl8CfyInmt3v19q+w1yRScLetKPZhUx0Az2CX/jD/1N+ch ieSNBojrMgKlgN1ULTo04MFviRLkXgXO4XuQ/shMv79aE4kHaHRK9dU/a9vdjhboX+ ISmD5lN/SkOK0TTcxh6ICoCaY2BniKX//IQ+YeAQ= Received: from smtp34.i.mail.ru (smtp34.i.mail.ru [94.100.177.94]) (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 2E4876EC40 for ; Mon, 27 Sep 2021 10:05:37 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 2E4876EC40 Received: by smtp34.i.mail.ru with esmtpa (envelope-from ) id 1mUkhk-000233-HC; Mon, 27 Sep 2021 10:05:36 +0300 To: Cyrill Gorcunov , tml Cc: Vladislav Shpilevoy References: <20210922130535.79479-1-gorcunov@gmail.com> <20210922130535.79479-4-gorcunov@gmail.com> Message-ID: Date: Mon, 27 Sep 2021 10:05:36 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <20210922130535.79479-4-gorcunov@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: ru X-4EC0790: 10 X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD96A58C36AA2E99649DFE41A06634A2C4EB30EB11CC09FFC21182A05F53808504074A13DAE810BD61F0E62950221E93DA1B244FC37BB8F6B867128B779B9196CB6 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7012137A818DEC7F7EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006376EC5B14D896A2D978638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8A582168C56D426315B19134D4C8DDE1E117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC974A882099E279BDA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18618001F51B5FD3F9D2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6CF00A2452BA722CE089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A582E1E35C2892CD3DD9B421B2B8701FD16634DF165573EFD8D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75BFC02AB3DF06BA5A410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34DA1FE609583D493CADA589C76C85C4C1DD844E4B9CEABA9C36E75DCF3647286C57F721A03E1AB5F81D7E09C32AA3244C567BEC47A6D2E1AA8B55D9D3D30D7F8B95A9E0DC41E9A4CFFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojnnOrOlyI/jPUixM+8N3zsA== X-Mailru-Sender: 3B9A0136629DC9125D61937A2360A446E4D00257354A59BCBD53DED14560C9141424BECBD1EB7201424AE0EB1F3D1D21E2978F233C3FAE6EE63DB1732555E4A8EE80603BA4A5B0BC112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH v17 3/5] qsync: track confirmed_lsn upon CONFIRM packet 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: Serge Petrenko via Tarantool-patches Reply-To: Serge Petrenko Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" 22.09.2021 16:05, Cyrill Gorcunov пишет: > While been investigating various cluster split-brain scenarios and > trying to gather valid incoming synchro request domains and ranges > we've discovered that limbo::confirmed_lsn updated not dense enough > to cover our needs. > > In particular this variable is always updated by a limbo owner upon > write of syncro entry (to a journal) while replica just reads such > record without confirmed_lsn update, so when the replica become a cluster > leader it sends a promote request back to the former leader where the > packet carries zero LSN instead of previous confirmed_lsn and validation > of such packet won't pass. > > Note the packet validation is not yet implemented in this patch so it > is rather a preparatory work for future. > > Part-of #6036 > > Signed-off-by: Cyrill Gorcunov > --- > src/box/txn_limbo.c | 14 ++++++++++++++ > 1 file changed, 14 insertions(+) > > diff --git a/src/box/txn_limbo.c b/src/box/txn_limbo.c > index eb9aa7780..959811309 100644 > --- a/src/box/txn_limbo.c > +++ b/src/box/txn_limbo.c > @@ -774,6 +774,20 @@ txn_limbo_process_run(struct txn_limbo *limbo, > switch (req->type) { > case IPROTO_RAFT_CONFIRM: > txn_limbo_read_confirm(limbo, lsn); > + /* > + * We have to adjust confirmed_lsn according > + * to LSN coming from the request. It is because > + * we will need to report it as old's limbo owner > + * LSN inside PROMOTE requests (if administrator > + * or election engine will make us so). > + * > + * We could update confirmed_lsn on every > + * txn_limbo_read_confirm call but this function > + * is usually called in a couple with > + * txn_limbo_write_confirm, thus to eliminate redundant > + * variables update we make so once but explicitly. > + */ > + limbo->confirmed_lsn = req->lsn; > break; > case IPROTO_RAFT_ROLLBACK: > txn_limbo_read_rollback(limbo, lsn); LGTM. -- Serge Petrenko