From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-f195.google.com (mail-lj1-f195.google.com [209.85.208.195]) (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 E1973452566 for ; Thu, 14 Nov 2019 22:48:08 +0300 (MSK) Received: by mail-lj1-f195.google.com with SMTP id d5so8012351ljl.4 for ; Thu, 14 Nov 2019 11:48:08 -0800 (PST) Date: Thu, 14 Nov 2019 22:48:06 +0300 From: Konstantin Osipov Message-ID: <20191114194806.GA20289@atlas> References: <20191114125705.26760-1-maria.khaydich@tarantool.org> <9545327.LWTAaRDJnC@home.lan> <20191114173338.GC17735@atlas> <2359844.DWZl6MdUWF@home.lan> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2359844.DWZl6MdUWF@home.lan> Subject: Re: [Tarantool-patches] [PATCH] Trigger on vclock change List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Georgy Kirichenko Cc: tarantool-patches@dev.tarantool.org * Georgy Kirichenko [19/11/14 22:42]: > A replica state is described by 2 vclocks - written and committed ones. Right > now it is not an issue to report them both as an applier submits transaction > asynchronously. In addition to these two vclocks (yes, the both could be > transferred from the WAL thread) applier will report a reject vclock - the > vclock where applying breaks, and this could be done from TX. I do not like > the idea to split transmission between 2 threads. The write and reject vclocks > are used to evaluate majority whereas commit vclock instructs a whole cluster > that majority was already reached. The main point is that any replica member > could commit a transaction - this relaxes RAFT limitations and increases the > whole cluster durability (and it is simpler in design and implementation, > really). Also the new synchronous replication design has a lot of advantages > in comparison with RAFT but let us discuss it in another thread. If you > interested please ask for details as I have not enough time to write public > document right now. > Returning to the subject, I would like to conclude that wal on_commit and > on_write triggers are good source to initiate status transmission. And the > trigger implemented by Maria will be replaced by replica on_commit which > allows us not to change anything at higher levels. Congratulations, Georgy, maybe you even get a Turing award for inventing a new protocol. Wait... they don't give a Turing award for "protocols" which have no proof and yield inconsistent results, or do they? Meanwhile, if you have a design in mind, you could send an RFC. I will respond to the RFC. PS What a shame... -- Konstantin Osipov, Moscow, Russia