诊断高可用性——ActiveMQ Artemis

Diagnosing High Availability -- ActiveMQ Artemis

有没有办法诊断 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>

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

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

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