Chapter 54. Upgrading a Replication Setup - Mixing Different MySQL Versions

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.

  MasterMasterMaster
  3.23.33 and up4.0.3 and up or any 4.1.x5.0.0
Slave3.23.33 and upyesnono
Slave4.0.3 and upyesyesno
Slave5.0.0yesyesyes

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:
  1. Block all updates on the master (FLUSH TABLES WITH READ LOCK).

  2. Wait until all the slaves have caught up all changes from the master (use SHOW MASTER STATUS on the master, and SELECT MASTER_POS_WAIT() on the slaves). Then run STOP SLAVE on the slaves.

  3. Shut down MySQL on the master and upgrade the master to MySQL 4.0 or 4.1.

  4. Restart MySQL on the master. Record the name <name> of the master's newly created binary log. You can obtain the name of the file by issuing SHOW MASTER STATUS on the master. Then issue these commands on each slave:

    mysql> CHANGE MASTER TO MASTER_LOG_FILE='<name>', MASTER_LOG_POS=4;
    mysql> START SLAVE;
    

If you also must upgrade your slaves from 3.23 to 4.0 or 4.1, you should first upgrade your slaves: shut down each one, upgrade it, and restart it. Then upgrade the master as just described.
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.