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

[27 Mar 2003 6:31] Guilhem Bichot 
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).
[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 
    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.