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: | |
| 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 | ||
[28 May 2009 18:55]
Justin Swanhart
[28 May 2009 18:56]
Justin Swanhart
tcpdump of proxy data sent from proxy to 5.1.15
Attachment: vanilla.tcpdump (application/octet-stream, text), 808 bytes.
[28 May 2009 18:59]
Justin Swanhart
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.
[28 May 2009 19:08]
Justin Swanhart
Actually 7.0.0 does not work.
[28 May 2009 19:15]
Justin Swanhart
OS: CentOS 5.0 Database: 5.1.15-beta (downloaded directly from MySQL AB, and compiled locally)
[28 May 2009 19:18]
Justin Swanhart
Verified that it works against 5.1.24. This is the oldest version I have lying around to test.
[28 May 2009 20:01]
Justin Swanhart
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;
}
[28 May 2009 20:02]
Justin Swanhart
Enterprise monitor uses MySQL proxy 7.0.0 which can not connect to 5.1.13 to 5.1.17
[28 May 2009 21:28]
Sveta Smirnova
Thank you for the report. Verified as described.
[28 May 2009 22:41]
Justin Swanhart
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.
[28 May 2009 22:42]
Justin Swanhart
should read: --proxy-pool-no-change-user=false
[11 Jun 2009 15:04]
Jan Kneschke
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.
[7 Jul 2009 16:24]
Jan Kneschke
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
[10 Jul 2009 11:54]
Jan Kneschke
pushed as r699-701 to 0.7
[1 Sep 2009 16:48]
Enterprise Tools JIRA Robot
Diego Medina writes: Verified fixed on 0.8.0
[13 Oct 2009 10:23]
MC Brown
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.
Portions of this website are copyright © 2001, 2002 The PHP Group
Page generated in 0.067 sec. using MySQL 8.4.7-u6-cloud
Timestamp references displayed by the system are UTC.
Content reproduced on this site is the property of the
respective copyright holders.
It is not reviewed in advance
by Oracle and does not necessarily represent the opinion of
Oracle or any other party.