The output of the XA RECOVER command to list transactions was
hard to read because of the representation of the data
column:
The good news is that 5.7 has transaction information in
performance_schema:

With Paul McCullagh’s PBXT storage engine getting integrated into
MariaDB 5.1,
it’s never been easier to it out. So we have, on a slave off one
of our own production systems which gets lots of inserts from our
Zabbix monitoring system.

That’s possibly an ideal usage profile, since PBXT is a log based
engine (simplistically stated, it indexes its transaction logs,
rather than rewriting data from log into index and indexing that)
so it should require less disk I/O than say InnoDB. And that
means it should be particularly suited to for instance logging,
which …

I have just released PBXT 1.0.09 RC3. Besides bug fixes (details
in the release notes), this version includes 2 Beta
features:

XA/2-Phase Commit support

Native online backup Driver

XA support has been around MySQL for quite a while, and we all
know of it usefulness, for example when sharding. So I was
surprised to find a bug in the XA recovery: Bug
#47134. Contrary to what is reported, the crash can also
occur when using XA with just the default engines installed, …

Recently a customer mentioned that they were seeing corruption
rarely when they copied InnoDB files using LVM to setup a new
slave. Investigating further, it turns out that replication would
start, but would then hit a lock wait timeout. This locking issue
occurred across restarts causing replication to always fail. They
would solve this by taking a new LVM snapshot and resetting it
up.

This is a classic case of an XA transaction in a prepared state persisting
across restarts and the LVM sometimes taking a snapshot at the
exact instant when this can occur. …

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.