MySQL Bugs: #1086: Wrong Exec_master_log_pos reported in A->B->C setup.

Bug #1086	Wrong Exec_master_log_pos reported in A->B->C setup.
Submitted:	18 Aug 2003 18:11	Modified:	20 Aug 2003 9:49
Reporter:	Dmitri Lenev
Status:	Closed
Category:	Server: Replication	Severity:	S2 (Serious)
Version:	4.0	OS:
Assigned to:	Dmitri Lenev	Target Version:

Description:
In the A->B->C replication set up Exec_master_log_pos on C doesn't give the position of
execution of its master (B) bin-log but the master's master (A).

This makes it hard to troubleshoot as you don't know where it's at in the binary log.

Documentation says that:

Exec_master_log_pos the position in the master's binlog (Relay_Master_Log_File) of the
last event executed by the SQL thread. ((Relay_Master_Log_File,Exec_master_log_pos) in the
master's binlog corresponds to (Relay_Log_File,Relay_Log_Pos) in the relay log).

And in this case this is not true.

How to repeat:
Set up A->B->C replication.(Don't forget to enable log-slave-updates on B)
Add binlog-do-db=test2 option for B because we need different bin-logs for A and B.
Now do some inserts with some table outside of test2 db on A. This inserts should not go
in B bin-log and thus to C. Now do some inserts for some table in test2 db on host A.
Now Exec_master_log_pos on C will have same value as Position in SHOW MASTER status on A
and not B as it should be.

Suggested fix:
Do not propagate log_pos of event from master to B own bin log. This probably as needed
for some repl_failsafe stuff that is broken anyway.

Thank you for your bug report. This issue has been committed to our
source repository of that product and will be incorporated into the
next release.

If necessary, you can access the source repository and build the latest
available version, including the bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

ChangeSet@1.1574.1.1, 2003-08-20 03:38:31+04:00, dlenev@mysql.com