Replication Compatibility Between MariaDB Versions
MySQL supports replication from one major version to the next higher major version. For example, you can replicate from a master running MariaDB to a slave running MariaDB 5.0, from a master running MariaDB 5.0 to a slave running MariaDB 5.1, and so on.
However, one may encounter difficulties when replicating from an older master to a newer slave if the master uses statements or relies on behavior no longer supported in the version of MariaDB used on the slave. For example, in MariaDB 5.5, CREATE TABLE ... SELECT statements are permitted to change tables other than the one being created, but are no longer allowed to do so in MariaDB 5.6 (see , "Replication of CREATE TABLE ... SELECT Statements").
The use of more than 2 MariaDB Server versions is not supported in replication setups involving multiple masters, regardless of the number of master or slave MariaDB servers. This restriction applies not only to major versions, but to minor versions within the same major version as well. For example, if you are using a chained or circular replication setup, you cannot use MariaDB 5.6.1, MariaDB 5.6.2, and MariaDB 5.6.4 concurrently, although you could use any 2 of these releases together.
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 MariaDB or earlier to a slave running MariaDB 5.1 or later. To work around such problems, you can insert a MariaDB server running an intermediate version between the two; for example, rather than replicating directly from a MariaDB master to a MariaDB 5.1 slave, it is possible to replicate from a MariaDB server to a MariaDB 5.0 server, and then from the MariaDB 5.0 server to a MariaDB 5.1 server.Important
It is strongly recommended to use the most recent release available within a given MariaDB 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 MariaDB 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 MariaDB 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 MariaDB 5.0 (or later) master to a MariaDB (or earlier) slave is generally not supported.
This also has significant implications for upgrading replication servers; see , "Upgrading a Replication Setup", for more information.
- Use of row-based replication. Row-based replication was implemented in MariaDB 5.1.5, so you cannot replicate using row-based replication from any MariaDB 5.6 or later master to a slave older than MariaDB 5.1.5.
For more information about row-based replication, see , "Replication Formats".
- SQL incompatibilities. 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 , "Replication Features and Issues".