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 18E006EC56; Fri, 19 Mar 2021 16:40:08 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 18E006EC56 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tarantool.org; s=dev; t=1616161208; bh=la3Bu+2IqgiXq8aM0bHrn9iWBOBBy+/k68zQtKk62V8=; h=To:References:Date:In-Reply-To:Subject:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=G6akFo1Xp5ARZ2CpHU++hyVrFC16rcLhwvoVteYBrWOvB1GAqTYFdf7wEmA32pEt7 RQCJoFWEK6bgZkEspLy8EPdbqL+U7ylFma6oktRRdbFFZTWMp56IkzxuKtF70nKxXS nyQMHcHAWVZiCDlDtueXFHINWQZQgwwzOquTI2OU= Received: from smtp39.i.mail.ru (smtp39.i.mail.ru [94.100.177.99]) (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 3121B6EC56 for ; Fri, 19 Mar 2021 16:40:07 +0300 (MSK) DKIM-Filter: OpenDKIM Filter v2.11.0 dev.tarantool.org 3121B6EC56 Received: by smtp39.i.mail.ru with esmtpa (envelope-from ) id 1lNFME-000767-3b; Fri, 19 Mar 2021 16:40:06 +0300 To: Vladislav Shpilevoy , Cyrill Gorcunov , tml References: <20210318184138.1077807-1-gorcunov@gmail.com> <20210318184138.1077807-2-gorcunov@gmail.com> Message-ID: Date: Fri, 19 Mar 2021 16:40:05 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.16; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-7564579A: EEAE043A70213CC8 X-77F55803: 4F1203BC0FB41BD95D6E7CC48CB1F5F179C48A9DDACBFB6F5347129BC2C9341C182A05F538085040D6DC5B25FB4DD54A0BC807BD635079E29ADD122A1258C10F9655E4A59050DAFA X-7FA49CB5: FF5795518A3D127A4AD6D5ED66289B5278DA827A17800CE77545ECFDF1E157EBEA1F7E6F0F101C67BD4B6F7A4D31EC0BCC500DACC3FED6E28638F802B75D45FF8AA50765F7900637D24CDE3D695BBBC6EA1F7E6F0F101C67CDEEF6D7F21E0D1D174C73DBBBFC7664C47072537531BC37519A4D60BA5BFB475EE60FDFDA56FA85389733CBF5DBD5E913377AFFFEAFD269176DF2183F8FC7C0DEC8C2C8BCD2534D8941B15DA834481FCF19DD082D7633A0EF3E4896CB9E6436389733CBF5DBD5E9D5E8D9A59859A8B6B737A621A50BC793CC7F00164DA146DA6F5DAA56C3B73B23C77107234E2CFBA567F23339F89546C55F5C1EE8F4F765FCF1DABE9C1E33628E75ECD9A6C639B01BBD4B6F7A4D31EC0BC0CAF46E325F83A522CA9DD8327EE493B89ED3C7A6281781BA6625F88748EAEFC4224003CC836476C0CAF46E325F83A50BF2EBBBDD9D6B0F05F538519369F3743B503F486389A921A5CC5B56E945C8DA X-C1DE0DAB: 0D63561A33F958A5B7AE4C01FCA80C066A93E5A7F0829ACB7755838F8A2A6D09D59269BC5F550898D99A6476B3ADF6B47008B74DF8BB9EF7333BD3B22AA88B938A852937E12ACA75F04B387B5D7535DE410CA545F18667F91A7EA1CDA0B5A7A0 X-C8649E89: 4E36BF7865823D7055A7F0CF078B5EC49A30900B95165D34505665BFD4C70705A9E777A44CEDE60F2BC176E6AB467D128E9FCCDFCC079C422623191DD593A4381D7E09C32AA3244CB463F991B4C0EAA5048380D2672A3F035A1673A01BA68E408D5DD81C2BAB7D1D X-D57D3AED: 3ZO7eAau8CL7WIMRKs4sN3D3tLDjz0dLbV79QFUyzQ2Ujvy7cMT6pYYqY16iZVKkSc3dCLJ7zSJH7+u4VD18S7Vl4ZUrpaVfd2+vE6kuoey4m4VkSEu530nj6fImhcD4MUrOEAnl0W826KZ9Q+tr5ycPtXkTV4k65bRjmOUUP8cvGozZ33TWg5HZplvhhXbhDGzqmQDTd6OAevLeAnq3Ra9uf7zvY2zzsIhlcp/Y7m53TZgf2aB4JOg4gkr2biojyKyJYJ15DtJuRwy/+0YKUQ== X-Mailru-Sender: 3B9A0136629DC9125D61937A2360A446153C0B9D9AE5C0C672CA136E43AC9E35AA8014D518566045424AE0EB1F3D1D21E2978F233C3FAE6EE63DB1732555E4A8EE80603BA4A5B0BC112434F685709FCF0DA7A0AF5A3A8387 X-Mras: Ok Subject: Re: [Tarantool-patches] [PATCH 1/2] gc/xlog: delay xlog cleanup until relays are subscribed 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 Cc: Mons Anderson Errors-To: tarantool-patches-bounces@dev.tarantool.org Sender: "Tarantool-patches" 19.03.2021 02:04, Vladislav Shpilevoy пишет: > Hi! Thanks for the patch! > > Generally looks fine except details. > > > AFAIU, we go for the timeout option for the only reason that > there might be non-fullmesh typologies, when a replica is in > _cluster, but does not have relays to other nodes. > > If we would know the topology, we could tell which nodes will > relay to who, and would be able to detect when a replica needs > to keep the logs, and when don't. Not even the entire topology. > Just the info from the adjacent nodes. From our own box.cfg.replication, > and from box.cfg.replication of these nodes. > > I still don't understand what was wrong with implementing some kind > of topology discovery for this 2-level topology tree. For instance > when applier on a replica is connected, the remote node sends us a > flag whether it is going to connect back. If the flag is false, we don't > keep the logs for that instance. IMO this topology discovery is not so easy to implement. And we've chosen this particular fix approach instead of 'persistent GC state' for its simplicity. How do you know whether a node is going to connect back? It has a corresponding entry in box.cfg.replication, sure, but how does it understand that this entry (URI) corresponds to the replica that has just connected? IIRC we had similar problems with inability to understand who's who judging solely by URI in some other fix. Don't remember which one exactly. Moreover, you may have something strange like a cascade topology. Say, there are 1 <- 2 <- 3 servers, with arrows showing replica-to-master connection. When 2 is up, how can it understand that it should wait for 3? -- Serge Petrenko