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 123E56EC40; Thu, 3 Jun 2021 10:18:05 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 123E56EC40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1622704685; bh=dS/psIKkLhwDIx9cuMSrPcBbRXF9oJCjCJjcXBqhjwY=; 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=nqGsDB/9p2+DwvTvoSWJOFiSFjhxqiS7ZIEqomNn7gKqZIJm0JknGdph3qU7oZLQe H6l1hASlBSrX39nebCmCJHe/DYeqFOF5Jk44zxmxkSAoILeteqSnA393S1+3MmvQdZ tpjsugUJ1R2VBZ3TNyp06S9uitEq5GTpSKQBqtvo= Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93]) (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 3EEAF6EC40 for ; Thu, 3 Jun 2021 10:18:03 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 3EEAF6EC40 Received: by smtp33.i.mail.ru with esmtpa (envelope-from ) id 1lohcA-0002NA-GA; Thu, 03 Jun 2021 10:18:02 +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> <5b62582e-20f1-21a3-76d8-993318aadedd@tarantool.org> Message-ID: <9ef39621-871e-c7d8-1f9a-96668bf58853@tarantool.org> Date: Thu, 3 Jun 2021 10:18:02 +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: <5b62582e-20f1-21a3-76d8-993318aadedd@tarantool.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-7564579A: 646B95376F6C166E X-77F55803: 4F1203BC0FB41BD9D5B0DA836B685C54907A7AE9C1BA82BC67C1327DFB87C6A6182A05F538085040E7F21801C2C2FD929A3C2DB684FEA6B81F787BD73F14606252ED3EFDA5C4F3E7 X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE705B093C0FC4B30B9EA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637A005C90FB6EB35FF8638F802B75D45FF36EB9D2243A4F8B5A6FCA7DBDB1FC311F39EFFDF887939037866D6147AF826D83173CD2D732C55916448CC14B3442D6B117882F4460429724CE54428C33FAD305F5C1EE8F4F765FC3A703B70628EAD7BA471835C12D1D9774AD6D5ED66289B52BA9C0B312567BB23117882F44604297287769387670735201E561CDFBCA1751F2CC0D3CB04F14752D2E47CDBA5A96583BA9C0B312567BB2376E601842F6C81A19E625A9149C048EE599709FD55CB46A6C5236E9430F51F07D8FC6C240DEA7642DBF02ECDB25306B2B78CF848AE20165D0A6AB1C7CE11FEE365B78C30F681404D2D242C3BD2E3F4C6C4224003CC836476EA7A3FFF5B025636E2021AF6380DFAD1A18204E546F3947CB11811A4A51E3B096D1867E19FE1407959CC434672EE6371089D37D7C0E48F6C8AA50765F7900637BF1C901A33650803EFF80C71ABB335746BA297DBC24807EABDAD6C7F3747799A X-B7AD71C0: AC4F5C86D027EB782CDD5689AFBDA7A24209795067102C07E8F7B195E1C978316F48C8EFC09980778955918E15BC64BA X-C1DE0DAB: 0D63561A33F958A54FD0F04CED49F0C5B5F852070286A8918A74C3587A24F1D9D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75FBC5FED0552DA851410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D349C39CCCDAABCB54B934A62D9CE5D4AD9ED93446AE577E8AC559C92237C147312C2BC35D62AA137AF1D7E09C32AA3244CEC9770EB7AB3A39FBAA0B15DDA0EF504A90944CA99CF22E3FACE5A9C96DEB163 X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojNbQUdF9mq4GNknY3zq7Vhg== X-Mailru-Sender: 583F1D7ACE8F49BD9DF7A8DAE6E2B08AA3FCAF0E140EBE338CFD4D7873C0CC67ECAE30EF5C4AD7B5424AE0EB1F3D1D21E2978F233C3FAE6EE63DB1732555E4A8EE80603BA4A5B0BC112434F685709FCF0DA7A0AF5A3A8387 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 23:16, Vladislav Shpilevoy пишет: > Hi! Good job on the review! > >>>>> 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. > How will you resubscribe then to get the changes from one RS starting from > a certain vclock? The same for the idea below. > > When you resubscribe, you need to tell the other RS starting from which > vclock it should send data. If you changed the received replica IDs, then > you don't have the needed information persisted anywhere. > > Absence of a resubscribe means a rejoin on each restart and disconnect, > which makes it hardly usable. Maybe save received vclocks in some local space? It would have [cluster_uuid ; vclock ] pairs. Then you could recover all the data first, and know which vclock to send in resubscribe to every cluster representative. > >> 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. > Thanks for noticing. I didn't delete it, but applied the diff below, > pushed to master, 2.8, 2.7. > > ==================== > @@ -2786,11 +2786,13 @@ box_process_subscribe(struct ev_io *io, struct xrow_header *header) > * the replica how many rows we have in stock for it, > * and identify ourselves with our own replica id. > * > - * Tarantool > 2.1.1 master doesn't check that replica > - * has the same cluster id. Instead it sends its cluster > - * id to replica, and replica checks that its cluster id > - * matches master's one. Older versions will just ignore > - * the additional field. > + * Master not only checks the replica has the same replicaset UUID, but > + * also sends the UUID to the replica so both Tarantools could perform > + * any checks they want depending on their version and supported > + * features. > + * > + * Older versions not supporting replicaset UUID in the response will > + * just ignore the additional field (these are < 2.1.1). > */ > struct xrow_header row; > xrow_encode_subscribe_response_xc(&row, &REPLICASET_UUID, &vclock); -- Serge Petrenko