How to handle begin/commit events in the binlog

[shuhaowu]

Originally by @pushrax:

It seems that even with RBR the binlog gets BEGIN/COMMIT events (via XID_EVENT) that are required for perfect replication while servicing queries in a consistent way from the replica. These events allow the replica to commit changes to multiple tables atomically. This might matter for our use-case, if the data we are writing to the target is also being selected. My understanding is that this only affects consistency of queries in the replica/target during the copying. We already tolerate inconsistent data during copying, so maybe it's completely fine to ignore these events.

Comment by @shuhaowu:

Note that it is not a problem if the target that we are copying data to is not being queried by any other source other than ghostferry itself. This means that the vast majority of the use cases is safe (also includes Github's gh-ost).

[shuhaowu]

We should handle this issue by clearly document that if the target data is being selected while ghostferry is trying to copy the same data, it may cause data inconsistency issues on the target database.