ActiveMQ Artemis共享存储模式主节点未启动时备节点启动异常

该表现是ActiveMQ Artemis共享存储master/slave主备架构下的默认预期行为。

默认配置逻辑下，slave节点启动后会优先尝试与存活的master节点建立集群连接，确认自身备份身份、完成必要的运行状态同步后，才会进入可接管的备份就绪状态。如果启动时探测不到存活的master，slave不会直接触发升主动作——这个设计的核心目的是规避脑裂，避免出现两个节点同时持有共享存储写锁、同时作为live节点对外服务，最终导致消息数据损坏的问题。你看到的AMQ221032: Waiting to become backup node日志，就代表slave正卡在等待master确认备份身份的阶段。

如果需要在master宕机场景下让slave启动时直接升为live节点对外服务，可以通过修改slave节点的HA策略配置实现，核心是关闭启动阶段强制等待存活master的校验规则，配置片段参考如下：

<ha-policy>
  <shared-store>
    <slave>
      <!-- 关闭启动时必须等待存活master的校验 -->
      <wait-for-live-server>false</wait-for-live-server>
      <!-- 可选配置：原master后续恢复时自动保持当前slave升主后的live身份，避免业务回切中断 -->
      <failover-on-shutdown>true</failover-on-shutdown>
      <!-- 注意：所有存储路径（消息日志、分页目录、绑定信息存储等）必须和原master配置一致，指向同一套共享存储目录 -->
    </slave>
  </shared-store>
</ha-policy>

配置使用时需要注意几个关键点：

• 必须提前确认底层共享存储的文件锁机制正常工作，否则关闭wait-for-live-server校验后会存在明确的脑裂风险：一旦存储锁失效，两个节点可能同时拿到共享存储写锁、同时启动为live节点，直接造成消息数据损坏。
• 该配置仅适合master节点已确认完全宕机、不会自行恢复启动的场景；如果master只是临时故障、后续会自动拉起，不建议修改该默认值，避免启动时序异常触发脑裂。
• 配置生效后，slave启动时如果探测不到存活master，会直接尝试抢占共享存储的active锁，抢占成功后就会直接进入live运行状态对外服务，不会再卡在等待备份身份确认的阶段。

内容的提问来源于stack exchange，提问作者Nicolas Verducou