Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: 10.0.0
    • Fix Version/s: 10.0.2
    • Labels:
      None
    • Global Rank:
      2458

      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?

        Issue Links

          Activity

          Hide
          Kristian Nielsen added a comment -

          Maybe 9.0 would work well instead of 10.0.

          It seems to not have the same problems with respect to replication (from reading the code).

          And there might be other stuff (user scripts etc) that would be happier with keeping a one-digit major version.

          Show
          Kristian Nielsen added a comment - Maybe 9.0 would work well instead of 10.0. It seems to not have the same problems with respect to replication (from reading the code). And there might be other stuff (user scripts etc) that would be happier with keeping a one-digit major version.
          Hide
          Elena Stepanova added a comment -

          Lixun Peng submitted it to MySQL, and it's even "verified"...

          Show
          Elena Stepanova added a comment - Lixun Peng submitted it to MySQL, and it's even "verified"...
          Hide
          Sergei Golubchik added a comment -

          pushed in 5.1 too

          Show
          Sergei Golubchik added a comment - pushed in 5.1 too
          Hide
          Sergei Golubchik added a comment -

          pushed in 10.0-base

          Show
          Sergei Golubchik added a comment - pushed in 10.0-base

            People

            • Assignee:
              Sergei Golubchik
              Reporter:
              Kristian Nielsen
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 0 minutes
                0m
                Remaining:
                Remaining Estimate - 0 minutes
                0m
                Logged:
                Time Spent - 5 hours, 30 minutes
                5h 30m