mariadb/mysql-test/suite/rpl/r/rpl_stm_000001.result
Kristian Nielsen 0a68328673 MDEV-34705: Binlog-in-engine: Protect against concurrent RESET MASTER and dump threads
This is actually an existing problem in the old binlog implementation, and
this patch is applicable to old binlog also. The problem is that RESET
MASTER can run concurrently with binlog dump threads / connected slaves.
This will remove the binlog from under the feet of the reader, which can
cause all sorts of strange behaviour.

This patch fixes the problem by disallowing to run RESET MASTER when dump
threads (or other RESET MASTER or SHOW BINARY LOGS) are running. An error is
thrown in this case, user must stop slaves and/or kill dump threads to make
the RESET MASTER go through. A slave that connects in the middle of RESET
MASTER will wait for it to complete.

Fix a lot of test cases to kill any lingering dump threads before doing
RESET MASTER, mostly just by sourcing include/kill_binlog_dump_threads.inc.

Signed-off-by: Kristian Nielsen <knielsen@knielsen-hq.org>
2025-06-11 11:32:10 +02:00

85 lines
2.2 KiB
Text

include/master-slave.inc
[connection master]
CALL mtr.add_suppression("Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT");
create table t1 (word char(20) not null);
load data infile '../../std_data/words.dat' into table t1;
load data local infile 'MYSQL_TEST_DIR/std_data/words.dat' into table t1;
select * from t1 limit 10;
word
Aarhus
Aaron
Ababa
aback
abaft
abandon
abandoned
abandoning
abandonment
abandons
connection slave;
stop slave;
connection master;
create temporary table tmp select * from mysql.global_priv where host="localhost" and user="root";
set password for root@"localhost" = password('foo');
connection slave;
start slave;
connection master;
replace into mysql.global_priv select * from tmp;
Warnings:
Note 1592 Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT. REPLACE... SELECT is unsafe because the order in which rows are retrieved by the SELECT determines which (if any) rows are replaced. This order cannot be predicted and may differ on master and the slave
drop temporary table tmp;
flush privileges;
create table t3(n int);
insert into t3 values(1),(2);
connection slave;
select * from t3;
n
1
2
select sum(length(word)) from t1;
sum(length(word))
1022
connection master;
drop table t1,t3;
connection slave;
connection master;
create table t1 (n int);
connection slave;
stop slave;
connection master;
include/kill_binlog_dump_threads.inc
reset master;
connection slave;
include/reset_slave.inc
connection master;
connection slave;
lock tables t1 read;
start slave;
connection master;
include/sync_slave_io_with_master.inc
unlock tables;
connection master;
create table t2(id int);
insert into t2 values(connection_id());
connection master1;
create temporary table t3(n int);
insert into t3 select get_lock('crash_lock%20C', 1) from t2;
connection master;
update t1 set n = n + get_lock('crash_lock%20C', 2);
connection master1;
select (@id := id) - id from t2;
(@id := id) - id
0
kill @id;
drop table t2;
drop temporary table t3;
connection master;
Got one of the listed errors
connection slave;
include/wait_for_slave_sql_error_and_skip.inc [errno=1927]
select count(*) from t1;
count(*)
5000
connection master1;
drop table t1;
include/rpl_end.inc