Description:
mysqldump --first-slave or --master-data silently send RESET MASTER (FLUSH MASTER
in fact, which is an alias) to the master. So the master's binlogs silently get
deleted. Even if this is relatively safe, as we've just dumped the master's data
(provided we dumped all databases : mysqldump --master-data this_db is allowed!),
the user may strongly not want it. And anyway it is a bug as just before purging,
mysqldump prints CHANGE MASTER statements which contain the current binlog
coordinates, which become bogus as soon as RESET MASTER is completed.
When fed in the slave, these CHANGE MASTER will produce errors like :
030317 15:54:09 Slave I/O thread: connected to master 'root@localhost:3306', replication started in log 'gbichot-bin.001' at position 131
030317 15:54:09 Error reading packet from server: Client requested master to start replication from impossible position (server_errno=1236)
030317 15:54:09 Got fatal error 1236: 'Client requested master to start replication from impossible position' from master when reading data from binary log
030317 15:54:09 Slave I/O thread exiting, read up to log 'gbichot-bin.001', position 131
How to repeat:
1) I create a db on the master
create database test2;
show master status;
+-----------------+----------+--------------+------------------+
| File | Position | Binlog_do_db | Binlog_ignore_db |
+-----------------+----------+--------------+------------------+
| gbichot-bin.001 | 131 | | |
+-----------------+----------+--------------+------------------+
1 row in set (0.00 sec)
2) Then I do
mysqldump --master-data -uroot test2
-- MySQL dump 9.07
--
-- Host: localhost Database: test2
---------------------------------------------------------
-- Server version 4.0.12-debug-log
--
-- Position to start replication from
--
CHANGE MASTER TO MASTER_LOG_FILE='gbichot-bin.001' ;
CHANGE MASTER TO MASTER_LOG_POS=131 ;
3) then
show master status;
+-----------------+----------+--------------+------------------+
| File | Position | Binlog_do_db | Binlog_ignore_db |
+-----------------+----------+--------------+------------------+
| gbichot-bin.001 | 79 | | |
+-----------------+----------+--------------+------------------+
1 row in set (0.00 sec)
See how 131 became 79
Suggested fix:
simply remove this RESET MASTER, or better make it an option (off by default).
