MDEV-31038: Parallel Replication Breaks if XA PREPARE Fails Updating Slave GTID State
If a replica failed to update the GTID slave state when committing
an XA PREPARE, the replica would retry the transaction and get an
out-of-order GTID error. This is because the commit phase of an XA
PREPARE is bifurcated. That is, first, the prepare is handled by the
relevant storage engines. Then second, the GTID slave state is
updated as a separate autocommit transaction. If the second phase
fails, and the transaction is retried, then the same transaction is
attempted to be committed again, resulting in a GTID out-of-order
error.
This patch fixes this error by immediately stopping the slave and
reporting the appropriate error. That is, there was logic to bypass
the error when updating the GTID slave state table if the underlying
error is allowed for retry on a parallel slave. This patch adds a
parameter to disallow the error bypass, thereby forcing the error
state to still happen.
Reviewed By
============
Andrei Elkin <email address hidden>
MDEV-31185 rw_trx_hash_t::find() unpins pins too early
rw_trx_hash_t::find() acquires element->mutex, then unpins pins, used for
lf_hash element search. After that the "element" can be deallocated and
reused by some other thread.
If we take a look rw_trx_hash_t::insert()->lf_hash_insert()->lf_alloc_new()
calls, we will not find any element->mutex acquisition, as it was not
initialized yet before it's allocation. rw_trx_hash_t::insert() can reuse
the chunk, unpinned in rw_trx_hash_t::find().
The scenario is the following:
1. Thread 1 have just executed lf_hash_search() in
rw_trx_hash_t::find(), but have not acquired element->mutex yet.
2. Thread 2 have removed the element from hash table with
rw_trx_hash_t::erase() call.
3. Thread 1 acquired element->mutex and unpinned pin 2 pin with
lf_hash_search_unpin(pins) call.
4. Some thread purged memory of the element.
5. Thread 3 reused the memory for the element, filled element->id,
element->trx.
6. Thread 1 crashes with failed "DBUG_ASSERT(trx_id == trx->id)"
assertion.
Note that trx_t objects are also reused, see the code around trx_pools
for details.
The fix is to invoke "lf_hash_search_unpin(pins);" after element->trx is
stored in local variable in rw_trx_hash_t::find().
Generate core dump file conditionally without server crashing
Requirements:
1. gdb(gcore) installed. Launch gcore to be sure it's installed.
2. On Debian-based platforms process attaching requires superuser
privileges, to solve it, run under su:
echo 0 > /proc/sys/kernel/yama/ptrace_scope
The core dump is generated under the following conditions.
1. Insert intention lock on gtid_slave_pos record was requested by slave
thread and ended up with timeout or deadlock.
2. If the highest bit on trx->skip_lock_inheritance_and_n_ref is set, then
lock_release_on_prepare() was invoked for that transaction. Generate
coredump if lock_release_on_prepare() was invoked for some transaction and
lock_res_set_nth_bit() was later invoked for that transaction for gap X
lock.
3. If there was lock wait timeout and the waiting transaction is in
prepared state and executed by slave thread.
No more then 10 core files per each condition must be generated. All the
files will be placed in data directory with core.{cond}.{n}.{pid} file
name pattern.
This commit is for debug purpose only, remove it on MDEV-30165 merging.
MDEV-30165 X-lock on supremum for preapared transaction for RR
trx_t::set_skip_lock_inheritance() must be invoked at the very beginning
of lock_release_on_prepare(). Currently trx_t::set_skip_lock_inheritance()
is invoked at the end of lock_release_on_prepare() when lock_sys and trx
are released, and there can be a case when locks on prepare are released,
but "not inherit gap locks" bit has not yet been set, and page split
inherits lock to supremum.
MDEV-30165 X-lock on supremum for preapared transaction for RR
Create gap locks for supremum and release them on transaction preparing.
Change innodb.innodb_trx_weight and versioning.update if decide to merge
it:
It's quite strange way to calculate transaction weight for choosing
deadlock victim, see TRX_WEIGHT() macro.
It just calculates the number of lock objects created by transaction.
There can be different amount of bits set in lock bitmaps, and amount of
lock objects does not make sense without calculating the amount of bits
set. The only benefit of this method is good performance.
As we create separate gap lock object for supremum, the amount of lock
objects become greater, and deadlock weight is different after the fix,
this causes the test failure.
The following tests fail with ER_UNKNOWN_SYSTEM_VARIABLE error. It does
not relate to the changes on this commit.
4c79e15...
by
Julius Goryavsky <email address hidden>
MDEV-30536: no expected deadlock in galera_insert_bulk test
Unstable test (galera_insert_bulk) temporarily disabled.
