From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f67.google.com (mail-lf1-f67.google.com [209.85.167.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by dev.tarantool.org (Postfix) with ESMTPS id 062C6469719 for ; Sun, 23 Feb 2020 11:16:16 +0300 (MSK) Received: by mail-lf1-f67.google.com with SMTP id 83so4582317lfh.9 for ; Sun, 23 Feb 2020 00:16:16 -0800 (PST) From: Georgy Kirichenko Date: Sun, 23 Feb 2020 11:16:12 +0300 Message-ID: <9655697.nUPlyArG6x@localhost> In-Reply-To: <20200222204930.GA23200@atlas> References: <2175956.ElGaqSPkdT@localhost> <20200222204930.GA23200@atlas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [Tarantool-patches] [PATCH v3 0/4] replication: fix applying of rows originating from local instance List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , Georgy Kirichenko , tarantool-patches@dev.tarantool.org, Serge Petrenko , v.shpilevoy@tarantool.org, alexander.turenko@tarantool.org Please do not think you are the only person who knows about byzantine faults. Also there is little relevance between byzantine faults and my suggestion to enforce replica-side checking. In any case filtering on the master side is the most worst thing we could do. In this case master has only one peer and have no chance to make a proper decision if replica is broken. And we have no chance to know about it (except assert which are excluded from release builds, or panic messages). For instance if master skipped some rows then there are no any tracks of the situation we could detect. In the opposite case a replica could connect to as many masters as they need to filter out all invalid data or hacked masters. At least we could enforce replication stream meta checking. Two major point I would like to mention are: 1. Replica could consistently follow all vclock members and apply all transactions without gaps (I already got rid of them, I hope you remember) 2. Replica could protect itself against concurrent local writes (one was made locally, the second one is returned from master) On Saturday, February 22, 2020 11:49:30 PM MSK Konstantin Osipov wrote: > * Georgy Kirichenko [20/02/22 23:22]: > > On Tuesday, February 18, 2020 8:37:03 PM MSK Serge Petrenko wrote: > > Hi! Thanks for the patch. > > I am pretty sure replica should be able to apply all replication stream > > transaction in a proper way without any reliance on a master correctness. > > Or signal an error if this is impossible. I am suggesting such logic > > because a replica has the complete information about it own at the > > moment. This includes local vclock, cfg, all existing appliers state and > > incoming streams. > It's an impossible and useless pursuit. > > Please read up on byzantine faults.