- Documentation Library
- Table of Contents
- MySQL 5.5 Manual
- MySQL 5.4 Manual
- MySQL 5.1 Manual
- MySQL 5.0 Manual
- MySQL 3.23/4.0/4.1 Manual
- Table of Contents
- 14 Replication
- 14.1 Introduction to Replication
- 14.2 Replication Implementation Overview
- 14.3 Replication Implementation Details
- 14.4 How to Set Up Replication
- 14.5 Replication Compatibility Between MySQL Versions
- 14.6 Upgrading a Replication Setup
- 14.7 Replication Features and Known Problems
- 14.8 Replication and Binary Logging Options and Variables
- 14.9 How Servers Evaluate Replication Filtering Rules
- 14.10 Replication FAQ
- 14.11 Troubleshooting Replication
- 14.12 How to Report Replication Bugs or Problems
MySQL supports replication from one major version to the next higher major version. For example, you can replicate from a master running MySQL 4.0 to a slave running MySQL 4.1, from a master running MySQL 4.1 to a slave running MySQL 5.0, and so on.
Note
The original binary log format was developed in MySQL 3.23. It was changed in MySQL 4.0.
You cannot replicate from a master that uses a newer binary log format to a slave that uses an older format — for example, from MySQL 4.1 to MySQL 3.23. (In general, MySQL does not support replication from newer masters to older slaves.) This also has significant consequences for upgrading servers in a replication setup, as described in Section 14.6, “Upgrading a Replication Setup”.
As far as replication is concerned, the binary log format used by all MySQL 4.0 and MySQL 4.1 releases is identical. However, replication from a 4.1 master to a 4.0 slave is unsupported; it has not been tested thoroughly, and no further development or bug fixing is planned for this master/slave combination. Although the binary log format is the same for 4.0 and 4.1, there are other constraints, such as SQL-level compatibility issues. For example, a 4.1 master cannot replicate to a 4.0 slave if the replicated statements use SQL features available in 4.1 but not 4.0.
In some cases, it is also possible to replicate between a master and a slave that is more than one major version newer than the master. However, there are known issues with trying to replicate from a master running MySQL 4.1 or earlier to a slave running MySQL 5.1 or later. To work around such problems, you can insert a MySQL server running an intermediate version between the two; for example, rather than replicating directly from a MySQL 4.1 master to a MySQL 5.1 slave, it is possible to replicate from a MySQL 4.1 server to a MySQL 5.0 server, and then from the MySQL 5.0 server to a MySQL 5.1 server.
Important
It is strongly recommended to use the most recent release available within a given MySQL major version because replication (and other) capabilities are continually being improved. It is also recommended to upgrade masters and slaves that use alpha or beta releases of a major version of MySQL to GA (production) releases when these become available for that major version.
For more information on potential replication issues, see Section 14.7, “Replication Features and Known Problems”.
User Comments
Please read carefully the paragraph about new password algorithm in chapter "Replication Features and Known Problems" - this leads also to problems with the "replication user" while setting up Master with version 4.1.x and Slave with version 4.0.x - solutions can be found at section "A.2.3 Client does not support authentication protocol".
An option that would help with binlog incompatibility between 4.1 and 5.1 or 5.1 to 4.1 would be to use mysqlbinlog on the master and apply to the slave. I plan on only using this briefly during upgrades.
Add your own comment.