ActiveMQ 经典到 ActiveMQ Artemis 故障转移不起作用

Posted 2023-03-10

【中文标题】ActiveMQ 经典到 ActiveMQ Artemis 故障转移不起作用

【英文标题】：ActiveMQ classic to ActiveMQ Artemis failover does not work

【发布时间】：2022-01-04 14:16:29

【问题描述】：

我正在尝试从 ActiveMQ“经典”迁移到 ActiveMQ Artemis。

我们有一个由 2 个活动节点组成的集群，我们尝试在不影响消费者和生产者的情况下迁移它们。为此，我们停止第一个节点，迁移它，启动它，并在第一个节点备份时在第二个节点执行相同操作。

我们观察到消费者/生产者无法重新连接：

o.a.a.t.f.FailoverTransport | |无法连接到 [tcp://172.17.233.92:63616?soTimeout=30000&soWriteTimeout=30000&keepAlive=true, tcp://172.17.233.93:63616?soTimeout=30000&soWriteTimeout=30000&keepAlive=true] 后：30 次尝试继续重试。

消费者/生产者在我们重新启动后能够连接。 这是正常行为吗？

这里是 ActiveMQ Artemis 代理：

  <connectors>
       <connector name="netty-connector">tcp://172.17.233.92:63616</connector>
       <connector name="server_0">tcp://172.17.233.93:63616</connector>
  </connectors>
  <acceptors>
       <acceptor name="netty-acceptor">tcp://172.17.233.92:63616?protocols=OPENWIRE</acceptor>
       <acceptor name="invm">"vm://0</acceptor>
  </acceptors>
  <cluster-connections>
     <cluster-connection name="cluster">
        <connector-ref>netty-connector</connector-ref>
        <retry-interval>500</retry-interval>
        <use-duplicate-detection>true</use-duplicate-detection>
        <message-load-balancing>ON_DEMAND</message-load-balancing>
        <max-hops>1</max-hops>
        <static-connectors>
           <connector-ref>server_0</connector-ref>
        </static-connectors>
     </cluster-connection>
  </cluster-connections>

这里是 ActiveMQ “经典”配置

     <!-- Transport protocol -->
    <transportConnectors>
        <transportConnector name="openwire"
                            uri="nio://172.17.233.92:63616?transport.soTimeout=15000&transport.threadName&keepAlive=true&transport.soWriteTimeout=15000&wireFormat.maxInactivityDuration=0"
                            enableStatusMonitor="true" rebalanceClusterClients="true" updateClusterClients="true" updateClusterClientsOnRemove="true" />
    </transportConnectors>

    <!-- Network of brokers setup -->
    <networkConnectors>
        <!-- we need conduit subscriptions for topics , but not for queue -->
        <networkConnector name="NC_topic" duplex="false" conduitSubscriptions="true" networkTTL="1" uri="static:(tcp://172.17.233.92:63616,tcp://172.17.233.93:63616)" decreaseNetworkConsumerPriority="true" suppressDuplicateTopicSubscriptions="true" dynamicOnly="true">
            <excludedDestinations>
                <queue physicalName=">" />
            </excludedDestinations>
        </networkConnector>
        <!-- we need conduit subscriptions for topics , but not for queue -->
        <networkConnector name="NC_queue" duplex="false" conduitSubscriptions="false" networkTTL="1" uri="static:(tcp://172.17.233.92:63616,tcp://172.17.233.93:63616)" decreaseNetworkConsumerPriority="true" suppressDuplicateQueueSubscriptions="true" dynamicOnly="true">
            <excludedDestinations>
                <topic physicalName=">" />
            </excludedDestinations>
        </networkConnector>
    </networkConnectors>

【问题讨论】：

您使用的是什么客户端库/版本？你可以分享客户端连接URL吗？你能分享 ActiveMQ Artemis broker.xml 吗？停止第一个节点后是否看到连接失败？

您好，连接 URL 是 [tcp://172.17.233.92:63616?soTimeout=30000&soWriteTimeout=30000&keepAlive=true, tcp://172.17.233.93:63616?soTimeout=30000&soWriteTimeout=30000&keepAlive=true] .我们正在使用 ActiveMQ 客户端 5.15.4

我之前从未领导过在“Classic”和 Artemis 之间尝试过这种“故障转移”的人，所以不清楚这个用例的“正常行为”究竟是什么。

您是否有机会按照之前的要求使用broker.xml 的内容修改您的问题？

我添加了 Artemis 和“经典”配置

【参考方案1】：

最后我们决定先停止2个节点，然后升级重启。从消费者/生产者的角度来看，这意味着中断，但所有订阅在重启后都已正确完成。

【参考方案2】：

这个问题应该是由于updateClusterClientsOnRemove，如果为真，将在从网络中删除集群时更新客户端，请参阅broker-side options for failover。

当第一个节点停止时，客户端将删除它并且他们不会再次添加它，因为 ActiveMQ Classic 的第二个节点无法连接到 ActiveMQ Artemis 的第一个节点。