MySQL manual version 5.0.20-mysql sync (iii)

Mysql

6.5 synchronization compatibility between different versions of MySQL

The earliest binary format was developed in MySQL 3.23. Improved in MySQL 4.0, and MySQL 5.0 improved. The causal relationship between a server that needs to be upgraded while configuring synchronization is described in "6.6 Upgrading a Replication Setup."

If you only care about synchronization, any MySQL 4.1.x version is the same as MySQL 4.0.x, because they all use binary logs in the same format. So, these versions are compatible with each other, and they can run synchronously seamlessly. One exception is that MySQL 4.0.0 to 4.0.2 because it was developed earlier and could not be compatible with later versions, so do not use them (they are the 4.0 version of the Alpha series.) The compatibility between them is documented in the publication of the package's manual.

The following table shows the Master/slave synchronization 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

A common rule is that we recommend using the latest version of MySQL because synchronization compatibility has been improving. We also recommend that both master and slave use the same version.

6.6 Upgrade Sync

When upgrading a server involves configuring synchronization, the steps to upgrade the settings differ from the current version and the upgraded version.

6.6.1 upgrade sync to 4.0 or 4.1

This section applies to upgrades from MySQL 3.23 to 4.0 or 4.1. 4.0 of servers must be 4.0.3 or higher, "6.5 Replication compatibility Between MySQL versions" mentioned.

When you upgrade master from MySQL 3.23 to 4.0 or 4.1, you first have to make sure that all of this master's slave are already 4.0 or 4.1, otherwise you have to upgrade slave: Turn off, upgrade, reboot, reboot, Sync, and so on.

You can safely upgrade with the following steps, assuming master is upgrading to 3.23, and slave is already 4.0 or 4.1. Note that after master upgrades, do not restart synchronization using any old binary logs because it interferes with the synchronization of 4.0 or 4.1 slave.

Executes the FLUSH TABLES with READ LOCK statement on Master to block all updates.

Wait until all the slave are up to master's data update. Execute the Show Master STATUS statement on MASTER to get the binary log and offset location. Then, slave the SELECT master_pos_wait () statement with these values, it blocks synchronization on the slave and returns the offset where it has been synchronized. Then execute the STOP SLAVE statement on the SLAVE.

Close Master and upgrade it to MySQL 4.0 or 4.1.

Restart Master and make a note of its new binary file name. The show Master STATUS statement can be executed on master to obtain this information. The following statement is then executed on each slave:

mysql> change MASTER to master_log_file= ' Binary_log_name ',

-> master_log_pos=4;

Mysql> START SLAVE;

6.6.2 Upgrade sync to 5.0

This section applies to upgrades from MySQL 3.23,4.0 or 4.1 to 5.0. 4.0 of servers must be 4.0.3 or higher, "6.5 Replication compatibility Between MySQL versions" mentioned.

First, take note of the MySQL 5.0 or Alpha release series. It's better than the old version in every way (it's easier to upgrade some important session variables in sync, such as Sql_mode; see "c.1.3 Changes in Release 5.0.0"). However, it has not been extensively tested. Since it is alpha, we do not recommend it for any production environment (now available for production, translator note).

The master from MySQL 3.23,4.0 or 4.1 upgrade to 5.0.0, the first to confirm that the master of all Slave are already 5.0.0, otherwise, to upgrade first slave: one by one shutdown, upgrade, restart, restart synchronization. 5.0.0 slave can read the relay log of execution statements written before the upgrade. The relay log created after the upgrade slave is 5.0 format.

When all the slave have been upgraded, turn master off, upgrade to 5.0.0, and then reboot. The 5.0.0 master can also read binary logs in the old format. Slave can identify old formats and handle them properly. The new binary log on master is 5.0.0 format. Slave can also recognize this format.

In other words, there is no special requirement to upgrade to 5.0.0 unless slave must use an older version before upgrading master to 5.0.0. Note that demoting 5.0.0 to an older version cannot be done automatically: you must make sure that all of the 5.0.0 format binaries and relay logs are processed before they can be removed to complete the demotion.