This section applies to upgrading replication from MySQL 3.23 to 4.0 or 4.1. A 4.0 server should be 4.0.3 or newer, as mentioned in Section 14.5, “Replication Compatibility Between MySQL Versions”.
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 at 4.0 or 4.1. If that is not the case, you should first upgrade your slaves: Shut down each one, upgrade it, restart it, and restart replication.
The upgrade can safely be done using the following procedure, assuming that you have a 3.23 master to upgrade and the slaves are 4.0 or 4.1. Note that after the master has been upgraded, you should not restart replication using any old 3.23 binary logs, because this unfortunately confuses the 4.0 or 4.1 slaves.
Block all updates on the master by issuing a
FLUSH TABLES WITH
READ LOCK
statement.
Wait until all the slaves have caught up with all changes
from the master server. Use SHOW MASTER
STATUS
on the master to obtain its current binary
log file and position. Then, for each slave, use those
values with a SELECT MASTER_POS_WAIT()
statement. The statement blocks on the slave and returns
when the slave has caught up. Then run
STOP SLAVE
on the slave.
Stop the master server and upgrade it to MySQL 4.0 or 4.1.
Restart the master server and record the name of its newly
created binary log. You can obtain the name of the file by
issuing a SHOW MASTER STATUS
statement on the master. Then issue these statements on each
slave:
mysql>CHANGE MASTER TO MASTER_LOG_FILE='binary_log_name',
->MASTER_LOG_POS=4;
mysql>START SLAVE;
User Comments
There is support for time zone since 4.1.3. For replication to work correctly for TIMESTAMP fields you will need to set default-time-zone to the same zone on master and slave (by default it is set to SYSTEM), particularly if system_time_zone are different for master and slave.
Add your own comment.