1
0
mirror of https://github.com/MariaDB/server.git synced 2025-11-30 05:23:50 +03:00
Files
mariadb/mysql-test/suite/galera/t/galera_bf_kill.test
sjaakola 7bffe468b2 MDEV-21910 Deadlock between BF abort and manual KILL command
When high priority replication slave applier encounters lock conflict in innodb,
it will force the conflicting lock holder transaction (victim) to rollback.
This is a must in multi-master sychronous replication model to avoid cluster lock-up.
This high priority victim abort (aka "brute force" (BF) abort), is started
from innodb lock manager while holding the victim's transaction's (trx) mutex.
Depending on the execution state of the victim transaction, it may happen that the
BF abort will call for THD::awake() to wake up the victim transaction for the rollback.
Now, if BF abort requires THD::awake() to be called, then the applier thread executed
locking protocol of: victim trx mutex -> victim THD::LOCK_thd_data

If, at the same time another DBMS super user issues KILL command to abort the same victim,
it will execute locking protocol of: victim THD::LOCK_thd_data  -> victim trx mutex.
These two locking protocol acquire mutexes in opposite order, hence unresolvable mutex locking
deadlock may occur.

The fix in this commit adds THD::wsrep_aborter flag to synchronize who can kill the victim
This flag is set both when BF is called for from innodb and by KILL command.
Either path of victim killing will bail out if victim's wsrep_killed is already
set to avoid mutex conflicts with the other aborter execution. THD::wsrep_aborter
records the aborter THD's ID. This is needed to preserve the right to kill
the victim from different locations for the same aborter thread.
It is also good error logging, to see who is reponsible for the abort.

A new test case was added in galera.galera_bf_kill_debug.test for scenario where
wsrep applier thread and manual KILL command try to kill same idle victim
2020-07-22 08:20:10 +03:00

142 lines
3.4 KiB
Plaintext

--source include/galera_cluster.inc
--source include/have_innodb.inc
#
# Test case 1: Start a transaction on node_2a and kill it
# from other connection on same node
#
--connection node_2
CREATE TABLE t1(a int not null primary key auto_increment,b int) engine=InnoDB;
insert into t1 values (NULL,1);
--connect node_2a, 127.0.0.1, root, , test, $NODE_MYPORT_2
--connection node_2a
begin;
update t1 set a = 5;
--connection node_2
--let $wait_condition = SELECT COUNT(*) = 1 FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'root' AND COMMAND = 'Sleep' LIMIT 1
--source include/wait_condition.inc
--let $k_thread = `SELECT ID FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'root' AND COMMAND = 'Sleep' LIMIT 1`
--disable_query_log
--eval KILL $k_thread
--enable_query_log
select * from t1;
--disconnect node_2a
#
# Test case 2: Start a transaction on node_2a and use
# kill query from other connection on same node
#
--connect node_2a, 127.0.0.1, root, , test, $NODE_MYPORT_2
--connection node_2a
begin;
update t1 set a =5;
--connection node_2
--let $wait_condition = SELECT COUNT(*) = 1 FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'root' AND COMMAND = 'Sleep' LIMIT 1
--source include/wait_condition.inc
--let $k_thread = `SELECT ID FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'root' AND COMMAND = 'Sleep' LIMIT 1`
--disable_query_log
--eval KILL QUERY $k_thread
--enable_query_log
select * from t1;
--disconnect node_2a
#
# Test case 3: Start a transaction on node_2a and start a DDL on other transaction
# that will then abort node_2a transaction
#
--connect node_2a, 127.0.0.1, root, , test, $NODE_MYPORT_2
--connection node_2a
begin;
update t1 set a =5, b=2;
--connection node_2
ALTER TABLE t1 ADD UNIQUE KEY b1(b);
ALTER TABLE t1 DROP KEY b1;
select * from t1;
--disconnect node_2a
#
# Test case 4: Start a transaction on node_2a and conflicting transaction on node_2b
# and start a DDL on other transaction that will then abort node_2a and node_2b
# transactions
#
--connect node_2a, 127.0.0.1, root, , test, $NODE_MYPORT_2
--connection node_2a
begin;
update t1 set a =5, b=2;
--connect node_2b, 127.0.0.1, root, , test, $NODE_MYPORT_2
--connection node_2b
begin;
send update t1 set a =6, b=7;
--connection node_2
ALTER TABLE t1 ADD UNIQUE KEY b2(b);
ALTER TABLE t1 DROP KEY b2;
select * from t1;
--disconnect node_2a
--disconnect node_2b
#
# Test case 5: Start a transaction on node_2a with wsrep disabled
# and start a DDL on other transaction that will then abort node_2a
# transactions
#
--connect node_2a, 127.0.0.1, root, , test, $NODE_MYPORT_2
--connection node_2a
SET SESSION wsrep_on=OFF;
begin;
update t1 set a =5, b=2;
--connection node_2
ALTER TABLE t1 ADD UNIQUE KEY b3(b);
select * from t1;
--disconnect node_2a
#
# Test case 6: Start a transaction on node_2a with wsrep disabled
# and kill it from other connection on same node
#
--connect node_2a, 127.0.0.1, root, , test, $NODE_MYPORT_2
--connection node_2a
SET SESSION wsrep_on=OFF;
begin;
update t1 set a =5, b=2;
--connection node_2
--let $wait_condition = SELECT COUNT(*) = 1 FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'root' AND COMMAND = 'Sleep' LIMIT 1
--source include/wait_condition.inc
--let $k_thread = `SELECT ID FROM INFORMATION_SCHEMA.PROCESSLIST WHERE USER = 'root' AND COMMAND = 'Sleep' LIMIT 1`
--disable_query_log
--eval KILL $k_thread
--enable_query_log
select * from t1;
--disconnect node_2a
--connection node_1
drop table t1;