File: binlog_truncate_active_log.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 (104 lines) | stat: -rw-r--r-- 3,035 bytes parent folder | download | duplicates (4)
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
104
# ==== Purpose ====
#
# Test verifies the truncation of single binary log file.
#
# ==== References ====
#
# MDEV-21117: recovery for --rpl-semi-sync-slave-enabled server

--source include/have_innodb.inc
--source include/have_aria.inc
# File: binlog_truncate_active_log.inc included in test makes use of
#       'debug_sync' facility.
--source include/have_debug_sync.inc
--source include/have_binlog_format_statement.inc

call mtr.add_suppression("Can.t init tc log");
call mtr.add_suppression("Aborting");

# The following cases are tested:
# A. 2pc transaction is followed by a blank "zero-engines" one
# B. 2pc transaction follows the blank one
# C. Similarly to A, with the XA blank transaction

RESET MASTER;
SET @@global.sync_binlog=1;
CREATE TABLE t (f INT) ENGINE=INNODB;
CREATE TABLE t2 (f INT) ENGINE=INNODB;
CREATE TABLE t4 (f INT) ENGINE=INNODB;
CREATE TABLE tm (f INT) ENGINE=Aria;

# Old (pre-crash) binlog file index initial value.
# It keeps incremented at the end of each case.
--let $binlog_file_index=1

--echo # Case A.
# Using 'debug_sync' hold 'query1' execution after 'query1' is flushed and
# synced to binary log but not yet committed. In an another connection hold
# 'query2' execution after 'query2' is flushed and synced to binlog.
# Crash and restart server with --init-rpl-role=SLAVE
#
# During recovery of binary log 'query1' status is checked with InnoDB engine,
# it will be in prepared but not yet commited. All transactions starting from
# 'query1' onwards will be removed from the binary log.
# Show-binlog-events is to prove that.

--let $truncate_gtid_pos = 0-1-7
--let $query1 = INSERT INTO t VALUES (20)
--let $query2 = DELETE FROM t2 WHERE f = 0 /* no such record */
--source binlog_truncate_active_log.inc

--echo # Case B.
# The inverted sequence ends up to truncate starting from $query2
--let $truncate_gtid_pos = 0-1-11
--let $query1 = DELETE FROM t2 WHERE f = 0
--let $query2 = INSERT INTO t VALUES (20)
--source binlog_truncate_active_log.inc


--echo # Case C.
delimiter |;
CREATE PROCEDURE sp_blank_xa()
BEGIN
 XA START   'blank';
 DELETE FROM t2 WHERE f = 0 /* no such record */;
 XA END     'blank';
 XA PREPARE 'blank';
END|
delimiter ;|

# The same as in A with $query2 being the zero-engine XA transaction.
# Both $query1 and $query2 are going to be truncated.
--let $truncate_gtid_pos = 0-1-15
--let $query1 = INSERT INTO t VALUES (20)
--let $query2 = CALL sp_blank_xa
--source binlog_truncate_active_log.inc

DROP PROCEDURE sp_blank_xa;


--echo # Case D.
delimiter |;
CREATE PROCEDURE sp_xa()
BEGIN
 XA START   'xid';
 DELETE FROM t WHERE f = 10;
 XA END     'xid';
 XA PREPARE 'xid';
END|
delimiter ;|

# The same as in B with $query1 being the prepared XA transaction.
# Truncation must occurs at $query2.
--let $truncate_gtid_pos = 0-1-21
--let $query1 = CALL sp_xa
--let $query2 = INSERT INTO t2 VALUES (20)
--source binlog_truncate_active_log.inc

DROP PROCEDURE sp_xa;


--echo # Cleanup
DROP TABLE t,t2,tm;
SET @@global.sync_binlog= default;
--echo # End of the tests