MySQL Bugs: #83299: 5.7 broke replica - Could not find first log file name in binary log index file

Bug #83299	5.7 broke replica - Could not find first log file name in binary log index file
Submitted:	7 Oct 2016 10:14	Modified:	11 Nov 2016 9:04
Reporter:	Steven Hartland	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:	5.7.15	OS:	Any
Assigned to:		CPU Architecture:	Any

Description:
After upgrading from mysql 5.6.30 to 5.7.15 replication stopped working.

The slave was reporting the following errors:

2016-10-07T09:52:37.374423Z 7 [ERROR] Error reading packet from server for channel '': Could not find first log file name in binary log index file (server_errno=1236)
2016-10-07T09:52:37.374440Z 7 [ERROR] Slave I/O for channel '': Got fatal error 1236 from master when reading data from binary log: 'Could not find first log file name in binary log index file', Error_code: 1236

Looking at the master.info file on the master it appears that the filename format changed from fully qualified to relative e.g.
/data/mysql/main/mysql-bin.023967
/data/mysql/main/mysql-bin.023968
./mysql-bin.023969
./mysql-bin.023970
./mysql-bin.023971

In the end we fixed this my editing master.info using:
perl -p -i -e 's|/data/mysql/main|\.|' mysql-bin.index

Followed by:
flush logs;

During this process ensure that the server is either stopped or isn't close to writing to master.info.

How to repeat:
Upgrade from 5.6.30 to 5.7.15
slave start;

Suggested fix:
Either don't change the pathing structure of master.info or ensure its properly upgraded.

Hello Steven,

Thank you for the report.
Could you please tell us whether you've upgraded slave, master first? Also, please could you upload both the conf files, unaltered error logs from master/slave to check further? In general, when you upgrade a master to 5.7 from an earlier MySQL release series, you should first ensure that all the slaves of this master are using the same 5.7.x release. If this is not the case, you should first upgrade the slaves.

Thanks,
Umesh

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Sorry never got the email to say there was a question waiting.

Yes the slave was upgraded prior to the slave, however the cause of the issue was actually a bug in the FreeBSD port / package which documented the move of the configuration file incorrectly so it wasn't using the my.cnf everyone thought it was.

This resulted in the changes in format of mysql-bin.index and hence the temporary failure of the replication.