Details
-
Type:
Task
-
Status: Open
-
Priority:
Minor
-
Resolution: Unresolved
-
Fix Version/s: 10.0
-
Component/s: None
-
Labels:None
Description
Currently if MySQL 5.6 is running with GTID enabled, replication to MariaDB does not work, it breaks on the first GTID-related event (e.g. 'Previous_gtids' or 'Gtid') with
Relay log read failure: Could not parse relay log event entry. The possible reasons are: the master's binary log is corrupted (you can check this by running 'mysqlbinlog' on the binary log), the slave's relay log is corrupted (you can check this by running 'mysqlbinlog' on the relay log), a network problem, or a bug in the master's or slave's MySQL code. If you want to check the master's binary log or slave's relay log, you will be able to know their names by issuing 'SHOW SLAVE STATUS' on this slave.
If it's at all possible, I think it's fairly important to be able to replicate from MySQL 5.6 with GTID to MariaDB, as one of reasonable migration scenarios is that a production has the main pair of MySQL 5.6 master and slave (using GTID), and a second MariaDB slave is running in parallel.
Of course it would be old-style replication, not using MariaDB GTID.
That said, replication from MySQL 5.6 GTID to MySQL 5.6 without GTID does not work either (it fails with "The slave IO thread stops because the master has @@GLOBAL.GTID_MODE ON and this server has @@GLOBAL.GTID_MODE OFF"), so maybe it's impossible.
Gliffy Diagrams
Attachments
Issue Links
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
If you want heterogeneous replication, you should look at Tungsten Replicator.
Mixing MariaDB 10 and MySQL 5.6/5.7 GTID replication streams would be a very bad idea. The whole point behind GTID is to make managed failovers, or slave promotion (in an emergency) easier. MariaDB and MySQL both have their own good solutions to this problem, but they don't have to be 100% compatible with each other. As Monty said, if you want a mixed environment, use the legacy format of log file + position. This is excluding all the other issues which arise as MySQL and MariaDB introduce their own features, which appear as differently formatted events in the binary log stream, i.e. checksums.
If your application relies on mixed RDBMS for high-availability for a single RDBMS type, something is very wrong.
> If your application relies on mixed RDBMS for high-availability for a single RDBMS type, something is very wrong.
This is not wrong, this is exactly how high availability works. If one wants to upgrade from MySQL 5.6 to MariaDB 10.0 or back he must tolerate mixed environment for some time (at least for several days). That's why GTIDs in 5.6 are fundamentally broken – they don't support mixed environment (when some replicas have GTIDs turned on and some don't).
Now how to manage reliable failovers in such mixed environment is a separate question, but at least replication itself should work.
We think it's important that one can add MariaDB as a slave to a MySQL 5.6 with GTID enabled.
The way we will do it is as follows:
If you are enabling GTID on MariaDB, any slave to that will be able to use GTID.
This means that if one wants to replace a MySQL 5.6 slave with GTID with MariaDB, one has to find out the current log position with SHOW MASTER STATUS before one can enable the MariaDB slave.