1
0
mirror of https://github.com/MariaDB/server.git synced 2025-08-26 01:44:06 +03:00
Files
mariadb/mysql-test/suite/rpl/t/rpl_row_find_row.test
Sven Sandberg 09c80e12c5 BUG#49978: Replication tests don't clean up replication state at the end
Major replication test framework cleanup. This does the following:
 - Ensure that all tests clean up the replication state when they
   finish, by making check-testcase check the output of SHOW SLAVE STATUS.
   This implies:
    - Slave must not be running after test finished. This is good
      because it removes the risk for sporadic errors in subsequent
      tests when a test forgets to sync correctly.
    - Slave SQL and IO errors must be cleared when test ends. This is
      good because we will notice if a test gets an unexpected error in
      the slave threads near the end.
    - We no longer have to clean up before a test starts.
 - Ensure that all tests that wait for an error in one of the slave
   threads waits for a specific error. It is no longer possible to
   source wait_for_slave_[sql|io]_to_stop.inc when there is an error
   in one of the slave threads. This is good because:
    - If a test expects an error but there is a bug that causes
      another error to happen, or if it stops the slave thread without
      an error, then we will notice.
    - When developing tests, wait_for_*_to_[start|stop].inc will fail
      immediately if there is an error in the relevant slave thread.
      Before this patch, we had to wait for the timeout.
 - Remove duplicated and repeated code for setting up unusual replication
   topologies. Now, there is a single file that is capable of setting
   up arbitrary topologies (include/rpl_init.inc, but
   include/master-slave.inc is still available for the most common
   topology). Tests can now end with include/rpl_end.inc, which will clean
   up correctly no matter what topology is used. The topology can be
   changed with include/rpl_change_topology.inc.
 - Improved debug information when tests fail. This includes:
    - debug info is printed on all servers configured by include/rpl_init.inc
    - User can set $rpl_debug=1, which makes auxiliary replication files
      print relevant debug info.
 - Improved documentation for all auxiliary replication files. Now they
   describe purpose, usage, parameters, and side effects.
 - Many small code cleanups:
    - Made have_innodb.inc output a sensible error message.
    - Moved contents of rpl000017-slave.sh into rpl000017.test
    - Added mysqltest variables that expose the current state of
      disable_warnings/enable_warnings and friends.
    - Too many to list here: see per-file comments for details.
2010-12-19 18:07:28 +01:00

104 lines
2.3 KiB
Plaintext

# BUG#47312: RBR: Disabling key on slave breaks replication:
# HA_ERR_WRONG_INDEX
#
# Description
# ===========
#
# This test case checks whether disabling a key on a slave breaks
# replication or not.
#
# Case #1, shows that while not using ALTER TABLE... DISABLE KEYS and
# the slave has no key defined while the master has one, replication
# won't break.
#
# Case #2, shows that before patch for BUG#47312, if defining key on
# slave table, and later disable it, replication would break. This
# has been fixed.
#
-- source include/master-slave.inc
-- source include/have_binlog_format_row.inc
#
# Case #1: master has key, but slave has not.
# Replication does not break.
#
SET SQL_LOG_BIN=0;
CREATE TABLE t (a int, b int, c int, key(b));
SET SQL_LOG_BIN=1;
-- connection slave
CREATE TABLE t (a int, b int, c int);
-- connection master
INSERT INTO t VALUES (1,2,4);
INSERT INTO t VALUES (4,3,4);
DELETE FROM t;
-- sync_slave_with_master
-- connection master
DROP TABLE t;
-- sync_slave_with_master
#
# Case #2: master has key, slave also has one,
# but it gets disabled sometime.
# Replication does not break anymore.
#
--source include/rpl_reset.inc
-- connection master
CREATE TABLE t (a int, b int, c int, key(b));
-- sync_slave_with_master
ALTER TABLE t DISABLE KEYS;
-- connection master
INSERT INTO t VALUES (1,2,4);
INSERT INTO t VALUES (4,3,4);
DELETE FROM t;
-- sync_slave_with_master
-- connection master
DROP TABLE t;
-- sync_slave_with_master
#
# BUG#53893: RBR: nullable unique key can lead to out-of-sync slave
#
#
# We insert two rows. Both with part of UNIQUE KEY set to null.
# Then we update the last row inserted. On master the correct
# row is updated. On the slave the wrong row would be updated
# because the engine would look it up by the NULL Unique KEY.
# As a consquence, the wrong row would be updated.
#
-- source include/rpl_reset.inc
-- connection master
CREATE TABLE t1 (c1 INT NOT NULL, c2 INT NOT NULL, c3 INT, UNIQUE KEY(c1,c3), KEY(c2));
INSERT INTO t1(c1,c2) VALUES(1,1);
INSERT INTO t1(c1,c2) VALUES(1,2);
UPDATE t1 SET c1=1000 WHERE c2=2;
-- sync_slave_with_master
-- let $diff_tables= master:t1, slave:t1
-- source include/diff_tables.inc
-- connection master
DROP TABLE t1;
-- sync_slave_with_master
--source include/rpl_end.inc