我已经通过xinetd使用HAProxy设置了负载平衡MySQL从站 。 2个负载均衡器共享一个由Pacemakerpipe理的虚拟IP：
crm configure show ：
node SVR120-27148.localdomain node SVR255-53192.localdomain primitive failover-ip ocf:heartbeat:IPaddr2 \ params ip="192.168.5.9" cidr_netmask="32" \ op monitor interval="5s" \ meta is-managed="true" primitive haproxy ocf:heartbeat:haproxy \ params conffile="/etc/haproxy/haproxy.cfg" \ op monitor interval="30s" \ meta is-managed="true" colocation haproxy-with-failover-ip inf: haproxy failover-ip order haproxy-after-failover-ip inf: failover-ip haproxy property $id="cib-bootstrap-options" \ dc-version="1.0.12-unknown" \ cluster-infrastructure="openais" \ no-quorum-policy="ignore" \ expected-quorum-votes="2" \ stonith-enabled="false" \ last-lrm-refresh="1342783084"
/etc/haproxy/haproxy.cfg ：
global log 127.0.0.1 local1 debug maxconn 4096 pidfile /var/run/haproxy.pid daemon defaults log global mode tcp option dontlognull retries 3 option redispatch maxconn 2000 contimeout 5000 clitimeout 50000 srvtimeout 50000 frontend FE_mysql bind 192.168.5.9:3307 default_backend BE_mysql backend BE_mysql mode tcp balance roundrobin option tcpka option httpchk #server mysql1 192.168.6.47:3306 weight 1 check port 9199 inter 12000 rise 3 fall 3 server mysql2 192.168.6.248:3306 weight 1 check port 9199 inter 12000 rise 3 fall 3 server mysql3 192.168.6.129:3306 weight 1 check port 9199 inter 12000 rise 3 fall 3
我的问题是大多数时候通过虚拟IP连接，/ /var/log/mysqld.log不断充斥着：
120719 12:59:46 [Warning] Aborted connection 17237 to db: 'db' user: 'user' host: '192.168.5.192' (Got an error reading communication packets) 120719 12:59:49 [Warning] Aborted connection 17242 to db: 'db' user: 'user' host: '192.168.5.192' (Got an error reading communication packets) 120719 12:59:52 [Warning] Aborted connection 17248 to db: 'db' user: 'user' host: '192.168.5.192' (Got an error reading communication packets)
（连接仍然build立）
192.168.5.192是HAProxy的IP地址。
mysql> show global status like 'Aborted%'; +------------------+-------+ | Variable_name | Value | +------------------+-------+ | Aborted_clients | 53626 | | Aborted_connects | 400 | +------------------+-------+
我不认为128M是不够的max_allowed_packet ：
max_connections = 300 max_allowed_packet = 128M
_timeoutvariables：
mysql> show global variables like '%timeout'; +----------------------------+----------+ | Variable_name | Value | +----------------------------+----------+ | connect_timeout | 10 | | delayed_insert_timeout | 300 | | innodb_lock_wait_timeout | 60 | | innodb_rollback_on_timeout | OFF | | interactive_timeout | 3600 | | lock_wait_timeout | 31536000 | | net_read_timeout | 30 | | net_write_timeout | 60 | | slave_net_timeout | 3600 | | wait_timeout | 600 | +----------------------------+----------+
有什么可以导致这个？ 它与HAProxy有关吗？
有什么想法吗？
这些是MySQL 文档中给出的原因：
max_allowed_packetvariables值太小，或者查询需要比为mysqld分配的内存更多的内存。 参见C.5.2.10节“分组太大”。
与Linux一起使用以太网协议，半双工和全双工。 许多Linux以太网驱动程序有这个错误。 您应该通过在客户机和服务器机器之间使用FTP传输大型文件来testing此错误。 如果传输进入突发 – 暂停 – 突发 – 暂停模式，则会遇到Linux双重综合症。 将网卡和集线器/交换机的双工模式切换为全双工或半双工模式，然后testing结果以确定最佳设置。
线程库导致读取中断的问题。
configuration错误的TCP / IP。
有故障的以太网，集线器，交换机，电缆等等。 只有更换硬件才能正确诊断。
而且， 这个解释更好：
虽然它们可能是一个更大问题的症状，但它们可能是由正常的（即不可预知的）networking问题引起的。
即使它们位于同一局域网中，由于各种原因，应用程序服务器和数据库之间可能会发生通信错误。 在通信或超时的情况下，应用程序和/或MySQL很可能会重试并运行，而且问题不会出现或显而易见。
根据我的经验，这些types消息的最常见的来源是来自应用程序（服务器）的剥离，应用程序没有正确终止连接，或者来自离站复制的延迟。
在您启用MySQL服务器上的错误日志logging之前，很可能发生了这种情况。