诊断高可用性——ActiveMQ Artemis

Question

有没有办法在 ActiveMQ Artemis 中诊断 HA 问题？我有一对运行良好的共享存储服务器。当我关闭主服务器时，辅助服务器会接管，直到主服务器告诉它它已备份，然后主服务器接管，辅助服务器恢复为辅助服务器。

我把配置复制到另一对服务器上，但是这个不工作。

据我所知，一切看起来都很好。集群出现在控制台中，两台服务器连接。当我关闭主服务器时，辅助服务器会记录以下消息：

2020-12-06 16:59:26,379 WARN  [org.apache.activemq.artemis.core.client] AMQ212037: Connection failure to <Primary IP>/<Primary IP>:61616 has been detected: AMQ219015: The connection was disconnected because of server shutdown [code=DISCONNECTED]

在工作对中，在这条消息之后，辅助节点迅速部署我所有的地址和队列并接管。但是新的对，从属在这之后什么都不做。

我不确定从哪里开始寻找。我只是不断将非工作对的配置与工作对的配置进行比较。

我正在使用 NFS 挂载。共享文件的类型是 Azure 的 NetApp。

这是我的代理配置。这是正确的，因为它适用于另一对......

初级：

<connectors>
   <connector name="artemis">tcp://<primary URL>:61616</connector>
   <connector name="artemis-backup">tcp://<secondary URL>:61616</connector>
</connectors>

<cluster-user>activemq</cluster-user>
<cluster-password>artemis123</cluster-password>

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

<cluster-connections>
   <cluster-connection name="cluster-1">
      <connector-ref>artemis</connector-ref>
      <static-connectors>
         <connector-ref>artemis-backup</connector-ref>
      </static-connectors>
   </cluster-connection>
</cluster-connections>

中学：

<connectors>
   <connector name="artemis-live">tcp://<primary URL>:61616</connector>
   <connector name="artemis">tcp://<secondary URL>:61616</connector>
</connectors>

<cluster-user>activemq</cluster-user>
<cluster-password>artemis123</cluster-password>

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

<cluster-connections>
   <cluster-connection name="cluster-1">
      <connector-ref>artemis</connector-ref>
      <static-connectors>
         <connector-ref>artemis-live</connector-ref>
      </static-connectors>
   </cluster-connection>
</cluster-connections>

Answer 1

在共享存储配置中，备份代理不断尝试获取日志上的文件锁。但是，由于主代理已经拥有锁，因此在主代理死亡之前它无法获得。因此，我会查看共享存储并确保文件锁定正常工作。

由于您使用的是 NFS，因此 NFS 客户端配置选项也值得检查。以下是我推荐的配置选项，以启用合理的故障转移时间：

• timeo=50 - NFS 超时 5 秒
• retrans=1 - 只允许重试一次
• soft - 软挂载 NFS 共享会禁用永久重试逻辑，允许 NFS 错误在上述超时后弹出到应用程序堆栈中
• noac - 关闭文件属性的缓存，但也强制同步写入 NFS 共享。这也减少了 NFS 错误弹出的时间。