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:
Category:MySQL Server: Replication Severity:S3 (Non-critical)
Version:3.23, 4.0 OS:Any (all)
Assigned to: Guilhem Bichot CPU Architecture:Any

[27 Mar 2003 6:31] Guilhem Bichot
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).
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).
[27 Mar 2003 6:32] Guilhem Bichot
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.
[27 Mar 2003 7:07] Guilhem Bichot
By the way, it is documented in the manual that 3.23
cannot replicate 4.0.
[21 Jun 2003 7:31] Guilhem Bichot
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 

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.