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:

• Continue to use the binary log positioning (not GTID) to read data from the Master
• Ignore all GTID events in MariaDB

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.

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.

Replication from MySQL 5.6 -> MySQL 10.0 should now work.
MariaDB will remove MySQL 5.6 GTID and MySQL Ignorable events and add the MariaDB GTID.

I have tried this without success on a MySQL 5.6.21 master and MariaDB 10.0.22 slave when GTID is enabled on the master. The error is:

Last_IO_Error: The slave I/O thread stops because master does not support MariaDB global transaction id. A fatal error is encountered when it tries to SELECT @@GLOBAL.gtid_domain_id. Error: Unknown system variable 'gtid_domain_id'

Is there a way to have MariaDB ignore the domain id?

ryno@ryno.tv the problem here is that MariaDB is asking MySQL for the gtid_domain_id.

It appears that you have MariaDB in GTID replication mode. MariaDB and MySQL have different GTID implementations, and that these are not compatible with each other. As such MariaDB cannot replicate from a MySQL master in GTID mode. CHANGE MASTER TO MASTER_USE_GTID=no; START SLAVE; will clear the error.

@Daniel Black My impression from the MariaDB website was that this should work beginning with 10.0.22.

https://mariadb.com/kb/en/mariadb/setting-up-replication/
*Replicating from MySQL master to MariaDB slave
*Replicating from MySQL 5.5 to MariaDB 5.5+ should just work.
Replicating from MySQL 5.6 without GTID to MariaDB 10+ should work.
Replication from MySQL 5.6 with GTID, binlog_rows_query_log_events and ignorable events works starting from MariaDB 10.0.22 and MariaDB 10.1.8. In this case MariaDB will remove the MySQL GTIDs and other unneeded events and instead adds its own GTIDs.

Thanks,
Ryan

ryno@ryno.tv,
This note refers to MySQL 5.6 with GTID, not to Replication with GTID. That is, when GTID is enabled on the MySQL 5.6 master, you can now use MariaDB 10.0 as a slave.

Using MASTER_USE_GTID with a master which does not support MariaDB GTIDs, be it MySQL (of any version), or MariaDB 5.5 or lower, is not supported.
Getting a failure when you explicitly set MASTER_USE_GTID on the slave and connect to a master which does not support it is a right thing to do – it's impossible to use GTID for such replication, and if the slave did not fail, the user would have an illusion that GTID is in use. This failure does not cause any damage, and this configuration would not bring any advantage – you just need to unset it as Daniel wrote above.

Understood. Thank you for such a quick response.