|
| 1 | +# ===== Purpose ===== |
| 2 | +# |
| 3 | +# 1) The purpose of this test is to check if the GTIDs, and the data dumped |
| 4 | +# by mysqldump are consistent. Especially the case when the server has |
| 5 | +# GTIDs enabled, and there are transactions running in the background, |
| 6 | +# during the dump. |
| 7 | +# 2) We've to also make sure that the dump file can be restored on a |
| 8 | +# GTID aware server. |
| 9 | +# |
| 10 | +# ===== Implementation ===== |
| 11 | +# |
| 12 | +# Consists of 2 steps |
| 13 | +# |
| 14 | +# - Step 1 - |
| 15 | +# 1) Create a test table 't', in database 'db' |
| 16 | +# 2) Create a stored procedure, which will be called just before mysqldump |
| 17 | +# is executed. This will help us to mimick a scenario in which there are |
| 18 | +# transactions going on in the background, while mysqldump is dumping |
| 19 | +# the databases. |
| 20 | +# 3) Call the procedure, then start mysqldump just after that |
| 21 | +# |
| 22 | +# - Step 2 - |
| 23 | +# 5) Now restore the dump file to the slave |
| 24 | +# 6) Execute some statements on the master |
| 25 | +# 7) Sync master, and slave |
| 26 | +# 8) The slave's GTID_EXECUTED must be equal to the master's one |
| 27 | +# |
| 28 | +# ===== Requirements ===== |
| 29 | +# |
| 30 | +# 1) The dump captured by mysqldump with --single-transaction and |
| 31 | +# set-gtid-purged=ON must contain the exact set of transaction GTIDs |
| 32 | +# that were extracted. |
| 33 | +# 2) The dump file can be restored without any issue |
| 34 | +# 3) The replication is working fine |
| 35 | +# 4) The slave's GTID_EXECUTED must be equal to the master's one |
| 36 | +# when replication catches up. |
| 37 | +# |
| 38 | +# ===== References ===== |
| 39 | +# |
| 40 | +# Bug#33630199 : mysqldump make a non-consistent backup with |
| 41 | +# --single-transaction option |
| 42 | + |
| 43 | +--source include/have_binlog_format_row.inc |
| 44 | +--let $rpl_gtid_utils= 1 |
| 45 | +--let $rpl_skip_start_slave= 1 |
| 46 | +--source include/master-slave.inc |
| 47 | + |
| 48 | +# Step 1 |
| 49 | +# Running mysqldump, and inserting data into the tables at the same time |
| 50 | + |
| 51 | +# File, which is going to be used by mysqldump |
| 52 | +let $mysqldumpfile = $MYSQLTEST_VARDIR/tmp/bug33630199_dump.sql; |
| 53 | + |
| 54 | +# Create test db |
| 55 | +CREATE DATABASE db; |
| 56 | + |
| 57 | +USE db; |
| 58 | + |
| 59 | +# Create test table |
| 60 | +CREATE TABLE t(num INT, num2 INT); |
| 61 | + |
| 62 | +# Create the stored procedure. |
| 63 | +# We need to keep on sending insert statements to the server, |
| 64 | +# while on the other session, mysqldump is dumping the data. |
| 65 | +DELIMITER $; |
| 66 | + |
| 67 | +CREATE PROCEDURE insertParallely() |
| 68 | +BEGIN |
| 69 | + DECLARE counter INT DEFAULT 1; |
| 70 | + WHILE counter <= 10000 DO |
| 71 | + INSERT INTO db.t VALUES(counter, 1); |
| 72 | + SET counter = counter + 1; |
| 73 | + END WHILE; |
| 74 | +END$ |
| 75 | + |
| 76 | +DELIMITER ;$ |
| 77 | + |
| 78 | +# Start sending insert statements |
| 79 | +--send CALL insertParallely(); |
| 80 | + |
| 81 | +--let $rpl_connection_name= server_1 |
| 82 | +--source include/rpl_connection.inc |
| 83 | + |
| 84 | +# Dump on fast machines could be empty. |
| 85 | +# Make sure that somethings inserted. |
| 86 | +--let $wait_condition= SELECT COUNT(*) > 10 FROM db.t |
| 87 | +--source include/wait_condition.inc |
| 88 | + |
| 89 | +# Start dump |
| 90 | +--exec $MYSQL_DUMP --compact --single-transaction --set-gtid-purged=ON -ER --databases db > $mysqldumpfile |
| 91 | + |
| 92 | +--source include/rpl_connection_master.inc |
| 93 | + |
| 94 | +--reap |
| 95 | + |
| 96 | +# End of Step 1 |
| 97 | + |
| 98 | +# Step 2 |
| 99 | +# Restoring the dump file, and syncing master-slave |
| 100 | + |
| 101 | +--source include/rpl_connection_slave.inc |
| 102 | + |
| 103 | +--exec $MYSQL_SLAVE --force < $mysqldumpfile |
| 104 | +--remove_file $mysqldumpfile |
| 105 | + |
| 106 | +--source include/start_slave.inc |
| 107 | + |
| 108 | +--source include/rpl_connection_master.inc |
| 109 | + |
| 110 | +# Make sure that replication is working. |
| 111 | +# Execute an UPDATE that updates all the table data. |
| 112 | +# If some data is missing from the dump but not from the GTID set, |
| 113 | +# replication errors will occur. |
| 114 | +UPDATE db.t SET num2=2 WHERE num2=1; |
| 115 | + |
| 116 | +--let $masters_gtid_executed=`SELECT @@GLOBAL.gtid_executed` |
| 117 | + |
| 118 | +--source include/sync_slave_sql_with_master.inc |
| 119 | + |
| 120 | +--source include/rpl_connection_slave.inc |
| 121 | + |
| 122 | +# Conclusion: |
| 123 | +# Executed GTIDs on the master and the slave are equal |
| 124 | + |
| 125 | +# Count the rows in 't' with num2=2 on slave, must be 10000 |
| 126 | +--let $row_count = `SELECT 10000 = (SELECT COUNT(*) FROM db.t WHERE num2=2)` |
| 127 | +--let $assert_text= The row count with num2=2 must be 10000 on slave |
| 128 | +--let $assert_cond= $row_count |
| 129 | +--source include/assert.inc |
| 130 | + |
| 131 | +# GTID_EXECUTED must be equal for both master, and slave |
| 132 | +--let $is_equal= `SELECT GTID_IS_EQUAL('$masters_gtid_executed', @@GLOBAL.gtid_executed)` |
| 133 | +--let $assert_text= The slave's GTID_EXECUTED must be equal to the master's one |
| 134 | +--let $assert_cond= $is_equal |
| 135 | +--source include/assert.inc |
| 136 | + |
| 137 | +--source include/rpl_connection_master.inc |
| 138 | +DROP DATABASE db; |
| 139 | + |
| 140 | +--source include/rpl_end.inc |
| 141 | + |
| 142 | +# End of Step 2 |
0 commit comments