File: rpl_row_find_row.test

package info (click to toggle)
mariadb 1%3A11.8.3-1
  • links: PTS, VCS
  • area: main
  • in suites: sid
  • size: 772,520 kB
  • sloc: ansic: 2,414,714; cpp: 1,791,394; asm: 381,336; perl: 62,905; sh: 49,647; pascal: 40,897; java: 39,363; python: 20,791; yacc: 20,432; sql: 17,907; xml: 12,344; ruby: 8,544; cs: 6,542; makefile: 6,145; ada: 1,879; lex: 1,193; javascript: 996; objc: 80; tcl: 73; awk: 46; php: 22
file content (103 lines) | stat: -rw-r--r-- 2,352 bytes parent folder | download | duplicates (7)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
# 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/have_binlog_format_row.inc
-- source include/master-slave.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