MySQL Bugs: #45167: MySQL proxy 0.7.1 does not work with MySQL 5.1.15

Bug #45167	MySQL proxy 0.7.1 does not work with MySQL 5.1.15
Submitted:	28 May 2009 18:55	Modified:	13 Oct 2009 10:23
Reporter:	Justin Swanhart	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Proxy: Core	Severity:	S1 (Critical)
Version:	0.7.0, 0.7.1, 0.8.0	OS:	Any
Assigned to:	Jan Kneschke	CPU Architecture:	Any
Tags:	regression

Description:
MySQL proxy 7.0.0 works (I compiled it today and tested it) against a 5.1.15 database but 7.0.1 does not.

How to repeat:
Attempt to use MySQL proxy 7.0.1 against a 5.1 database.  You will immediately get: 'Lost connection to MySQL server', because the socket disconnects immediately.

I've sent strace and tcpdump information to the proxy discussion mailing list.  I will attach them to this bug as well.

tcpdump of proxy data sent from proxy to 5.1.15

Attachment: vanilla.tcpdump (application/octet-stream, text), 808 bytes.

How to repeat should say against a 5.1.15 database, not a 5.1 database.  Newer versions of 5.1 may work.  7.0.1 will connect to MySQL 5.4, for instance.

Actually 7.0.0 does not work.

OS: CentOS 5.0
Database: 5.1.15-beta (downloaded directly from MySQL AB, and compiled locally)

Verified that it works against 5.1.24.  This is the oldest version I have lying around to test.

suggested fix, remove this code:

if (recv_sock->challenge &&

          recv_sock->challenge->server_version > 50113 && recv_sock->challenge->server_version < 50118) {

        /**

         * Bug #25371

         *

         * COM_CHANGE_USER returns 2 ERR packets instead of one

         *

         * we can auto-correct the issue if needed and remove the second packet

         * Some clients handle this issue and expect a double ERR packet.

         */

 

        con->state = CON_STATE_ERROR;

      }

Enterprise monitor uses MySQL proxy 7.0.0 which can not connect to 5.1.13 to 5.1.17

Thank you for the report.

Verified as described.

That piece of code is probably in place so that the proxy doesn't get messed up when COM_CHANGE_USER is issued by the connection pooling code.

The connection pool should be modified to check if the MySQL version is incompatible with COM_CHANGE_USER and it should abort gracefully with an error in the log when --proxy-pool-no-change-user=true is set, and the proxy connects to a MySQL backend with a version >=5.1.14 and <=5.1.17.

Since the proxy still includes the command line option:
  --proxy-fix-bug-25371                               fix bug #25371 (mysqld > 5.1.12) for older libmysql versions

it is funny that the proxy doesn't work at all with these versions anymore.

should read:
--proxy-pool-no-change-user=false

The problem also appears if a external connection pool uses COM_CHANGE_USER. 

My current approach is returning a error when COM_CHANGE_USER is received if we talked to a broken mysql-server version.

revno: 749
committer: jan@mysql.com
branch nick: trunk
timestamp: Tue 2009-07-07 18:23:32 +0200
message:
  added a test for the failing COM_CHANGE_USER (#45167)
------------------------------------------------------------
revno: 748
committer: jan@mysql.com
branch nick: trunk
timestamp: Tue 2009-07-07 18:22:42 +0200
message:
  after we sent our error on COM_CHANGE_USER to the client keep the connection open
------------------------------------------------------------
revno: 747
committer: jan@mysql.com
branch nick: trunk
timestamp: Tue 2009-07-07 17:17:11 +0200
message:
  moved the check for the broken COM_CHANGE_USER to the read_query state (fixes 45167)
  
    instead of denying to operate with the broken MySQL Servers (see #25371) we 
    just deny to forward COM_CHANGE_USER command

pushed as r699-701 to 0.7

Diego Medina writes: 
Verified fixed on 0.8.0

A note has been added to the 0.8.0 changelog: 

MySQL Proxy would fail to work with certain versions of MySQL, including MySQL 5.1.15, where a change in the MySQL protocol existed.