1
0
mirror of https://github.com/MariaDB/server.git synced 2025-07-30 16:24:05 +03:00

Scrum task 845. Thi is a behaviour change :

now by default, FLUSH, OPTIMIZE, ANALYZE, REPAIR commands are written to the
binlog, unless the new NO_WRITE_TO_BINLOG keyword was used :
OPTIMIZE NO_WRITE_TO_BINLOG table t;

Previously these commands were never written to the binlog, but there are
2 reasons to change this :
- the RENAME TABLE in MERGE table bug (#175) on slave
- the possible "differently optimised queries may lead to different
updates on the master and slave" bug, until we have automatic ORDER BY.

FLUSH LOGS/SLAVE/MASTER/TABLES WITH READ LOCK are never written to the binlog.
New test for the new logging behaviour.
Other small change : reload_acl_and_cache() and reset_slave() don't send their errors themselves,
this is more usual.
This commit is contained in:
guilhem@mysql.com
2003-05-15 18:35:39 +02:00
parent da0e28b7d6
commit 4a0e006230
10 changed files with 204 additions and 46 deletions

View File

@ -0,0 +1,33 @@
#
# Test of replicating FLUSH TABLES to make
# RENAME TABLE work with MERGE tables on the slave.
# Test of FLUSH NO_WRITE_TO_BINLOG by the way.
#
source include/master-slave.inc;
create table t1 (a int);
insert into t1 values (10);
create table t2 (a int);
create table t3 (a int) type=merge union(t1);
create table t4 (a int);
# We force the slave to open t3 (because we want to try confusing him) with this :
insert into t4 select * from t3;
rename table t1 to t5, t2 to t1;
# RENAME may have confused the master (this is a known bug): so FLUSH tables,
# first don't write it to the binlog, to test the NO_WRITE_TO_BINLOG keyword.
flush no_write_to_binlog tables;
# Check that it's not in the binlog.
show binlog events;
# Check that the master is not confused.
select * from t3;
# This FLUSH should go into the binlog to not confuse the slave.
flush tables;
# Check that it's in the binlog.
show binlog events;
save_master_pos;
connection slave;
sync_with_master;
# Check that the slave is not confused.
select * from t3;
# Note that all this confusion may cause warnings 'table xx is open on rename'
# in the .err files; these are not fatal and are not reported by mysql-test-run.