Jonas Oreland <jonaso@google.com> 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.