首页
学习
活动
专区
圈层
工具
发布
社区首页 >问答首页 >使用MySQL的负载平衡HAProxy:读取通信数据包时出错吗?

使用MySQL的负载平衡HAProxy:读取通信数据包时出错吗?
EN

Server Fault用户
提问于 2012-07-19 06:06:52
回答 4查看 8K关注 0票数 7

我设置了通过xinetd使用使用MySQL的负载平衡MySQL从站。两个负载平衡器共享一个虚拟IP,该IP是由Pac怪人管理的:

crm configure show

代码语言:javascript
复制
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

代码语言:javascript
复制
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总是充斥着:

代码语言:javascript
复制
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) 

(连接仍在建立)

192.168.5.192是HAProxy的IP地址。

代码语言:javascript
复制
mysql> show global status like 'Aborted%';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| Aborted_clients  | 53626 |
| Aborted_connects | 400   |
+------------------+-------+

我不认为1.28M对max_allowed_packet来说是不够的:

代码语言:javascript
复制
max_connections = 300
max_allowed_packet = 128M

_timeout变量:

代码语言:javascript
复制
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有关吗?

有什么想法吗?

EN

回答 4

Server Fault用户

发布于 2012-07-19 06:37:39

以下是MySQL 文档给出的原因:

max_allowed_packet变量值太小,或者查询所需内存比分配给mysqld的内存要多。见C.5.2.10节,“包太大”。使用以太网协议与Linux,半双工和全双工。许多Linux以太网驱动程序都有这个错误。您应该通过在客户端和服务器机器之间使用FTP传输一个巨大的文件来测试这个错误。如果传输进入突发-暂停-突发暂停模式,则您正在经历Linux双工综合症。将网卡和集线器/交换机的双工模式切换到全双工或半双工,并测试结果以确定最佳设置。线程库中导致读取中断的问题。配置不良的TCP/IP。故障的以太网,集线器,开关,电缆等。只有更换硬件才能正确诊断。

而且,解释得更好:

虽然它们可能是更大问题的症状,但它们可能是由正常(即不可预防的)网络问题引起的。即使它们位于同一个LAN上,由于各种原因,应用程序服务器和数据库之间的通信错误也可能发生。在通信中断或超时的情况下,应用程序和/或MySQL最有可能重试和工作,而问题从未浮出水面或显现出来。在我的经验中,这些类型的消息最常见的来源是应用程序(服务器)崩溃,应用程序没有正确终止连接,或者来自非站点复制中的延迟。它们很可能发生在您在MySQL服务器上启用错误日志之前。

票数 2
EN

Server Fault用户

发布于 2018-02-10 20:41:28

我发现增加haproxy.cfg文件中的超时设置为我解决了这个错误。我花了很多时间检查my.cnf、wait_timeout等等,并意识到瓶颈实际上是HAProxy。

票数 1
EN

Server Fault用户

发布于 2019-01-25 04:52:27

查哈勃曼努尔

tune.idletimer设置haproxy将考虑空缓冲区可能与空闲流相关联的持续时间。这用于优化调整一些分组大小,同时交替地转发大小大小的数据。在SSL中使用splice()或发送大型缓冲区的决定由此参数调制。该值以毫秒为单位,介于0到65535之间。值为零意味着that将不会尝试检测空闲流。默认情况是1000,这似乎正确地检测到最终用户暂停(例如:点击前阅读页面)。不应该有理由改变这个值。请检查下面的tune.ssl.maxrecord。

我设置了tune.idletimer=60000并重新启动haproxy服务。问题又发生了。我在haproxy 1.8.14中遇到了这个问题。

旧的haproxy 1.5.4是可以的。

票数 0
EN
页面原文内容由Server Fault提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://serverfault.com/questions/409973

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档