温馨提示×

rabbitmq集群故障centos怎么排查

小樊
38
2025-12-23 09:38:58
栏目: 智能运维

CentOS 上 RabbitMQ 集群故障排查步骤

一 快速定位与基础检查

  • 检查节点进程与基础状态
    • 查看服务:systemctl status rabbitmq-server
    • 查看节点状态:rabbitmqctl status
    • 查看集群状态:rabbitmqctl cluster_status(关注 running_nodesnodespartitions 字段)
  • 检查端口连通性(集群通信与业务端口)
    • epmd 端口:4369/TCP(节点发现)
    • 集群通信:25672/TCP(节点间通信)
    • 业务 AMQP:5672/TCP
    • 管理插件:15672/TCP
    • 示例:ss -tnlp | egrep ‘4369|25672|5672|15672’;必要时在节点间执行 telnet 对端IP 端口 验证
  • 检查主机名解析
    • 确认短/长主机名一致:hostnamectl;/etc/hosts 应包含集群所有节点的 IP<->hostname 映射,且 hostname 与节点名后缀一致(如 rabbit@
  • 检查防火墙/安全组
    • firewalld:firewall-cmd --list-ports;放通 4369、25672、5672、15672 或临时测试时 systemctl stop firewalld
    • 如走云上安全组,同样需放通上述端口
  • 检查 Erlang Cookie 一致性
    • 文件:/var/lib/rabbitmq/.erlang.cookie(属主 rabbitmq:rabbitmq,权限 600
    • 各节点 cookie 必须完全一致(建议使用主节点 scp 覆盖,再校正权限与属主)

二 常见故障场景与修复

  • 加入集群报错 nodedown / unable to connect
    • 现象:join_cluster 失败,诊断提示 epmd 连不通或目标主机不可达
    • 处理:校正 /etc/hosts 与 hostname;确保 4369/25672 互通;统一 .erlang.cookie 权限为 600;必要时短暂关闭防火墙验证;按“先 stop_app → join_cluster → start_app”的顺序操作
  • 全部节点重启后无法启动或长时间等待 Mnesia 表
    • 现象:日志出现 “Waiting for Mnesia tables …”,默认每次 30 秒、最多 20 次重试
    • 处理:按“最后宕机的节点最先启动”的顺序启动;若无法满足,可在唯一存活的磁盘节点执行 rabbitmqctl force_boot 后启动其他节点
  • 节点不一致(inconsistent_cluster)
    • 现象:某节点认为仍在集群,但其他节点已将其移除
    • 处理:在“被移除”的节点执行 rabbitmqctl reset 后再 start_app;若所在节点是集群中唯一的磁盘节点,需先 force_reset 再重建集群关系
  • 只剩磁盘节点无法 reset
    • 现象:执行 reset 提示不能重置唯一的磁盘节点
    • 处理:在该节点执行 rabbitmqctl force_reset 后再 reset/启动,随后重新加入集群
  • 管理界面看不到节点统计或插件未启用
    • 处理:在对应节点启用管理插件 rabbitmq-plugins enable rabbitmq_management,再访问 http://:15672

三 日志与诊断命令

  • 查看节点与集群诊断
    • rabbitmq-diagnostics status(查看运行状态、内存、磁盘、连接等)
    • rabbitmq-diagnostics cluster_status(查看节点列表、运行状态、分区等)
  • 查看日志定位问题
    • 日志目录:/var/log/rabbitmq/,主要查看 rabbit@.log 与 rabbit@-sasl.log
    • 关注关键词:nodedown、epmd、timeout_waiting_for_tables、inconsistent_cluster、connection_closed、blocked by firewall 等
  • 启用管理插件便于可视化排查
    • rabbitmq-plugins enable rabbitmq_management(访问 15672 查看节点、队列、连接、告警等)

四 恢复与重建集群的稳妥做法

  • 准备
    • 选择一个数据最完整的节点作为“最后停止”的节点,优先启动它;确保集群中至少有一个 磁盘节点 以保留元数据
  • 启动顺序
    • 先启动“最后停止”的节点;再依次启动其他节点,观察 cluster_status 的 running_nodes 是否逐步恢复
  • 无法按正确顺序启动
    • 在唯一存活的磁盘节点执行 rabbitmqctl force_boot,随后启动其他节点
  • 清理“失联”节点
    • 在健康节点执行 rabbitmqctl forget_cluster_node (支持 --offline 离线移除),随后在失联节点 reset 并重新加入
  • 重建关系与节点类型
    • 加入集群:在每个待加入节点执行 rabbitmqctl stop_app → rabbitmqctl join_cluster <seed_node> [–ram] → rabbitmqctl start_app
    • 变更类型:rabbitmqctl stop_app → rabbitmqctl change_cluster_node_type disc|ram → rabbitmqctl start_app
  • 验证
    • cluster_status 应显示所有节点一致、partitions 为空、running_nodes 完整;管理界面各节点状态为绿色

五 最小可用检查清单

  • 每个节点:服务运行(systemctl status rabbitmq-server)、节点名与 /etc/hosts 一致、.erlang.cookie 一致且权限 600
  • 端口:4369、25672、5672、15672 对集群内互通(ss/telnet 验证)
  • 防火墙/安全组:已放通上述端口
  • 集群状态:cluster_status 中 partitions=[]、running_nodes 数量正确、无 inconsistent_cluster 告警
  • 管理面:15672 可登录并查看节点与队列概况

0