maria-developers team mailing list archive

[Kristian Nielsen <knielsen@xxxxxxxxxxxxxxx>]

Jonas Oreland <jonaso@xxxxxxxxxx> writes:

> <quick thoughts on implementation>
> for row-based replication this seems quite "easy".
>
> for statement-based replication i image that you would have to add hooks
> into the "real" code
> after parsing has been performed, but before the actual execution is
> started (and yes, i know that there is sometimes a blurry line here)
> </thoughts>

A different approach could be to do this on the master.
When a transaction is binlogged, we have easy access to most/all of this
information. And there is room in the GTID event at the start of every binlog
event group to save this information for the slave. Then the slave has the
information immediately when it starts scheduling events for parallel
execution. So this does not sound too hard. Though the amount of information
that can be provided is then somewhat limited for space and other reasons, of
course.

> i think it will be well invested time to add infrastructure to be able to
> restrict when parallel applying will be performed.

Yes, I think it is an interesting idea.

For example, we could only run transactions in parallel that are safe to
rollback (marked by a bit in the GTID). Then in case of a deadlock, we know
it's safe to roll back all of them and try again.

This would only need to be done within each replication domain, which is where
we need to enforce commit order. It would still be possible to eg. run a
long-running DDL in parallel in a separate domain, with the user/DBA taking
care of ensuring that no conflicts will occur.

I'll need to think more of it, but it's an interesting idea. Thanks for the
suggestion!

 - Kristian.