[Tarantool-patches] [PATCH v2 1/5] box: introduce matrix clock

[Sergey Ostanevich]

On 19 мар 11:41, 'Konstantin Osipov' wrote:
> * Timur Safin <tsafin at tarantool.org> [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