Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-4487

FR: Allow replication from MySQL 5.6+ when GTID is enabled on the master

    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

          Issue Links

            Activity

            Hide
            monty Michael Widenius added a comment -

            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.

            Show
            monty Michael Widenius added a comment - 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.
            Hide
            mathnode Richard Bensley added a comment - - edited

            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.

            Show
            mathnode Richard Bensley added a comment - - edited 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.
            Hide
            pivanof Pavel Ivanov added a comment -

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

            Show
            pivanof Pavel Ivanov added a comment - > 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.

              People

              • Assignee:
                monty Michael Widenius
                Reporter:
                elenst Elena Stepanova
              • Votes:
                10 Vote for this issue
                Watchers:
                14 Start watching this issue

                Dates

                • Created:
                  Updated: