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

    XMLWordPrintable

Details

    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

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

              Dates

                Created:
                Updated:
                Resolved:

                Git Integration

                  Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.