Details
-
Bug
-
Status: Closed (View Workflow)
-
Blocker
-
Resolution: Fixed
-
10.0.0
-
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
- causes
-
MDEV-28723 MySQL Connector fails to connect to MariaDB
- Closed
- relates to
-
CONC-21 update the client library to remove the fake version prefix
- Closed
-
CONJ-32 update the connector to remove the fake version prefix
- Closed
-
MDEV-4575 MySQL client doesn't strip off 5.5.5- prefix while connecting to 10.x server
- Closed
-
MDEV-28910 remove the 5.5.5- version hack
- Closed
- links to