Any MySQL 4.1.x version is identical to MySQL 4.0.3 (and newer 4.0) as far as replication is concerned (same binary log format). So replication between 4.0.3 (and newer 4.0) and any 4.1.x (whatever of the two is the master or slave) is working seamlessly.
Binary log format was changed between MySQL 3.23 and MySQL 4.0, and between MySQL 4.0 (or 4.1, as it's the same binary log format) and MySQL 5.0. This has consequences on how to upgrade a replication setup, which is explained below.
The following table indicates master/slave replication compatibility between different versions of MySQL.
Master | Master | Master | ||
3.23.33 and up | 4.0.3 and up or any 4.1.x | 5.0.0 | ||
Slave | 3.23.33 and up | yes | no | no |
Slave | 4.0.3 and up | yes | yes | no |
Slave | 5.0.0 | yes | yes | yes |
Versions 4.0.0, 4.0.1 and 4.0.2 were very early development versions which should not be used anymore (their compatibility is still documented in the manual included in these versions' distributions).
As a general rule, it's always recommended to use recent MySQL versions, because replication capabilities are continually being improved. We recommend using same version for both the master and the slave.
Upgrading from 3.23 to 4.0 (4.0.3 or newer) or any 4.1.x |
When you upgrade a master from MySQL 3.23 to MySQL 4.0 (or
4.1), you should first ensure that all the slaves of this master are
already 4.0 or 4.1 (if that's not the case, you should first upgrade
your slaves as explained a few lines below).
Once the master is upgraded, you should not restart replication
using old 3.23 binary logs, because this will unfortunately confuse the
4.0 or 4.1 slave. The upgrade
can safely be done this way, assuming you have a 3.23 master to upgrade
and you have 4.0 or 4.1 slaves:
|
Upgrading from 3.23 or 4.0 (4.0.3 or newer) or any 4.1.x to 5.0.0 | First, note that MySQL 5.0.0 is alpha; even if it is supposed to work better than older versions (easier upgrade, replication of some important session variables like sql_mode; see News-5.0.0), it has not been tested a lot yet so, as with any alpha release, we recommend you do not use in critical production environment yet. When you upgrade a master from MySQL 3.23 or 4.0 or 4.1 to 5.0.0, you should first ensure that all the slaves of this master are already 5.0.0 (if that's not the case, you should first upgrade your slaves as explained a few lines below). Then just shut down your master, upgrade it to 5.0.0 and restart it. The 5.0.0 master will be able to read the old binary logs (of before the master upgrade) and to send them to the 5.0.0 slaves which will recognize this old format and handle it. Binary logs created after the master upgrade will be in 5.0.0 format and be recognized by 5.0.0 slaves too. To upgrade the slaves, just shut them down, upgrade them to 5.0.0, and restart them (and restart replication). The 5.0.0 slaves will be able to read the old relay logs (of before the slave upgrade) and execute the statements they contain. Relay logs created after the slave upgrade will be in 5.0.0 format. In other words, there are no measures to take when upgrading to 5.0.0, except that slaves must be 5.0.0 to be able to upgrade the master to 5.0.0. Note that downgrading from 5.0.0 to older versions does not work as automatically; you will have to remove any 5.0.0 binary logs or relay logs before proceeding. |