Hi Kristian,
First of all thanks for the great on-list explanations of your parallel replication features. It looks as if you are making good progress on a very hard problem.
Second, this is slightly off-topic but can you expand somewhat on the semantics of group-committed transactions in the binlog? Here are a few questions:
a.) It seems logical that transactions within a group commit should appear together in the binlog and should be serialized before and after other transactions in the binlog. Is there *any* way this ordering could be violated, for example to mix in a non-grouped transaction?
b.) Is there any ordering of the transactions within the group commit in the binlog for example sorted based on the resources each uses? Or is it more or less random based on time locks are acquired, etc.?
c.) How do you handle commit timestamps on group-committed transactions? Are they identical? In past MySQL releases I have found instances where timestamps can walk backwards across succeeding transactions. Such anomalies can be very troublesome for downstream consumers like data warehouses that want to create materialized, point-in-time views or partition data based on time of commit. (Ask me how I know.)
Any clarifications you can offer would be most welcome.
Cheers, Robert