maria:bb-10.5-MDEV-21469-2022

Last commit made on 2022-12-08
Get this branch:
git clone -b bb-10.5-MDEV-21469-2022 https://git.launchpad.net/maria

Branch merges

Branch information

Name:
bb-10.5-MDEV-21469-2022
Repository:
lp:maria

Recent commits

b2e7986... by Brandon Nesterenko

MDEV-21469 Test and error message fixups

181780f... by Andrei <email address hidden>

Some cleanup.

d5b1323... by Andrei <email address hidden>

fixed assert associated with MDEV-25616 r/o xa binlogging

64b7de4... by Sujatha Sivakumar

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.

e484786... by Andrei Elkin <email address hidden>

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).

The work is a prerequisite for MDEV-21469.

dd20a43... by THIRUNARAYANAN BALATHANDAYUTHAPANI

MDEV-30114 Incremental prepare fails when innodb_undo_tablespaces > 0

- Mariabackup fails to open the undo tablespaces while applying delta
files to the corresponding data file. Mariabackup opens the
undo tablespaces first time in srv_undo_tablespaces_init() and does
tries to open the undo tablespaces in xtrabackup_apply_deltas() with
conflicting mode and leads to the failure.

- Mariabackup should close the undo tablespaces before applying
the incremental delta files.

7487c31... by Marko Mäkelä

Merge 10.4 into 10.5

This fixes up 4eb8e51c269eb9447d3765a6e4deba0dc68dfa37
which missed a second parent.

4eb8e51... by Jan Lindström

Merge 10.4 into 10.5

1181564... by Marko Mäkelä

MDEV-24412: Disable the test on ./mtr --embedded

846112c... by Marko Mäkelä

MDEV-24412: Create a separate test

Some builders in our CI, most notably FreeBSD and IBM AIX, do not support
sparse files. Also, Microsoft Windows requires special means for creating
sparse files. Since these platforms do not run ./mtr --big-test, we will
for now simply move the test to a separate file that requires that option.