From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp33.i.mail.ru (smtp33.i.mail.ru [94.100.177.93]) (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 192BE452566 for ; Thu, 14 Nov 2019 23:01:55 +0300 (MSK) From: Georgy Kirichenko Date: Thu, 14 Nov 2019 23:01:54 +0300 Message-ID: <27617293.E4uLSYyink@home.lan> In-Reply-To: <20191114194806.GA20289@atlas> References: <20191114125705.26760-1-maria.khaydich@tarantool.org> <2359844.DWZl6MdUWF@home.lan> <20191114194806.GA20289@atlas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: Konstantin Osipov Cc: tarantool-patches@dev.tarantool.org On Thursday, November 14, 2019 10:48:06 PM MSK Konstantin Osipov wrote: > * 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? You do not even know details of the protocol but make such suggestion, so I could only repeat your last statement: "what a shame", seriously. Please, remember all my attempts to discuss it with you or, for instance, our one-per-2-week meetings which all (except the first one) were skipped by you. > > Meanwhile, if you have a design in mind, you could send an RFC. I > will respond to the RFC. Anybody could see the design document after this protocol research will be done. Yes, the research requires to be implemented first. > > PS What a shame...