MySQL Bugs: #198: Replication between a 4.0.12 master and 3.23.52 slave does not work

Bug #198	Replication between a 4.0.12 master and 3.23.52 slave does not work
Submitted:	27 Mar 2003 6:31	Modified:	21 Jun 2003 7:31
Reporter:	Guilhem Bichot	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S3 (Non-critical)
Version:	3.23, 4.0	OS:	Any (all)
Assigned to:	Guilhem Bichot	CPU Architecture:	Any

Description:
Log_file displayed by SHOW SLAVE STATUS does not change, and master's queries are not played on the slave.

How to repeat:
set up a 4.0 master and 3.23 slave, do SLAVE START, do a query on the master (e.g. CREATE TABLE).
Do SHOW SLAVE STATUS :
the position is correct but the log_file is not (is empty in most cases).
And the table has not been created on the slave.

Suggested fix:
Don't want to fix yet.
4.0->4.0 and 3.23->3.23 works.
Here there seems to be 2 bugs :
Rotate_log_event format changed between 3.23 and 4.0, so the 4.0 master sends
(with fake_rotate_event) a Rotate which the slave badly parses (as header sizes
have been changed), so the slave ends up with
(gdb) print mi->log_file_name
$8 = "\000\000\000\000\000\000\004\000\000\000\000\000\000\000gbichot-bin.001", '\000' <repeats 482 times>
instead of gbichot-bin.001. The leading '\0' makes SHOW SLAVE STATUS print an
empty string.
Second problem is every query read from the master is considered as SQLCOM_EMPTY_QUERY (I don't know why).

Here the customer wants to upgrade soon to 4.0, so it is probably ok (I asked him if it was) to not fix it.

By the way, it is documented in the manual that 3.23
cannot replicate 4.0.

Thank you for your bug report. This issue has been fixed in the latest
development tree for that product. You can find more information about
accessing our development trees at 
    http://www.mysql.com/doc/en/Installing_source_tree.html

3.23.58 slaves will detect the problem and print an error.
If the master is 4.0.x with x<14, the slave may not immediately detect the problem if he has asked for a binlog position >4 (then the slave will detect the problem when the master sends the next binlog). If the master is 4.0.14 or newer, the slave will always detect the problem as soon as replication starts.