MySQL Bugs: #75205: Master should write a LOST_EVENTS entry on xa commit after recovery.

Bug #75205	Master should write a LOST_EVENTS entry on xa commit after recovery.
Submitted:	13 Dec 2014 17:26	Modified:	27 Jan 2015 19:59
Reporter:	Daniël van Eeden (OCA)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: XA transactions	Severity:	S2 (Serious)
Version:	5.7.5-m15	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	Backup, binlog, replication, xa

Description:
When I have an prepared XA transaction, and then crash mysqld and then commit that transaction it is not written to the binlog.

This is documented on http://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html

I would like the server to write an LOST_EVENTS event to the binlog in that case to detect that this has happened.

How to repeat:
See description.

Suggested fix:
A. Why is it not possible to write the event to the binlog?
I assume it's like this:
1. transaction gets prepared (details known in InnoDB and Server)
2. crash
3. crash recovery (details known in InnoDB only)
4. server gets the list of xa transactions from InnoDB with xa recover, but no other details.
5. On commit there are no details about what should be written to the binlog..

Possible solutions:
- Try to get enough details from InnoDB to write a RBR event at least. (Don't know if InnoDB knows the statement)
- Write the binlog details to a mysql.xa_prepared_trx table (transactional) during xa prepare.

B. When the server detects that there are lost events it should write a LOST_EVENTS event to the binlog.

Maybe binlog_error_action / binlog_impossible_mode can be used, but I don't think that's an good idea as that is mainly about storage subsystem issues.

http://dev.mysql.com/doc/refman/5.7/en/xa-restrictions.html
"An implication is that XA cannot be used safely together with replication."

That would also imply that it's not possible to use point in time recovery based on binlogs.

Considering the common use cases for XA, not being able to fully recover all data is something I consider as a serious issue. (so Severity=S2 (Serious))

Some actions which can be done:
 - Make binlogs and XA work (e.g. remove the documented restriction)
 - Make sure replication and binlog restore don't silently ignore this (e.g. fix this bug)
 - Update the documentation to let people know XA and point-in-time recovery is not safe.
 - Get MySQL Enterprise Backup to emit a warning if XA is in active use

As this also happens with TokuDB in 5.5.40-tokudb-7.5.3 this looks like an server issue.

Thank you for the reasonable feature request.