ejabberd双节点集群中MUC房间表仅显示单节点的原因排查

一、muc_room表node字段的作用 #

• 标记持久化MUC房间当前的运行节点：ejabberd集群里，一个MUC房间只会由单个节点负责运行，处理所有和这个房间相关的逻辑——比如消息转发、成员管理、权限控制。node字段就是记录这个负责节点的标识（格式是ejabberd节点名@主机名）。
• 集群路由的核心依据：当用户连接到集群里的其他节点，要访问这个房间时，节点会通过node字段的值，把请求转发到对应的负责节点，保证房间逻辑的一致性，不会出现多节点同时处理同一房间的混乱情况。
• 故障恢复的参考标识：如果负责房间的节点挂了，ejabberd可以通过这个字段的记录，在集群里其他正常节点上重新激活这个持久化房间，避免房间丢失。

二、用户跨节点连接时消息收发异常的排查方案 #

1. 检查HAProxy的会话保持配置 #

• 必须开启会话粘滞（session stickiness）：MUC的消息处理依赖用户连接节点和房间负责节点的关联，如果HAProxy没把同一用户的连接固定到同一个节点，很容易导致消息路由混乱。建议配置基于JID或者客户端Cookie的会话粘滞规则，确保用户全程连接到同一节点。
• 调整负载均衡策略：别用轮询这种无状态策略，换成带会话保持的，比如基于客户端IP的source模式，或者Cookie模式。

2. 验证ejabberd集群的MUC配置与状态 #

• 确认集群节点通信正常：执行ejabberdctl cluster_status，检查所有节点是否正常加入集群，节点之间能不能互通。
• 检查mod_muc的路由配置：确保mod_muc的route_subscribed参数设为true，这个配置会让节点把订阅房间的消息正确路由到房间的负责节点。
• 查看房间的集群激活状态：在ejabberd2节点上执行ejabberdctl list_muc_rooms，确认这些持久化房间是否在集群里被正确识别——如果ejabberd1正常运行，ejabberd2应该能看到房间的路由信息，知道要把消息转发到ejabberd1。

3. 日志排查定位问题 #

• 查看ejabberd日志：去默认日志路径/var/log/ejabberd/ejabberd.log里搜muc、route、message这类关键词，看看有没有消息转发失败、路由错误的日志条目。
• 临时开启调试日志：把ejabberd的日志级别调到debug，观察消息从客户端到节点、再到房间负责节点的完整路径，就能定位出在哪一步出了问题。

内容的提问来源于stack exchange，提问作者Vipin CP