MySQL Bugs: #51202: Confusing information on Master binary log position

Bug #51202	Confusing information on Master binary log position
Submitted:	16 Feb 2010 2:42	Modified:	5 Mar 2010 7:52
Reporter:	Peter Zaitsev (Basic Quality Contributor)	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Server: InnoDB storage engine	Severity:	S3 (Non-critical)
Version:	5.1.41, 5.1.43	OS:	Any
Assigned to:	Assigned Account	CPU Architecture:	Any
Tags:	qc

Description:
On recovery we can gert something like:

InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 115, file name portland-bin.001717
InnoDB: Last MySQL binlog file position 0 589600615, file name ./galax-bin.001376

However the Slave's Master Bin log file is not updated in this version so it just prints whatever junk is in the database.

How to repeat:
Upgrade MySQL 5.0 slave to 5.1 when crash it and enjoy.
Or you can take a look at the code :)

Suggested fix:
Remove the message if it was decided not to maintain slave position any more.

Thank you for the report.

Verified as described:

100216  8:34:08  InnoDB: Database was not shut down normally!
InnoDB: Starting crash recovery.
InnoDB: Reading tablespace information from the .ibd files...
InnoDB: Restoring possible half-written data pages from the doublewrite
InnoDB: buffer...
InnoDB: Last MySQL binlog file position 0 39760, file name .%2

This can be verified just as described.

1. Start 5.0->5.0 replication
2. Stop it
3. Upgrade slave to 5.1
4. Start replication again
5. Crash slave
6. See misleading message:

InnoDB: In a MySQL replication slave the last master binlog file
InnoDB: position 0 5084, file name mysql-bin.000001
InnoDB: Last MySQL binlog file position 0 39836, file name ./mysql-bin.000008

Regarding to bug #34058 I think this is different: bug #34058 about wrong position while this bug is about message which are not useful anymore.

I'm experiencing this same problem on  5.1.40sp1-enterprise-gpl-advanced-log. 

Having invalid  "last master binlog" information is a huge problem us and is holding up our adoption of 5.1 since it makes it impossible for us to recover a slave server using an innodb hotbackup taken from our master server.

Please restore this functionality, we've grown quite dependent on it.