This feature adds the support for rr in mtr. These 2 options are added
--rr run the mysqld in rr record mode
--rr_option= run the rr with custom record option, for multiple options use --rr_option= for each option.
For example
./mtr main.view --rr_option=-h --rr_option=-u --rr_option=-c=23
--boot-rr run the mysqld performing bootstrap in rr record mode
Recording are stored in mysql-test/var/rr folder.
To run recording please run
rr replay var/rr/mysql-X
Limitations
Restart will create a new recording.
Repeat will work on same recording , So might be harder to debug.
If test create the multiple instance of mariadb all will be stored in var/rr
MDEV-21469: Implement crash-safe binary logging of the user XA
Make XA PREPARE, XA COMMIT and XA ROLLBACK statements
crash-safe when --log-bin is specified.
At execution of XA PREPARE, XA COMMIT and XA ROLLBACK their replication
events are made written into the binary log prior to execution
of the commands in storage engines.
In case the server crashes, after writing to binary log but before all
involved engines have processed the command, the following recovery
will execute the command's replication events to equalize the states
of involved engines with that of binlog.
That applies to all XA PREPARE *group* and XA COMMIT or ROLLBACK.
On the implementation level the recovery time binary log parsing
is augmented to pay attention to
the user XA xids to identify the XA transactions' state:s in binary log, and
eventually match them against their states in engines, see
MYSQL_BIN_LOG::recover_explicit_xa_prepare().
In discrepancy cases the outdated state in the engines is corrected with
resubmitting the transaction prepare group of events, or completion
ones. The multi-engine partly prepared XA PREPARE case
the XA is rolled back first.
The fact of multiple-engine involved is registered into
Gtid_log_event::flags2 as one bit. The boolean value is
sufficient and precise to deal with two engines in XA transaction.
With more than 2 recoverable engines the flag method is still correct though
may be pessimistic, as it treats all recoverable engines as XA
participants. So when the number of such Engines exceeds the number
of prepared engines of the XA that XA is treated
as partially completed, with all that ensued.
As an optimization no new bit is allocated in flags2, instead a
pre-existing ones (of MDEV-742) are reused, observing that
A. XA "COMPLETE" does not require multi-engine hint for its recovery and that
B. the MDEV-742 XA-completion bit is not anyhow used by
XA-PREPARE and its GTID log event.
Notice the multi-engine flagging is superceded by MDEV-21117 extension
in Gtid log event so this part should be taken from there.
MDEV-21469 Pre-commit: make sure binlog hton is listed in the head
of the user XA participants list.
This patch makes sure that at handling of the user XA
the binlog hton heads the list of the transaction branches
which was not the case for the multi-engine XA.
Also a recovered XA's completion (XA COMMIT or ROLLBACK through a
"foreign" connection) is made to invoke first binlog hton's
"complete"_by_xid before the general hton loop (and naturally skip the
binlog hton action in the loop).
