From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com [209.85.167.66]) (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 4BB3B469710 for ; Wed, 6 May 2020 22:10:46 +0300 (MSK) Received: by mail-lf1-f66.google.com with SMTP id 188so2291824lfa.10 for ; Wed, 06 May 2020 12:10:46 -0700 (PDT) Date: Wed, 6 May 2020 22:10:44 +0300 From: Konstantin Osipov Message-ID: <20200506191044.GB2749@atlas> References: <20200403210836.GB18283@tarantool.org> <20200430145033.GF112@tarantool.org> <20200506185559.GA2749@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200506185559.GA2749@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: Sergey Ostanevich , Vladislav Shpilevoy , tarantool-patches@dev.tarantool.org * 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. -- Konstantin Osipov, Moscow, Russia https://scylladb.com