mysqlproxy0.8版本读写分离测试总结

虽说，mysql-proxy0.8版本出来的时候，标榜自己解决了哪些问题，但是根据我实际测试的情况，测试过程中还有重启的记录，

测试环境3台64位centos5.4虚拟机:

192.168.0.26 mysql-proxy

192.168.0.24 mysql-master

192.168.0.10 mysql-slave

#!/bin/sh

/root/mysql-proxy-0.8.0-linux-glibc2.3-x86-64bit/bin/mysql-proxy \
--daemon \
--keepalive \
--admin-address=:4041 \
--admin-username=root \
--admin-password=123456 \
--admin-lua-script=/root/mysql-proxy-0.8.0-linux-glibc2.3-x86-64bit/share/doc/mysql-proxy/admin-sql.lua \
--log-level=debug \
--log-file=/var/log/mysql-proxy.log \
--proxy-address=:6666 \
--proxy-backend-addresses=192.168.0.24:3306 \
--proxy-read-only-backend-addresses=192.168.0.10:3306 \
--proxy-pool-no-change-user=disabled \
--proxy-lua-script=/root/mysql-proxy-0.8.0-linux-glibc2.3-x86-64bit/share/doc/mysql-proxy/rw-splitting.lua 2>&1

启动debug模式，修改后的rw-splitting.lua，在终端我们会看到以下提示信息：

简单的通过命令行，测试一下，

mysql -h 192.168.0.26 -P6666 -u root -p'123456'

通过终端可以显示

[root@sunss-26 ~]# sh mysql-proxy.sh 
[root@sunss-26 ~]# 
[connect_server] 192.168.0.26:46062
  [1].connected_clients = 0
  [1].pool.cur_idle     = 0
  [1].pool.max_idle     = 8
  [1].pool.min_idle     = 4
  [1].type = 1
  [1].state = 0
  [1] idle-conns below min-idle
[read_query] 192.168.0.26:46062
  current backend   = 0
  client default db = 
  client username   = root
  query             = select @@version_comment limit 1
  sending to backend : 192.168.0.24:3306
    is_slave         : false
    server default db: 
    server username  : root
    in_trans        : false
    in_calc_found   : false
    COM_QUERY       : true

[connect_server] 192.168.0.26:46064
  [1].connected_clients = 0
  [1].pool.cur_idle     = 0
  [1].pool.max_idle     = 8
  [1].pool.min_idle     = 4
  [1].type = 1
  [1].state = 1
  [1] idle-conns below min-idle
[read_query] 192.168.0.26:46064
  current backend   = 0
  client default db = 
  client username   = root
  query             = select @@version_comment limit 1
  sending to backend : 192.168.0.24:3306
    is_slave         : false
    server default db: 
    server username  : root
    in_trans        : false
    in_calc_found   : false
    COM_QUERY       : true

出现的问题是：

1.在命令端，输入命令后无响应，查看日志，显示：

2010-10-28 23:29:24: (critical) network-mysqld.c:510: received packet-id 0, but expected 3 ... out of sync.
2010-10-28 23:29:24: (critical) network-mysqld.c.1254: network_mysqld_read(CON_STATE_READ_QUERY) returned an error

2.使用压力测试工具测试，跟踪表明mysql-proxy创建的子进程无法退出，导致进程挂起，别连接要么连接失败，要么连接没响应，如果连接越来越过，这些堆积的子进程也会越来越多，资源无法释放（kill，或者CTRL+C除外）

3.读写分离倒是可以做到的，但是目前mysql-proxy目前还不支持预编译语句（prepare statement）

       最后总结下吧，mysql-proxy还是不够稳定，大家遇到这种情况是怎么处理的，不妨说出来，呵呵