ActiveMQ Artemis：共享存储HA配置下主Pod重启循环问题

问题背景 #

在Kubernetes环境中运行ActiveMQ Artemis时，配置基于共享存储的高可用（HA）策略后，主Pod陷入重启循环。本文针对该问题进行排查，同时测试了无HA策略的共享存储集群模式并分析其可行性。

已尝试操作 #

共享存储HA配置 #

主Pod的broker.xml配置：

<ha-policy>
    <shared-store>
        <primary>
            <failover-on-shutdown>true</failover-on-shutdown>
        </primary>
    </shared-store>
</ha-policy>

从Pod的broker.xml配置：

<ha-policy>
    <shared-store>
        <backup>
            <allow-failback>false</allow-failback>
            <failover-on-shutdown>true</failover-on-shutdown>
        </backup>
    </shared-store>
</ha-policy>

配置后观察到的错误日志：

ERROR [org.apache.activemq.artemis.core.server] AMQ222010: Critical IO Error, shutting down the server. file=Lost NodeManager lock, message=NULL
java.io.IOException: lost lock

无HA策略的集群模式测试 #

• 未定义任何HA策略，仅启动两个集群化Artemis节点，共享同一个PVC存储数据
• 实际行为：
  • 一个Pod自动切换为活跃状态，另一个变为被动状态
  • 虽未显式配置HA策略，但实际呈现主备架构特征

问题解答 #

1. 为何共享存储HA配置触发“Lost NodeManager lock”错误，而无HA策略的共享集群可正常运行？ #

显式配置shared-store HA策略时，Artemis会启用NodeManager锁机制来确保主节点对共享存储的独占访问，防止数据损坏。出现“lost lock”错误通常是因为：

• Kubernetes的共享存储卷不支持POSIX兼容的文件锁（比如部分NFS存储在集群模式下锁机制存在问题）
• 主Pod在持有锁期间，因网络波动、存储延迟等原因被K8s判定为不健康，导致存储卷被重新挂载或锁被强制释放
• 从Pod启动时尝试获取锁，干扰了主节点的锁持有状态

而无HA策略的共享集群模式下，Artemis不会主动启用NodeManager的强锁机制，而是依靠自身集群逻辑自动协商主备状态，对存储锁的依赖更低，因此能在锁支持不完善的存储环境中运行。

2. 无HA策略但带共享存储的集群模式是否可接受且推荐？ #

这种模式仅适合非核心业务场景，不推荐在生产环境的核心链路中使用。原因是该模式并非Artemis官方设计的标准HA方案，缺乏明确的故障切换保障机制，实际行为依赖节点间的自动协商，稳定性不可控。

如果存储环境确实无法支持POSIX锁，建议优先考虑Artemis的复制型HA策略（replication），而非依赖这种非标准的共享存储集群模式。

3. 运行带共享存储但无HA策略的ActiveMQ Artemis集群存在哪些风险？ #

• 数据一致性风险：没有NodeManager锁机制的保护，极端情况下可能出现两个节点同时写入共享存储，直接导致数据损坏或丢消息
• 故障切换不可靠：节点故障时，被动节点可能无法及时感知并切换为主节点，导致服务中断时间不可控
• 日志与排查困难：这种非标准模式的行为没有官方文档明确说明，出现问题时难以定位和排查
• 版本兼容性问题：后续Artemis版本更新可能改变集群协商逻辑，导致现有模式失效

内容的提问来源于stack exchange，提问作者Subhidh Agarwal