mirror of
https://github.com/MariaDB/server.git
synced 2025-01-20 22:12:30 +01:00
eb191861e3
The rpl_trigger test case indicated a problem with idempotency support when run under row-based replication, which this patch fixes. However, despite this, the test is not designed for execution under row-based replication and hence rpl_trigger.test is not executed under row-based replication. The problem is that the test expects triggers to be executed when the slave updates rows on the slave, and this is (deliberately) not done with row-based replication. sql/log_event.cc: Adding function to print symbolic name of handler errors for debug purposes. Ignoring some more error messages to provide full idempotency support for update and delete operations. mysql-test/suite/rpl/r/rpl_idempotency.result: New BitKeeper file ``mysql-test/suite/rpl/r/rpl_idempotency.result'' mysql-test/suite/rpl/t/rpl_idempotency.test: New BitKeeper file ``mysql-test/suite/rpl/t/rpl_idempotency.test''
79 lines
2.7 KiB
Text
79 lines
2.7 KiB
Text
# Testing various forms of idempotency for replication that should
|
|
# work the same way under statement based as under row based.
|
|
|
|
source include/master-slave.inc;
|
|
|
|
connection master;
|
|
CREATE TABLE t1 (a INT PRIMARY KEY);
|
|
CREATE TABLE t2 (a INT);
|
|
INSERT INTO t1 VALUES (-1),(-2),(-3);
|
|
INSERT INTO t2 VALUES (-1),(-2),(-3);
|
|
sync_slave_with_master;
|
|
|
|
# A delete for a row that does not exist, the statement is
|
|
# deliberately written to be idempotent for statement-based
|
|
# replication as well. We test this towards both a table with a
|
|
# primary key and without a primary key.
|
|
|
|
connection slave;
|
|
DELETE FROM t1 WHERE a = -2;
|
|
DELETE FROM t2 WHERE a = -2;
|
|
connection master;
|
|
DELETE FROM t1 WHERE a = -2;
|
|
DELETE FROM t2 WHERE a = -2;
|
|
SELECT * FROM t1 ORDER BY a;
|
|
SELECT * FROM t2 ORDER BY a;
|
|
sync_slave_with_master;
|
|
SELECT * FROM t1 ORDER BY a;
|
|
SELECT * FROM t2 ORDER BY a;
|
|
let $last_error = query_get_value("SHOW SLAVE STATUS", Last_SQL_Errno, 1);
|
|
disable_query_log;
|
|
eval SELECT "$last_error" AS Last_SQL_Error;
|
|
enable_query_log;
|
|
|
|
# An insert of a row that already exists. Since we are replacing the
|
|
# row if it already exists, the most apropriate representation is
|
|
# INSERT IGNORE. We only test this towards a table with a primary key,
|
|
# since the other case does not make sense.
|
|
|
|
INSERT IGNORE INTO t1 VALUES (-2);
|
|
connection master;
|
|
INSERT IGNORE INTO t1 VALUES (-2);
|
|
SELECT * FROM t1 ORDER BY a;
|
|
sync_slave_with_master;
|
|
SELECT * FROM t1 ORDER BY a;
|
|
let $last_error = query_get_value("SHOW SLAVE STATUS", Last_SQL_Errno, 1);
|
|
disable_query_log;
|
|
eval SELECT "$last_error" AS Last_SQL_Error;
|
|
enable_query_log;
|
|
|
|
# BUG#19958: RBR idempotency issue for UPDATE and DELETE
|
|
|
|
# Statement-based and row-based replication have different behaviour
|
|
# when updating a row with an explicit WHERE-clause that matches
|
|
# exactly one row (or no row at all). For statement-based replication,
|
|
# the statement is idempotent since the first time it is executed, it
|
|
# will update exactly one row, and the second time it will not update
|
|
# any row at all. This was not the case for row-based replication, so
|
|
# we test under both row-based and statement-based replication both
|
|
# for tables with and without primary keys.
|
|
|
|
connection slave;
|
|
UPDATE t1 SET a = 1 WHERE a = -1;
|
|
UPDATE t2 SET a = 1 WHERE a = -1;
|
|
connection master;
|
|
UPDATE t1 SET a = 1 WHERE a = -1;
|
|
UPDATE t2 SET a = 1 WHERE a = -1;
|
|
SELECT * FROM t1 ORDER BY a;
|
|
SELECT * FROM t2 ORDER BY a;
|
|
sync_slave_with_master;
|
|
SELECT * FROM t1 ORDER BY a;
|
|
SELECT * FROM t2 ORDER BY a;
|
|
let $last_error = query_get_value("SHOW SLAVE STATUS", Last_SQL_Errno, 1);
|
|
disable_query_log;
|
|
eval SELECT "$last_error" AS Last_SQL_Error;
|
|
enable_query_log;
|
|
|
|
connection master;
|
|
DROP TABLE t1, t2;
|
|
sync_slave_with_master;
|