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
|
# The test verifies that crashed in the middle of XA COMMIT server
# does not lose the prepared transaction, neither it gets committed.
# This is to test that fixes to BUG #12161 Xa recovery and client disconnection
# do not break existing policy.
# The prepared XA can be identified and concluded with XA COMMIT or ROLLBACK,
# "manually" by the user.
--source include/not_valgrind.inc # Test takes too much time in Valgrind
--source include/have_debug.inc
# There's some format specifics through show_binlog_events,
# but MIXED is chosen rather to optimize.
--source include/have_binlog_format_mixed.inc
--source include/linux.inc
#
# Crash-safe testing is difficult on other than Linux.
# TODO: Open it back at XA-commit/rollback crash-safe bug/FR fixing.
#
--source include/master-slave.inc
--source include/rpl_connection_slave.inc
--source include/stop_slave.inc
--source include/rpl_connection_master.inc
call mtr.add_suppression("Found 1 prepared XA transactions");
CREATE TABLE t1 (a INT);
# Transaction is committed (XA-rollback) only
# to binlog, not to engine.
XA START 'xid_partly_rolled_back';
INSERT INTO t1 VALUES(1);
XA END 'xid_partly_rolled_back';
XA PREPARE 'xid_partly_rolled_back';
# Server crashes after doing the rollback, with Innodb engine
# rollback invoking first. XA ROLLBACK query is binlogged afterward.
# Yet the innodb tranasction has a good chance to remain in
# the engine after the master server restart which produces
# desired scenario: the query is logged, but the engine did not necessarily
# roll back.
--exec echo "wait" > $MYSQLTEST_VARDIR/tmp/mysqld.1.expect
SET @@session.debug="+d,crash_after_xa_rollback";
# CR_SERVER_LOST
--error 2013
XA ROLLBACK 'xid_partly_rolled_back';
#
# Server restart
#
--enable_reconnect
--source include/wait_until_disconnected.inc
--let $rpl_server_number= 1
--source include/rpl_start_server.inc
--disable_reconnect
--source include/rpl_connection_master.inc
# Due to non-determinism mentioned in the simulation part above
# the following query is commented out.
# Correct rollback handlerton ordering and thus deterministic behaviour
# is scheduled for bug#20672719 fixing (TODO: uncomment)
# XA RECOVER;
--let $assert_text = Zero records in t1 is expected at master
--let $assert_cond = COUNT(*) = 0 FROM t1
--source include/assert.inc
--source include/show_binlog_events.inc
SET @save.sql_log_bin = @@session.sql_log_bin;
SET @@session.sql_log_bin = 0;
#
# Rollback
# TODO: same as above, remove 0.
--error 0,ER_XAER_NOTA
XA ROLLBACK 'xid_partly_rolled_back';
SET @@session.sql_log_bin = @save.sql_log_bin;
--source include/rpl_connection_slave.inc
--source include/start_slave.inc
# Verify that slave has 'xid_partly_rolled_back' rolled back.
--source include/rpl_connection_master.inc
--source include/sync_slave_sql_with_master.inc
--let $assert_text = Zero records in t1 is expected at slave
--let $assert_cond = COUNT(*) = 0 FROM t1
--source include/assert.inc
#
# Cleanup
#
--source include/rpl_connection_master.inc
DROP TABLE t1;
--source include/sync_slave_sql_with_master.inc
--source include/rpl_end.inc
|
