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 69CC46EC40; Wed, 2 Jun 2021 09:36:26 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 69CC46EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1622615786; bh=13LBDtFnJWBb15mBGz3U0k3pFeAYs89PusGih+9m7oo=; 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=avhI/xV1JM94mpWj2ECv+7ORjibl8uM2j+9tCQvmZZ8CkEKejXLpJoxCnB+M+kic5 m3kJxUtqrC71WChRJs76EAE+7BROuesbs726c4q91rlu/6rE60hon1Ymxh192sQ4iS R8cqo2a1hqQUPwTY6gahesA5+FN4okKT3Rzw+pSk= Received: from smtp37.i.mail.ru (smtp37.i.mail.ru [94.100.177.97]) (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 EE4B46EC40 for ; Wed, 2 Jun 2021 09:36:24 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org EE4B46EC40 Received: by smtp37.i.mail.ru with esmtpa (envelope-from ) id 1loKUK-000261-8P; Wed, 02 Jun 2021 09:36:24 +0300 To: Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org, gorcunov@gmail.com References: <6ed9245f407510ad3a149f62c960f89fa689909e.1622233728.git.v.shpilevoy@tarantool.org> <5b059031-b099-9fe4-8c4c-7b6ef780df73@tarantool.org> <2da9c4ac-a10c-9cbd-ec4b-ef35aecd0ea0@tarantool.org> Message-ID: Date: Wed, 2 Jun 2021 09:36:23 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 MIME-Version: 1.0 In-Reply-To: <2da9c4ac-a10c-9cbd-ec4b-ef35aecd0ea0@tarantool.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-7564579A: 78E4E2B564C1792B X-77F55803: 4F1203BC0FB41BD9D5B0DA836B685C5407454A95E60932C8E3171F0D0805CD56182A05F5380850402B24037B0754B84249C0391CD39A813EE71508C5F8CBC0A1B96B657911F727CA X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE7922E451CE6E839B1EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637CD1DFD3ABA64F6568638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D8F807B241E27CAA15A1D7C93D1C3BE192117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC974A882099E279BDA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F446042972877693876707352033AC447995A7AD18F04B652EEC242312D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE7B96B19DC40933219935A1E27F592749D8FC6C240DEA7642DBF02ECDB25306B2B78CF848AE20165D0A6AB1C7CE11FEE3A6C7FFFE744CA7FB6E0066C2D8992A16C4224003CC836476EA7A3FFF5B025636E2021AF6380DFAD1A18204E546F3947CB11811A4A51E3B096D1867E19FE1407959CC434672EE6371089D37D7C0E48F6C8AA50765F7900637BF1C901A33650803EFF80C71ABB335746BA297DBC24807EABDAD6C7F3747799A X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A2368A440D3B0F6089093C9A16E5BC824A2A04A2ABAA09D25379311020FFC8D4AD770A38206F2E2FCCB56CF104BCA6EDF9 X-C1DE0DAB: 0D63561A33F958A5F8715EE33C29CD965CD3E133926FA4DB909259C61588CE31D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75FBC5FED0552DA851410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34D1AE09A115117C96B0751753E1668FF49983AF60BDC4AEAA0DED4626CC947DCC23A9C5DB1D52A3111D7E09C32AA3244CB0242CCE33EDA807A37D762509F4F92251E887DA02A9F7BFFACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2bioj+mfSpkNmA2qsWKXgCDo5qQ== X-Mailru-Sender: 583F1D7ACE8F49BD9DF7A8DAE6E2B08ABBBC9E18DEF381FF234F054348329E419E65FFBFCB62FD31424AE0EB1F3D1D21E2978F233C3FAE6EE63DB1732555E4A8EE80603BA4A5B0BC112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH 1/1] replication: check rs uuid on subscribe process 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" 02.06.2021 00:34, Vladislav Shpilevoy пишет: > Hi! Thanks for the review! Thanks for the fixes! > >>> The UUID ignorance on subscribe decode was introduced here: >>> https://github.com/tarantool/tarantool/commit/7f8cbde3555084ad6c41f137aec4faba4648c705#diff-fc276b44b551b4eac3431c9433d4bc881790ddd7df76226d7579f80da7798f6e >>> >>> And I don't understand why. Maybe I miss something? The tests have >>> passed. Sergey, do you remember why was it needed really? >>> >>> Replicaset UUID mismatch definitely means the node can't connect. >>> It is not related to whether it is anonymous or not. Because it >>> has nothing to do with _cluster. >> Hi! Thanks for the patch! >> >> That change was meant to help anonymous replicas fetch data from >> multiple clusters. There was such an idea back then. >> It never got implemented though, and I doubt it will. > Wow, I am not sure how it is supposed to work at all. Starting from > the problem that in different RS you have conflicting replica_id, and > you won't be able to keep track of the changes properly. You simply can't > pack the same replica_id from 2 different replicasets into one replica_id > in your own journal. > > It does not matter if you are anon or not - the changes in the given > replicasets are generated by non-anon nodes and their replica IDs will > clash. I guess you could assign the same replica_id to all the changes coming from one cluster. Just assign lsns in the order of arrival, or something. Or you could maintain a vclock per  each cluster, assign the same replica_id to each change coming from this cluster, and assign vclock_sum as the change's lsn. > >> So the idea was that replica should check the replicaset UUID itself. >> It doesn't work now obviously. And looks like it hadn't worked before >> you introduced the ER_TOO_EARLY_SUBSCRIBE error. >> The test for checking uuid on replica side didn't catch this problem >> because the replica was already registered on master in it. >> >> Long story short, I'm ok with this change, but now you should remove >> unnecessary replicaset uuid checks from replica side (in applier_subscribe). > If it is not critical for you, I would leave as many checks as possible > on both sides. It has nothing to do with perf but protects from unexpected > situations like this one. Let me know if you want it deleted anyway. Ok, I'm not against it. >> And looks like replication/gh-3704-misc-replica-checks-cluster-id test is >> obsolete now. > Yes, looks like so. I deleted it on the branch. Sorry, one more nit. I failed to notice this earlier, but there's an obsolete comment in box_process_subscribe(). It goes like "Tarantool > 2.1.1 master doesn't check that replica has the same cluster uuid". LGTM, once you delete the comment. -- Serge Petrenko