From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp38.i.mail.ru (smtp38.i.mail.ru [94.100.177.98]) (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 BE009469719 for ; Thu, 19 Mar 2020 12:17:07 +0300 (MSK) Date: Thu, 19 Mar 2020 12:17:06 +0300 From: Sergey Ostanevich Message-ID: <20200319091706.GH188@tarantool.org> References: <680467d22cb2864fb4c2d18ac33c4cccb272ebbb.1584558067.git.sergepetrenko@tarantool.org> <20200318200846.GB17681@atlas> <09ba01d5fdc5$f5e1fab0$e1a5f010$@tarantool.org> <20200319084144.GD5707@atlas> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20200319084144.GD5707@atlas> Subject: Re: [Tarantool-patches] [PATCH v2 1/5] box: introduce matrix clock List-Id: Tarantool development patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: 'Konstantin Osipov' , Timur Safin , 'Serge Petrenko' , v.shpilevoy@tarantool.org, tarantool-patches@dev.tarantool.org, Kirill Yukhin On 19 мар 11:41, 'Konstantin Osipov' wrote: > * Timur Safin [20/03/19 11:11]: > > : > A matrix clock which allows to maintain a set of vclocks and > > : > their components order. The main target is to be able to > > : > build a vclock which contains lsns each one is less or equal > > : > that n corresponding lsn from a matrix clock. > > : > > > : > The purpose of the matrix clock is to evaluate a vclock > > : > which is already processed by wal consumers like relays > > : > or to obtain a majority vclock to commit journal entries > > : > in case of synchronous replication. > > : > > > : > @sergepetrenko: refactoring & rewrite comments to doxygen style. > > : > > : I think we have discussed that matrix clock should not be pushed. > > : > > : It's a huge over complication. > > : > > : Why are you committing this? > > : > > : -- > > : Konstantin Osipov, Moscow, Russia > > > > That's the very good question. There is smell of some miscommunication > > between parties involved, hopefully we will resolve it soon. > > Last time we gathered to discuss sync replications, the consensus was > > That we do not want matrix clock as they overcomplicate conflict resolution process (so, at least, it was not looking like prerequisite to sync > > replications mechanism). > > George should clarify, but AFAIU his original design introduced > matrix clock to GC and to sync replication. These series only > touch the GC. George reported there was an issue with the current > GC tracker, basically it becomes non-function when sync > replication is in place -I don't know what the issue is. > > I'd love to discuss the problem first, and then see alternatives. > > The thing is, I'd like our vclock to become sparse one day and be > able to contain thousands of entries. We could use a dynamic data structure > which changes the underlying structure depending on the actual > member count. > To get there and stay efficient, we need to make sure we never > copy entire vclock by value, and instead begin passing objects > representing a "vclock diff" around. Maintaining a sparse matrix would be > hell in this case. > > > Serge, if I miss some important detains here, I'd love to get corrected > > here. I do feel there are some other reasons needed, which I probably > > simply not aware of. The discussion was with MRG users of Tarantool and their point was: they are facing problems with consistent state restore and root cause analysis in case of Tarantool failure. It's a huge burden for them to debug and fix their applications even with vector clock, while introduction of matrix one will make this task impossible. > > -- > Konstantin Osipov, Moscow, Russia