From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp61.i.mail.ru (smtp61.i.mail.ru [217.69.128.41]) (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 E4AB9469710 for ; Tue, 12 May 2020 19:03:25 +0300 (MSK) Date: Tue, 12 May 2020 19:03:25 +0300 From: Sergey Ostanevich Message-ID: <20200512160325.GL112@tarantool.org> References: <20200403210836.GB18283@tarantool.org> <20200430145033.GF112@tarantool.org> <20200506185559.GA2749@atlas> <20200506191044.GB2749@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200506191044.GB2749@atlas> Subject: Re: [Tarantool-patches] [RFC] Quorum-based synchronous replication List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Konstantin Osipov , Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org On 06 мая 22:10, Konstantin Osipov wrote: > * Konstantin Osipov [20/05/06 21:55]: > > A few more issues: > > > > - the spec assumes there is a full mesh. In any other > > topology electing a leader based on the longest wal can easily > > deadlock. Yet it provides no protection against non-full-mesh > > setups. Currently the server can't even detect that this is not > > a full-mesh setup, so can't check if the precondition for this > > to work correctly is met. > > Come to think of it, it's a special case of network partitioning. > A replica with the longest WAL can be reachable by the external > coordinator but partitioned away from the majority, so never able to > make progress. So the answer from this replica on it's appointment will be 'I have no quorum'. Hence, the orchentration should pick the next-length WAL. What's the problem? > > > -- > Konstantin Osipov, Moscow, Russia > https://scylladb.com