rabbitmq普通集群(3节点)+haproxy,节点无规律宕掉

zp_xyz 2018-06-08 11:06:36
现在生产上有一个rabbitmq(RabbitMQ 3.6.3, Erlang 18.1),三个节点,普通集群,集群前面有一个haproxy进行负载均衡,最近发现集群中的三个节点会随机出现宕掉的情况,影响业务。
下面是haproxy的配置
 global
log 127.0.0.1 local0
log 127.0.0.1 local2 info
maxconn 4096
user haproxy
group haproxy
daemon
pidfile /var/run/haproxy.pid

defaults
log global
mode tcp
option tcplog
option dontlognull #保证HAProxy不记录上级负载均衡发送过来的用于检测状态没有数据的心跳包
retries 3 #重试次数
option redispatch
maxconn 4096 #最大连接数
#balance source #如果想让HAProxy按照客户端的IP地址进行负载均衡策略,即同一IP地址的所有请求都发送到同一服务器时需要配置此选项
balance leastconn
timeout connect 5000
timeout client 70000
timeout server 70000

listen admin_stat
#haproxy的web管理端口 8888,自行设置
bind 0.0.0.0:8888
mode http
stats refresh 30s
#haproxy web管理url,自行设置
stats uri /haproxy_stats
stats realm Haproxy\ Statistics
#haproxy web管理用户名密码,自行设置
stats auth admin:Byb1Asr9
stats hide-version

listen rabbitmq
#监听5672端口(如果haproxy安装在集群节点上时请选择非5672端口如5670),并转发给三个节点的5672端口,采用轮询策略
bind 0.0.0.0:5672
mode tcp
balance roundrobin
server rabbitmq-1 192.168.1.15:5672 check inter 2000 rise 2 fall 3
server rabbitmq-2 192.168.1.16:5672 check inter 2000 rise 2 fall 3
server rabbitmq-3 192.168.1.17:5672 check inter 2000 rise 2 fall 3


下图是rabbitmq的信息


节点宕掉的时候,在节点的mq日志(rabbitmq@mq1.log)里只能看到下面的信息,没有其他的错误信息
在系统的/var/log/message这个时间段,没有出现错误。
 =INFO REPORT==== 5-Jun-2018::01:30:09 ===
accepting AMQP connection <0.227.33> (192.168.1.7:43276 -> 192.168.1.16:5672)

=INFO REPORT==== 5-Jun-2018::01:30:09 ===
accepting AMQP connection <0.224.33> (192.168.1.7:43279 -> 192.168.1.16:5672)

=INFO REPORT==== 5-Jun-2018::01:30:09 ===
accepting AMQP connection <0.294.33> (192.168.1.7:43282 -> 192.168.1.16:5672)

=WARNING REPORT==== 6-Jun-2018::12:18:07 ===
closing AMQP connection <0.227.33> (192.168.1.7:43276 -> 192.168.1.16:5672):
client unexpectedly closed TCP connection

=INFO REPORT==== 6-Jun-2018::19:14:47 ===
rabbit on node rabbit@mq1 down

=INFO REPORT==== 6-Jun-2018::19:14:47 ===
accepting AMQP connection <0.16310.70> (192.168.1.7:42508 -> 192.168.1.16:5672)

=INFO REPORT==== 6-Jun-2018::19:14:47 ===
accepting AMQP connection <0.16320.70> (192.168.1.7:42511 -> 192.168.1.16:5672)

=INFO REPORT==== 6-Jun-2018::19:14:48 ===
accepting AMQP connection <0.16390.70> (192.168.1.7:42514 -> 192.168.1.16:5672)

=INFO REPORT==== 6-Jun-2018::19:14:48 ===
Statistics event collector started.



在/var/log/secure里宕掉的时间点有如下日志,其他的信息都没有了:

Jun  6 19:14:48 mq1 su: pam_unix(su:session): session closed for user rabbitmq


想问一下,各位,有没有谁碰到类似的问题,或者能否提供一些解析问题的思路?谢谢了
...全文
1544 2 打赏 收藏 转发到动态 举报
写回复
2 条回复
切换为时间正序
请发表友善的回复…
发表回复
zp_xyz 2018-06-21
  • 打赏
  • 举报
回复
https://groups.google.com/forum/#!searchin/rabbitmq-users/connection_closed%7Csort:date/rabbitmq-users/UGQbdvM1rTA/t4-q6Z27BAAJ

最终咨询了官方后,对方说是版本有重大Bug,可能会导致出现类似问题,所以建议赶紧升级处理,最后先去升级再来看是否会出问题。
zp_xyz 2018-06-08
  • 打赏
  • 举报
回复
我一直比较疑惑为什么会出现 “client unexpectedly closed TCP connection” ,我在本地专门搭了一个一样的环境,抓包测试了一下rabbitmq的心跳机制,client建立连接后,如果心跳是60s,那么在连接建立后的第60s,client会发一个心跳请求给到mq,mq同时会回一个心跳给client,然后每30s,client都会发心跳到mq,每60s ,mq会发心跳到client。如果是这个样子的话,我不是太理解什么时候,会出现连接被close掉。
下图为抓包后请求明细
相关推荐
Re: 《Galera 高可用 MySQL 集群》 (Percona Xtradb Cluster)PXC v5.7 + Haproxy + Keepalived========================================================# Galera Cluster 如何解决问题 我们知道 Galera Cluster 是 MySQL封装了具有高一致性,支持多点写入的同步通信模块Galera而做的,它是建立在MySQL同步基础之上的,使用 Galera Cluster时,应用程序可以直接读、写某个节点的最新数据,并且可以在不影响应用程序读写的情况下,下线某个节点,因为支持多点写入,使得 Failover 变得非常简单。 目前Galera Cluster具备的功能包括如下几个方面:    1) 多主架构:真正的多点读写的集群,在任何时候读写数据,都是最新的。    2) 同步复制:集群不同节点之间数据同步,没有延迟,在数据库挂之后,数据不会丢失。    3) 并发复制:从节点在APPLY数据时,支持并行执行,有更好的性能表现。    4) 故障切换:在出现数据库故障时,因为支持多点写入,切的非常容易。    5) 热插拔  :在服务期间,如果数据库挂了,只要监控程序发现的够快,不可服务时间就会非常少。在节点故障期间,节点本身对集群的影响非常小。    6) 自动节点克隆:在新增节点,或者停机维护时,增量数据或者基础数据不需要人工手动备份提供, Galera Cluster会自动拉取在线节点数据,最终集群会变为一致。    7) 对应用透明:集群的维护,对应用程序是透明的,几乎感觉不到。以上几点,足以说明Galera Cluster是一个既稳健,又在数据一致性、完整性及高性能方面有出色表现的高可用解决方案

49,935

社区成员

发帖
与我相关
我的任务
社区描述
Java相关技术讨论
javaspring bootspring cloud 技术论坛(原bbs)
社区管理员
  • Java相关社区
  • 小虚竹
  • 谙忆
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告