Skip navigation links
MySQL 5.4 Reference Manual :: 16 Replication :: 16.4 Replication Notes and Tips :: 16.4.2 Replication Compatibility Between MySQL Versions
16.4.3 Upgrading a Replication Setup »
Section Navigation      [Toggle]

16.4.2. Replication Compatibility Between MySQL Versions

MySQL supports replication from one major version to the next higher major version. For example, you can replicate from a master running MySQL 4.1 to a slave running MySQL 5.0, from a master running MySQL 5.0 to a slave running MySQL 5.1, and so on.

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 early releases of a major version of MySQL to GA (production) releases when the latter become available for that major version.

Replication from newer masters to older slaves may be possible, but is generally not supported. This is due to a number of factors:

  • Binary log format changes.  The binary log format can change between major releases. While we attempt to maintain backward compatibility, this is not always possible. For example, the binary log format implemented in MySQL 5.0 changed considerably from that used in previous versions, especially with regard to handling of character sets, LOAD DATA INFILE, and time zones. This means that replication from a MySQL 5.0 (or later) master to a MySQL 4.1 (or earlier) slave is generally not supported.

    This also has significant implications for upgrading replication servers; see Section 16.4.3, “Upgrading a Replication Setup”, for more information.

  • Use of row-based replication.  Row-based replication was implemented in MySQL 5.1.5, so you cannot replicate using row-based replication from any MySQL 5.4 or later master to a slave older than MySQL 5.1.5.

    For more information about row-based replication, see Section 16.1.2, “Replication Formats”.

  • SQL incompatiblities.  You cannot replicate from a newer master to an older slave using statement-based replication if the statements to be replicated use SQL features available on the master but not on the slave.

    However, if both the master and the slave support row-based replication, and there are no data definition statements to be replicated that depend on SQL features found on the master but not on the slave, you can use row-based replication to replicate the effects of data modification statements even if the DDL run on the master is not supported on the slave.

For more information on potential replication issues, see Section 16.4.1, “Replication Features and Issues”.


User Comments

Posted by [name withheld] on November 24 2004 12:35pm[Delete] [Edit]

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".

Posted by David Turner on May 26 2009 3:19pm[Delete] [Edit]

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.