mirror of
https://github.com/MariaDB/server.git
synced 2025-02-04 21:02:17 +01:00
0ad52e4d6a
If replicating an event in ROW format, and InnoDB detects a deadlock while searching for a row, the row event will error and rollback in InnoDB and indicate that the binlog cache also needs to be cleared, i.e. by marking thd->transaction_rollback_request. In the normal case, this will trigger an error in Rows_log_event::do_apply_event() and cause a rollback. During the Rows_log_event::do_apply_event() cleanup of a successful event application, there is a DBUG_ASSERT in log_event_server.cc::rows_event_stmt_cleanup(), which sets the expectation that thd->transaction_rollback_request cannot be set because the general rollback (i.e. not the InnoDB rollback) should have happened already. However, if the replica is configured to skip deadlock errors, the rows event logic will clear the error and continue on, as if no error happened. This results in thd->transaction_rollback_request being set while in rows_event_stmt_cleanup(), thereby triggering the assertion. This patch fixes this in the following ways: 1) The assertion is invalid, and thereby removed. 2) The rollback case is forced in rows_event_stmt_cleanup() if transaction_rollback_request is set. Note the differing behavior between transactions which are skipped due to deadlock errors and other errors. When a transaction is skipped due to an ignored deadlock error, the entire transaction is rolled back and skipped (though note MDEV-33930 which allows statements in the same transaction after the deadlock-inducing one to commit). When a transaction is skipped due to ignoring a different error, only the erroring statements are rolled-back and skipped - the rest of the transaction will execute as normal. The effect of this can be seen in the test results. The added test case to rpl_skip_error.test shows that only statements which are ignored due to non-deadlock errors are ignored in larger transactions. A diff between rpl_temporary_error2_skip_all.result and rpl_temporary_error2.result shows that all statements in the errored transaction are rolled back (diff pasted below): : diff rpl_temporary_error2.result rpl_temporary_error2_skip_all.result 49c49 < 2 1 --- > 2 NULL 51c51 < 4 1 --- > 4 NULL 53c53 < * There will be two rows in t2 due to the retry. --- > * There will be one row in t2 because the ignored deadlock does not retry. 57d56 < 1 59c58 < 1 --- > 0 Reviewed By: ============ Andrei Elkin <andrei.elkin@mariadb.com>
155 lines
4.1 KiB
Text
155 lines
4.1 KiB
Text
include/master-slave.inc
|
|
[connection master]
|
|
connection slave;
|
|
connection master;
|
|
==== Test Without sql_mode=strict_trans_tables ====
|
|
create table t1 (n int not null primary key);
|
|
connection slave;
|
|
insert into t1 values (1);
|
|
connection master;
|
|
insert into t1 values (1);
|
|
insert into t1 values (2),(3);
|
|
connection slave;
|
|
select * from t1 order by n;
|
|
n
|
|
1
|
|
2
|
|
3
|
|
==== Test With sql_mode=strict_trans_tables ====
|
|
insert into t1 values (7),(8);
|
|
connection master;
|
|
set sql_mode=strict_trans_tables;
|
|
insert into t1 values (7), (8), (9);
|
|
connection slave;
|
|
select * from t1 order by n;
|
|
n
|
|
1
|
|
2
|
|
3
|
|
7
|
|
8
|
|
include/check_slave_is_running.inc
|
|
==== Clean Up ====
|
|
connection master;
|
|
drop table t1;
|
|
connection slave;
|
|
connection master;
|
|
create table t1(a int primary key);
|
|
insert into t1 values (1),(2);
|
|
SET SQL_LOG_BIN=0;
|
|
delete from t1;
|
|
SET SQL_LOG_BIN=1;
|
|
set sql_mode=strict_trans_tables;
|
|
insert into t1 values (1), (2), (3);
|
|
connection slave;
|
|
select * from t1;
|
|
a
|
|
1
|
|
2
|
|
include/check_slave_is_running.inc
|
|
==== Clean Up ====
|
|
connection master;
|
|
drop table t1;
|
|
connection slave;
|
|
==== Using Innodb ====
|
|
connection master;
|
|
SET SQL_LOG_BIN=0;
|
|
CREATE TABLE t1(id INT NOT NULL PRIMARY KEY, data INT) Engine=InnoDB;
|
|
SHOW CREATE TABLE t1;
|
|
Table Create Table
|
|
t1 CREATE TABLE `t1` (
|
|
`id` int(11) NOT NULL,
|
|
`data` int(11) DEFAULT NULL,
|
|
PRIMARY KEY (`id`)
|
|
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci
|
|
SET SQL_LOG_BIN=1;
|
|
connection slave;
|
|
call mtr.add_suppression("Slave SQL.*Could not execute .*te_rows event on table test.t.; Duplicate entry.* error.* 1062");
|
|
CREATE TABLE t1(id INT NOT NULL PRIMARY KEY, data INT) Engine=InnoDB;
|
|
SHOW CREATE TABLE t1;
|
|
Table Create Table
|
|
t1 CREATE TABLE `t1` (
|
|
`id` int(11) NOT NULL,
|
|
`data` int(11) DEFAULT NULL,
|
|
PRIMARY KEY (`id`)
|
|
) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci
|
|
connection master;
|
|
INSERT INTO t1 VALUES(1, 1);
|
|
INSERT INTO t1 VALUES(2, 1);
|
|
INSERT INTO t1 VALUES(3, 1);
|
|
INSERT INTO t1 VALUES(4, 1);
|
|
SET SQL_LOG_BIN=0;
|
|
DELETE FROM t1 WHERE id = 4;
|
|
SET SQL_LOG_BIN=1;
|
|
UPDATE t1 SET id= id + 3, data = 2;
|
|
connection slave;
|
|
|
|
**** We cannot execute a select as there are differences in the
|
|
**** behavior between STMT and RBR.
|
|
==== Using MyIsam ====
|
|
connection master;
|
|
SET SQL_LOG_BIN=0;
|
|
CREATE TABLE t2(id INT NOT NULL PRIMARY KEY, data INT) Engine=MyIsam;
|
|
SHOW CREATE TABLE t2;
|
|
Table Create Table
|
|
t2 CREATE TABLE `t2` (
|
|
`id` int(11) NOT NULL,
|
|
`data` int(11) DEFAULT NULL,
|
|
PRIMARY KEY (`id`)
|
|
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci
|
|
SET SQL_LOG_BIN=1;
|
|
connection slave;
|
|
CREATE TABLE t2(id INT NOT NULL PRIMARY KEY, data INT) Engine=MyIsam;
|
|
SHOW CREATE TABLE t2;
|
|
Table Create Table
|
|
t2 CREATE TABLE `t2` (
|
|
`id` int(11) NOT NULL,
|
|
`data` int(11) DEFAULT NULL,
|
|
PRIMARY KEY (`id`)
|
|
) ENGINE=MyISAM DEFAULT CHARSET=latin1 COLLATE=latin1_swedish_ci
|
|
# Slave_skipped_errros = 4
|
|
connection master;
|
|
INSERT INTO t2 VALUES(1, 1);
|
|
INSERT INTO t2 VALUES(2, 1);
|
|
INSERT INTO t2 VALUES(3, 1);
|
|
INSERT INTO t2 VALUES(5, 1);
|
|
SET SQL_LOG_BIN=0;
|
|
DELETE FROM t2 WHERE id = 5;
|
|
SET SQL_LOG_BIN=1;
|
|
UPDATE t2 SET id= id + 3, data = 2;
|
|
connection slave;
|
|
|
|
# Slave_skipped_errros = 5
|
|
**** We cannot execute a select as there are differences in the
|
|
**** behavior between STMT and RBR.
|
|
****
|
|
**** Ensure transactions which are skipped due to encountering a
|
|
**** non-deadlock error which is present in --slave-skip-errors result
|
|
**** in partially committed transactions
|
|
connection master;
|
|
CREATE TABLE t3 (a INT UNIQUE) ENGINE=InnoDB;
|
|
connection slave;
|
|
connection slave;
|
|
INSERT INTO t3 VALUES (3);
|
|
connection master;
|
|
BEGIN;
|
|
INSERT INTO t3 VALUES (1);
|
|
INSERT INTO t3 VALUES (2);
|
|
INSERT INTO t3 VALUES (3);
|
|
INSERT INTO t3 VALUES (4);
|
|
COMMIT;
|
|
connection slave;
|
|
**** Master and slave tables should have the same data, due to the
|
|
**** partially replicated transaction's data overlapping with the data
|
|
**** that pre-existed on the slave. That is, despite the transaction
|
|
**** consisting of 4 statements, the errored statement should be ignored
|
|
**** and the other 3 should commit successfully.
|
|
include/diff_tables.inc [master:t3,slave:t3]
|
|
connection master;
|
|
DROP TABLE t3;
|
|
==== Clean Up ====
|
|
connection master;
|
|
DROP TABLE t1;
|
|
DROP TABLE t2;
|
|
connection slave;
|
|
include/rpl_end.inc
|