mariadb/mysql-test/t/rpl_dual_pos_advance.test
unknown b7cdb978d9 Bug #28597 Replication doesn't start after upgrading to 5.1.18
Since bug@20166, which replaced the binlog file name generating to base
on pidfile_name instead of the previous glob_hostname, the binlog file
name suddenly started to be stored solely in the absolute path format,
including a case when --log-bin option meant a relative path.
What's more serious, the path for binlog file can lead unrequestedly 
to pid-file directory so that after any proper fix for this bug
there might be similar to the bug report consequences for one who
upgrades from post-fix-bug@20166-pre-fix-bug@28597 to post-fix-bug@28597.

Fixed with preserving`pidfile_name' (intr.by bug@20166) but stripping
off its directory part. This restores the original logics of storing
the names in compatible with --log-bin option format and with the
requirement for --log-bin ralative path to corresond to the data directory.
Side effects for this fix:

effective fixing bug@27070, refining its test;
ensuring no overrun for buff can happen anymore (Bug#31836 
insufficient space reserved for the suffix of relay log file name);
bug#31837  --remove_file $MYSQLTEST_VARDIR/tmp/bug14157.sql missed
in rpl_temporary.test;
fixes Bug@28603  Invalid log-bin default location;


mysql-test/t/rpl_dual_pos_advance.test:
  After correcting the logics of log file name composing workaround for
  
    Bug #27070 server logs are created unrequested and in wrong directory
  
  is removed.
mysql-test/t/rpl_temporary.test:
  remaining temp file of the test removed
sql/log.cc:
  stripping off the directory part of `pidfile_name' for binlog name
  generating (which fixes two more bugs on wrong binlog file location);
  ensuring no overrun for buff can happen anymore (Bug #31836 
  insufficient space reserved for the suffix of relay log file name);
2007-11-05 17:20:10 +02:00

108 lines
2.1 KiB
Text

# This test checks that in a dual-head setup
# A->B->A, where A has --log-slave-updates (why would it?
# assume that there is a C as slave of A),
# then the Exec_master_log_pos of SHOW SLAVE STATUS does
# not stay too low on B(BUG#13023 due to events ignored because
# of their server id).
# It also will test BUG#13861.
source include/master-slave.inc;
# set up "dual head"
connection slave;
reset master;
connection master;
--replace_result $SLAVE_MYPORT SLAVE_PORT
eval change master to master_host="127.0.0.1",master_port=$SLAVE_MYPORT,master_user="root";
start slave;
# now we test it
connection slave;
create table t1 (n int);
save_master_pos;
connection master;
sync_with_master;
# Now test BUG#13861. This will be enabled when Guilhem fixes this
# bug.
# stop slave
# create table t2 (n int); # create one ignored event
# save_master_pos;
# connection slave;
# sync_with_master;
# connection slave;
# show tables;
# save_master_pos;
# create table t3 (n int);
# connection master;
# bug is that START SLAVE UNTIL may stop too late, we test that by
# asking it to stop before creation of t3.
# start slave until master_log_file="slave-bin.000001",master_log_pos=195;
# wait until it's started (the position below is the start of "CREATE
# TABLE t2") (otherwise wait_for_slave_to_stop may return at once)
# select master_pos_wait("slave-bin.000001",137);
# wait_for_slave_to_stop;
# then BUG#13861 causes t3 to show up below (because stopped too
# late).
# show tables;
# start slave;
# BUG#13023 is that Exec_master_log_pos may stay too low "forever":
connection master;
create table t4 (n int); # create 3 ignored events
create table t5 (n int);
create table t6 (n int);
save_master_pos;
connection slave;
sync_with_master;
connection slave;
save_master_pos;
connection master;
# then BUG#13023 caused hang below ("master" looks behind, while it's
# not in terms of updates done).
sync_with_master;
show tables;
# cleanup
stop slave;
reset slave;
drop table t1,t4,t5,t6; # add t2 and t3 later
save_master_pos;
connection slave;
sync_with_master;
# End of 4.1 tests