Problem is that mysql.galera_slave_pos table is replicated,
thus it should be InnoDB to allow rolling back in case
of replay.
Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
The test was changing wsrep_on option in node_3, which is native
MariaDB server (i.e. not a cluster node). Native NariaDB server
should not manipulate wsrep replication state, this problem is fixed.
galera.galera_slave_replay test phase 2 will cause certification failure
for async slave SQL handler thread. This certification failure is now
monitored and required to happen in the test.
The test phase 2, generates scenario, where async slave SQL handler faces
certification failure and galera slave applier is paused when this happens.
This makes the test vulnerable for anomaly described in MDEV-22632.
Therefore the fix in this commit depends on MDEV-22632, and should be merged
after the fix for MDEV-22632.
If async replication slave thread conflicts with cluster replication,
then the async slave transaction should be BF aborted, and depending on the
state of async slave transaction execution, potentially also replayed.
There were problems in such BF abort implementation and the replaying was not
started.
This pull request contains fixes which make sure that if async slave thread is
marked to abort and replay, it will complete carry out the rollback and
release all locks and resources before starting the replaying. After replaying,
async slave transactions is treated as successful, so the slave thread will
continue as usual, handling next replication event.
There is also new mtr test: galera.galera_slave_replay, which stresses both a
certification failure for async slave thread and a successful BF abort
followed by replaying.
