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

Replication 10.0 -> 5.5 fails

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Blocker
    • Resolution: Fixed
    • 10.0.0
    • 10.0.2
    • None
    • None

    Description

      Replication from 10.0 to 5.5 (or earlier versions, MariaDB and MySQL both)
      fails:

      "Master reported unrecognized MySQL version"

      The problem is that in 5.5 and below, there is code like this in the slave:

          switch (*mysql->server_version) {
          case '1':
            errmsg = "Master reported unrecognized MySQL version";

      This breaks on version "10.0".

      Agreed solution: we'll sent the version string in the handshake packet in the form of 5.5.30-mysql-10.0.2-MariaDB. The @@global.version variable and the VERSION() sql function will not be affected by this change.

      The rest of the issue follows, for reference purposes.

      Apparently this was discovered earlier, as the code in 10.0 is changed to look
      at the whole version number, not just the first digit. But this is completely
      broken, as we cannot change the code for earlier releases (it needs to be
      fixed on the new master, so it accomodates old slaves).

      It looks like we will either need to call 10.0 something else, or have the
      server lie about the version number.


      I investigated the code in a bit more detail. Unfortunately, it looks like we
      do not have too many options here, basically:

      1. Use 9.0 for the coming MariaDB version, instead of 10.0.

      2. Lie to all clients about our version number. Eg. send 5.5.50 or something
      like that.

      3. Not be able to replicate from MariaDB 10.0 master to MySQL slave at all.

      The option (3) seems unacceptable to me.

      Option (1) looks attractive to me. This might also help other (3rd party)
      applications, if they have regexps or something that cannot handle two-digit
      major version.

      Option (2) appears easy, but seems likely to cause a lot of confusion.

      Background: The version string in question is sent by the server in the very
      first packet to the client. First come 4 bytes of packet length, then one byte
      of protocol version, and then the version string.

      The slave replication code in MySQL checks the first character of the version
      string, and aborts if it is not a digit in the range [5-9]. (well, 3 and 4 are
      used for old binlog formats).

      The string is also used by clients to get the server version,
      eg. mysql_get_server_version().

      So there seems to be no way to implement a work-around for just old slaves. At
      the time when the server sends the string, we have no knowledge about who or
      what is connecting.

      So basically, unless we start the version string sent to all clients with a
      digit in [5-9], it becomes impossible to replicate to a MySQL slave (same with
      MariaDB slave <= 5.5, though we could fix that with a minor release).

      If we call the next MariaDB release "10.0", but send to clients that we are
      something else, this seems bound to create a lot of confusion.

      So right now, it seems preferable to rename our coming release to "9.0". There
      should still be time to do this (we are still alpha), but better not delay too
      long if this is the end decision.

      Any other ideas?

      Attachments

        Issue Links

          Activity

            People

              serg Sergei Golubchik
              knielsen Kristian Nielsen
              Votes:
              0 Vote for this issue
              Watchers:
              4 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.