Re: [Tarantool-patches] [PATCH] Trigger on vclock change

[Konstantin Osipov <kostja.osipov@gmail.com>]

* Georgy Kirichenko <kirichenkoga@gmail.com> [19/11/14 17:11]:
> On Thursday, November 14, 2019 4:44:22 PM MSK Konstantin Osipov wrote:
> > * Maria <maria.khaydich@tarantool.org> [19/11/14 15:59]:
> > > This patch implements replication.on_vclock
> > > trigger that can be  useful for programming
> > > shard-systems with redundancy.
> > 
> > 3808 is about being able to wait for an lsn.
> > 
> > Using a trigger for *waiting* is called busy waiting, and is a cpu
> > hog, especially at a performance critical space like update of
> > replica vclock, which can happen a hundred times a second.
> > 
> > Why not implement a way to wait for an lsn instead?
> Please explain your proposal in a more detailed way.
> Do you wish to implement a hard-coded `handler` and each time when a replica 
> vclock is updated this handler will compare the updated vclock against members 
> of set of replica_id:lsn pairs organized in a list, tree or something else? 
> And if a compare matches to true then a corresponding handler will be called?

Yes, quite simply wait_lsn() could add the server_id, lsn that is
being waited for to a sorted list, and whenever we update
replicaset vclock for this lsn we also look at top of the list, if
it is not empty, and if the current lsn is greater than the top,
we could pop the value from the list and send a notification to
the waiter.

I also think it it's a pair of server_id, lsn, rather than entire
vclock - usually you know what you're waiting for, and it's only
one component of vclock, not all of them.

Going forward I think one is better off using synchronous
replication, not wait-lsn, since wait_lsn doesn't roll back the
transaction on failure.

Why did you decide to do this ticket at all?


> Anyway, we will need to have such trigger in order to make applier able to 
> report local replica wal and commited vclock in scope of synchronous 
> replication issue.

This has to happen in WAL thread, not in main thread, and has to
watch relay-from-memory vclock, not async-replication vclock. And
it also needs to roll back the transaction locally on failure,
i.e. write some sort of undo records to the WAL.

-- 
Konstantin Osipov, Moscow, Russia