诊断高可用性--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客户端配置选项也值得检查。以下是我推荐的配置选项，以启用合理的故障转移时间：

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