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 2F7856EC55; Mon, 12 Jul 2021 11:05:00 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 2F7856EC55 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1626077100; bh=hMA/pWbNMUaHznUWziBYZmlAl/ud51izUU0fk/suPwM=; h=To:References:Date:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=HZsBgLMvk03ilo6UUZ34Pb+tOwOheZXoratRJ2s9fIT4BxOvKaUg+cbrlSR8EfFuZ C+9Kz0CBWDg0iJ3i5sJ+rL3cSmK+VDHmvW1oyzLJzvaU7ufjTAxmNPLq5C+quEHDZR sDq20Oe0LFdaPOMQeZlKfRSon2F2rBp5fdh5+igk= Received: from smtpng3.i.mail.ru (smtpng3.i.mail.ru [94.100.177.149]) (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 C02096EC55 for ; Mon, 12 Jul 2021 11:04:58 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org C02096EC55 Received: by smtpng3.m.smailru.net with esmtpa (envelope-from ) id 1m2qvy-0003K9-0F; Mon, 12 Jul 2021 11:04:58 +0300 To: Serge Petrenko , Cyrill Gorcunov , tml References: <20210710222803.253251-1-gorcunov@gmail.com> <187d1ae2-99cb-50d4-d5b4-18aa6c5f5546@tarantool.org> Message-ID: <36639f07-5c56-5c94-d563-0862135d0ea9@tarantool.org> Date: Mon, 12 Jul 2021 10:04:56 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <187d1ae2-99cb-50d4-d5b4-18aa6c5f5546@tarantool.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD954DFF1DC42D673FB2EBB2C4D2123922B4672D8F1E18DEFDF182A05F53808504086CF390DBFBD904030DD2FCC106DD18228B7DAEFD59688545C9B2B828BBB0C02 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE77E216A0E97507353EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F79006379108F895B68B2FFD8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D823D344F4E89E13884BEB919E9331C15A117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC081CF0AE924DC023A471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F4460429728776938767073520B28585415E75ADA9E5D25F19253116ADD2E47CDBA5A96583BA9C0B312567BB231DD303D21008E29813377AFFFEAFD269A417C69337E82CC2E827F84554CEF50127C277FBC8AE2E8BA83251EDC214901ED5E8D9A59859A8B6A45692FFBBD75A6A089D37D7C0E48F6C5571747095F342E88FB05168BE4CE3AF X-C1DE0DAB: 0D63561A33F958A5E0838B9E1EDE197A22015A098B05B875BEC35B25CA09525ED59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA753753CEE10E4ED4A7410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D3433E9BC74ABA5769F52B7E7BCC00AAAB242E3CB796A0D83C511C033FB516BDB05AAF2202E5DDCEA241D7E09C32AA3244C0B1B38ECBB9F9E0C4BC3B2123B4C3D4135DA7DC5AF9B58C0FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj/3sbGI30Xhfz3fxqqVZvEQ== X-Mailru-Sender: 689FA8AB762F7393C37E3C1AEC41BA5DD6E66EA1427C8223822495EBF483148F3841015FED1DE5223CC9A89AB576DD93FB559BB5D741EB963CF37A108A312F5C27E8A8C3839CE0E267EA787935ED9F1B X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH] limbo: introduce request processing hooks 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: Vladislav Shpilevoy via Tarantool-patches Reply-To: Vladislav Shpilevoy Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" On 12.07.2021 10:01, Serge Petrenko via Tarantool-patches wrote: > > > 11.07.2021 17:00, Vladislav Shpilevoy пишет: >> Hi! Thanks for the patch! >> >> On 11.07.2021 00:28, Cyrill Gorcunov wrote: >>> Guys, this is an early rfc since I would like to discuss the >>> design first before going further. Currently we don't interrupt >>> incoming syncro requests which doesn't allow us to detect cluster >>> split-brain situation, as we were discussing verbally there are >>> a number of sign to detect it and we need to stop receiving data >>> from obsolete nodes. >>> >>> The main problem though is that such filtering of incoming packets >>> should happen at the moment where we still can do a step back and >>> inform the peer that data has been declined, but currently our >>> applier code process syncro requests inside WAL trigger, ie when >>> data is already applied or rolling back. >>> >>> Thus we need to separate "filer" and "apply" stages of processing. >>> What is more interesting is that we filter incomings via in memory >>> vclock and update them immediately. Thus the following situation >>> is possible -- a promote request comes in, we remember it inside >>> promote_term_map but then write to WAL fails and we never revert >>> the promote_term_map variable, thus other peer won't be able to >>> resend us this promote request because now we think that we've >>> alreday applied the promote. >> Well, I still don't understand what the issue is. We discussed it >> privately already. You simply should not apply anything until WAL >> write is done. And it is not happening now on the master. The >> terms vclock is updated only **after** WAL write. >> >> Why do you need all these new vclocks if you should not apply >> anything before WAL write in the first place? > > If I understand correctly, the issue is that if we filter (and check for > the split brain) after the WAL write, we will end up with a conflicting > PROMOTE in our WAL. Cyrill is trying to avoid this, that's why > he's separating the filter stage. This way the error will reach > the remote peer before any WAL write, and the WAL write won't happen. > > And if we filter before the WAL write, we need the second vclock, which > Cyrill has introduced. Why do you need a second vclock? Why can't you just filter by the existing vclock and update it after WAL write like now?