我对ActiveMQ Artemis集群迁移到可插拔仲裁配置有疑问。
目前，我们在测试环境中有一个集群，它有6台服务器(3对具有经典复制的主服务器和从服务器(，我计划迁移到具有可插拔仲裁投票的集群。阿尔忒弥斯的版本是2.23.1。
我已经配置了另一个(预测试(集群，其中有3个动物园管理员节点和2个主/备份阿尔忒弥斯节点。它似乎工作得很好，但这是一个预测试环境，我们在这里进行一些实验，没有客户端和工作负载。因此，我决定将测试集群重新配置为使用可插入的仲裁投票。
起初，我认为我们可以将每个服务器的角色从主服务器更改为主服务器，从从属服务器更改为备份服务器。
以前的配置是-主：
<ha-policy>
<replication>
<master>
<check-for-live-server>true</check-for-live-server>
<vote-on-replication-failure>true</vote-on-replication-failure>
<quorum-size>2</quorum-size>
<group-name>group-for-each-pair</group-name>
</master>
</replication>
</ha-policy>
从：
<ha-policy>
<replication>
<slave>
<allow-failback>true</allow-failback>
<group-name>group-for-each-pair</group-name>
</slave>
</replication>
</ha-policy>
组名称用于从属设备，以确定它必须连接到哪个主设备。
很遗憾，此设置在主部分和备份部分不起作用。我试图配置它，并获得broker.xml的xsd验证错误。
在文档中，有一些关于可插拔仲裁配置中不再需要的设置的文字：
有一些不再需要的经典复制配置：
复制失败时投票法定投票等待投票重试次数投票重试等待检查实时服务器
但是<group-name>什么都没有。也许是文件问题。
新配置是-主要：
<ha-policy>
<replication>
<primary>
<manager>
<class-name>org.apache.activemq.artemis.quorum.zookeeper.CuratorDistributedPrimitiveManager</class-name>
<properties>
<property key="connect-string" value="zookeeper-amq1:2181,zookeeper-amq2:2181,zookeeper-amq3:2181"/>
</properties>
</manager>
</primary>
</replication>
</ha-policy>
备份：
<ha-policy>
<replication>
<backup>
<manager>
<class-name>org.apache.activemq.artemis.quorum.zookeeper.CuratorDistributedPrimitiveManager</class-name>
<properties>
<property key="connect-string" value="zookeeper-amq1:2181,zookeeper-amq2:2181,zookeeper-amq3:2181"/>
</properties>
</manager>
<allow-failback>true</allow-failback>
</backup>
</replication>
</ha-policy>
当我尝试使用这些设置启动群集时，我发现备份服务器试图连接到任何主服务器，但其中一些服务器无法启动。我又回到了原来的配置。
我阅读了文档，发现了一些可以帮助的设置：
<coordination-id>。用于多主配置，可能在本节中不起作用- Apache Curator设置中的
namespace。也许将服务器拆分成对会有所帮助，每个备份都将连接到同一命名空间中的主服务器。但它可能是为另一个目的而设计的(为几个单独的集群配备一名动物园管理员(，可能还会有其他一些问题
另一个选项是删除不必要的4台ActiveMQ Artemis服务器，只使用1对服务器。这将需要重新配置客户端，但即使连接字符串中还有6台服务器，客户端也只能继续使用剩下的2台服务器。
是否有一种在不更改集群拓扑(6台服务器(的情况下从经典复制迁移到可插拔仲裁表决的首选方法？
此测试环境中的任何更改(如果成功(都将在具有相同拓扑的UAT和生产集群上执行。因此，如果可能的话，我们更希望平稳迁移。
我建议您像以前一样使用group-name。例如在主设备上：
<ha-policy>
<replication>
<primary>
<manager>
<class-name>org.apache.activemq.artemis.quorum.zookeeper.CuratorDistributedPrimitiveManager</class-name>
<properties>
<property key="connect-string" value="zookeeper-amq1:2181,zookeeper-amq2:2181,zookeeper-amq3:2181"/>
</properties>
</manager>
<group-name>group-for-each-pair</group-name>
</primary>
</replication>
</ha-policy>
在备份上：
<ha-policy>
<replication>
<backup>
<manager>
<class-name>org.apache.activemq.artemis.quorum.zookeeper.CuratorDistributedPrimitiveManager</class-name>
<properties>
<property key="connect-string" value="zookeeper-amq1:2181,zookeeper-amq2:2181,zookeeper-amq3:2181"/>
</properties>
</manager>
<group-name>group-for-each-pair</group-name>
<allow-failback>true</allow-failback>
</backup>
</replication>
</ha-policy>
也就是说，我强烈建议您使用一对HA代理执行性能测试。单个代理每秒可能处理数百万条消息，因此您可能不需要由3个主要代理组成的集群。此外，如果你的应用程序连接到集群节点，使得消息在一个节点上产生，并从另一个节点消耗，那么拥有集群实际上可能会因为额外的"；啤酒花"；一条信息必须被接受。显然，对于单个HA对来说，这不是一个问题。
最后，从6个代理减少到2个代理将显著降低配置和操作复杂性，而且还可能大幅降低基础设施成本。这是我们首先实现可插拔法定人数投票的主要原因之一。