mirror of
https://github.com/MariaDB/server.git
synced 2025-02-09 23:24:11 +01:00
33de71c2f8
When a transaction fails in certification phase, it has connsumed one GTID, but as transaction must rollback, it will not go for commit ordering, and because of this also the wsrep XID checkpointing can happen out of order. This PR will make the thread, which has failed for certiication failure to wait for its commit order turn for checkpointing wsrep IXD in innodb rollback segment. There is a specific test for wsrep XID checkpointing ordering in mtr test: mysql-wsrep-bugs-607, which is added in this PR. Test galera_slave_replay depends also on this fix, as the second test phase may also assert for bad wsrep XID checkpointing order. galera_slave_replay.test had also other problems, which caused the test to fail immediately, thse are now fixes in this PR as well.
70 lines
2.1 KiB
Text
70 lines
2.1 KiB
Text
--source include/galera_cluster.inc
|
|
--source include/have_debug.inc
|
|
--source include/have_debug_sync.inc
|
|
--source include/galera_have_debug_sync.inc
|
|
--source include/have_log_bin.inc
|
|
|
|
#
|
|
# Test case to stress the order of wsrep XID checkpointing.
|
|
#
|
|
# In buggy version, the transaction which failed certification can
|
|
# rush to record wsrep XID checkpoint before the offending applier,
|
|
# causing assert in innodb sys header update routine
|
|
#
|
|
|
|
--echo #
|
|
--echo # test the order of wsrep XID storage after certifiation failure
|
|
--echo #
|
|
|
|
--connection node_1
|
|
set session wsrep_sync_wait=0;
|
|
|
|
create table t1 (i int primary key, j int);
|
|
|
|
insert into t1 values (4, 0);
|
|
|
|
--connect node_2b, 127.0.0.1, root, , test, $NODE_MYPORT_2
|
|
--connection node_2b
|
|
set session wsrep_sync_wait=0;
|
|
# wait for the last insert to be replicated from node 1
|
|
--let $wait_condition = SELECT COUNT(*) = 1 FROM test.t1;
|
|
--source include/wait_condition.inc
|
|
|
|
# block applier before applying
|
|
SET GLOBAL debug_dbug = "d,sync.wsrep_apply_cb";
|
|
|
|
# send update from node 1, it will pause in the sync point
|
|
--connection node_1
|
|
UPDATE test.t1 set j=1 where i=4;
|
|
|
|
--connection node_2b
|
|
# wait until applier has reached the sync point
|
|
SET SESSION DEBUG_SYNC = "now WAIT_FOR sync.wsrep_apply_cb_reached";
|
|
|
|
# look number of cert failures so far, and expect one more to happen
|
|
--let $expected_cert_failures = `SELECT VARIABLE_VALUE+1 FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME = 'wsrep_local_cert_failures'`
|
|
|
|
# Inject a conflicting update in node 2, it should fail in certification
|
|
--connection node_2
|
|
set session wsrep_sync_wait=0;
|
|
set session wsrep_retry_autocommit=0;
|
|
--send UPDATE test.t1 SET j=2 WHERE i=4
|
|
|
|
--connection node_2b
|
|
# wait until the update has hit certification failure
|
|
|
|
--let $wait_condition = SELECT VARIABLE_VALUE = $expected_cert_failures FROM INFORMATION_SCHEMA.GLOBAL_STATUS WHERE VARIABLE_NAME = 'wsrep_local_cert_failures'
|
|
--source include/wait_condition.inc
|
|
|
|
# release the applier
|
|
SET DEBUG_SYNC = "now SIGNAL signal.wsrep_apply_cb";
|
|
|
|
SET GLOBAL debug_dbug = "";
|
|
SET DEBUG_SYNC = "RESET";
|
|
|
|
--connection node_2
|
|
--error ER_LOCK_DEADLOCK
|
|
--reap
|
|
select * from t1;
|
|
|
|
DROP TABLE t1;
|