Bug #57771 Master losing track of binary log file after configuration change

Description:
Changing the log-bin directory in the configuration file on the master causes the slave to stop with a "Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'".

The master appears to lose where the file is, even though the bin-log.index has the correct file and path of the previous configuration setting.

There is no error message logged on the master that it could not find the file either.

How to repeat:
Set your master configuration file to put files in the datadir (not needed but we'll use that for a path):
log-bin=/extra/51master/log-bin

Shut down the master the slave will stop with the following error "Last_IO_Error: error reconnecting to master 'root@localhost:3306' - retry-time: 60  retries: 86400"

Set your master configuration file to put files in the datadir:
log-bin=log-bin

Restart the master.

Start the slave threads with a 'START SLAVE;'.

The slave stops with the "Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file'".

The change in the master binary log of the bin-log location has caused the master to lose track of where to find it. But the file is correctly named in the bin-log.index.

[root@localhost 51master]# more log-bin.index 
/extra/51master/log-bin.000013    <--- can't find this one anymore
./log-bin.000014

Suggested fix:
The master should be able to find the correct file, irregardless of a change in the master configuration file. The file hasn't moved and the location is correct in the bin-log.index file. That would allow the slave to continue as well.

If the file has actually been deleted or can't be found, there should be an error in the master log file that it cannot serve the slave or find the log file.

Workaround:

Shut down the master server and edit the bin-log.index file to all have the same 'new' path, in our case all of the file are in the same location.

[root@localhost 51master]# more log-bin.index 
./log-bin.000013    <--- finds the file now
./log-bin.000014

See also: BUG#12133.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/128828

3507 Luis Soares	2011-01-14
      BUG#57771: Master losing track of binary log file after 
      configuration change
      
      Sketch of a test case.

Using the above test case and testing it against current
mysql-trunk:

  - tree: mysql-trunk
  - revid: sven.sandberg@oracle.com-20110114104020-j0l7jpwzegs3d401
  - OS: Ubuntu linux

I get the following result:

include/master-slave.inc
[connection master]
/home/lsoares/Workspace/bzr/work/reviews/b12133/mysql-trunk-vanilla/mysql-test/var
/home/lsoares/Workspace/bzr/work/reviews/b12133/mysql-trunk-vanilla/mysql-test/var/mysqld.1/data/mysqld-bin.000001
# Shutdown master
# Restart master with log-bin option set to the new path
/home/lsoares/Workspace/bzr/work/reviews/b12133/mysql-trunk-vanilla/mysql-test/var/mysqld.1/data/mysqld-bin.000001
./mysqld-bin.000002
CREATE TABLE t1 (a INT);
DROP TABLE t1;
STOP SLAVE;
include/wait_for_slave_to_stop.inc
START SLAVE;
Last_IO_Errno = '1236'
Last_IO_Error = '110114 20:03:18 Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file''

Note that I get the same error as Roger did.

Now, trying the same test case against a mysql-trunk patched with
BUG#12133 proposed patch, I get:

include/master-slave.inc
[connection master]
/home/lsoares/Workspace/bzr/work/reviews/b12133/mysql-trunk/mysql-test/var
mysqld-bin.000001
# Shutdown master
# Restart master with log-bin option set to the new path
mysqld-bin.000001
mysqld-bin.000002
CREATE TABLE t1 (a INT);
DROP TABLE t1;
STOP SLAVE;
include/wait_for_slave_to_stop.inc
START SLAVE;
Last_IO_Errno = '0'
Last_IO_Error = ''
include/check_slave_no_error.inc
include/check_slave_is_running.inc
rpl.rpl_bug57771 'stmt'                  [ pass ]   5714

Therefore, seems that patch for BUG#12133 fixes this one as well.

Duplicate of BUG#12133