e57e1c4...
by
Teemu Ollakka <email address hidden>
InnoDB wsrep applier lock wait timeout
This patch implements wsrep applier lock wait timeout
functionality.
As transactions which are executed by appliers have passed
certification in the cluster, they must be applied and committed
successfully. However, occasionally BF aborting local transactions
may not work perfectly due to race conditions or unforeseen
behavior of the lock manager, which may cause appliers to wait
locks indefinitely. Especially if the local transaction has
already reached commit stage, it will not yield via lock
wait timeout.
In order to resolve indefinite applier waits, a short applier
lock wait timeout is introduced. However instead of giving up
with lock wait, a background thread is used to retry BF abort
on behalf of the applier which is waiting for the lock.
A variable to control the applier lock wait timeout is
innodb_wsrep_applier_lock_wait_timeout with default
value of five seconds. If the value is zero, the background
BF aborting is disabled.
A separate timer wsrep_BF_watchdog_timer was added to achieve
one second resolution.
The value of innodb_wsrep_applier_lock_wait_timeout is set
to zero in Galera suite MTR test configuration to avoid
non-deterministic behavior.
10.4-MDEV-29684 Fixes for cluster wide write conflict resolving
The rather recent thd_need_ordering_with() function does not take high priority transactions' order in consideration.
Chaged this funtion to compare also transaction seqnos and favor earlier transaction.
10.4-MDEV-29684 Fixes for cluster wide write conflict resolving
If two high priority threads have lock conflict, we look at the order of these tranactions and honor the earlier transaction.
for_locking parameter in lock_rec_has_to_wait() has become obsolete and it is now removed from the code.
MDEV-29684 Fixes for cluster wide write conflict resolving
Cluster conflict victim's THD is marked with wsrep_aborter.
THD::wsrep_aorter holds the thread ID of the hight priority tread,
which is currently carrying out BF aborting for this victim.
However, the BF abort operation is not always successful,
and in such case the wsrep_aboter mark should be removed.
In the old code, this wsrep_aborter resetting did not happen,
and this could lead to a situation where the sticky wsrep_aborter
mark prevents any further attempt to BF abort this transaction.
This commit fixes this issue, and resets wsrep_aborter after unsuccesful BF abort attempt.
MDEV-30235 InnoDB crash on table-rebuilding DDL when the statistics tables are corrupted
commit_try_rebuild(): Only invoke trx_t::drop_table_statistics()
if both InnoDB statistics tables are accessible (and exclusively
locked by the current transaction). This avoids a crash due to
ut_a(sym_node->table != NULL) in pars_retrieve_table_def().
The crash was repeated on a partial copy of a MariaDB 10.3 data
directory that lacked the *.ibd files for the statistics tables.
