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: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Fix Version/s: 10.0.22, 10.1.8
    • Component/s: Replication
    • 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.

        Attachments

          Issue Links

            Activity

              People

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

                Dates

                • Created:
                  Updated:
                  Resolved:

                  Time Tracking

                  Estimated:
                  Original Estimate - Not Specified
                  Not Specified
                  Remaining:
                  Remaining Estimate - 0 minutes
                  0m
                  Logged:
                  Time Spent - 2 days
                  2d