当前位置: 首页 > 知识库问答 >
问题:

通过JGroups协议在Artemis集群中实现共享存储HA策略的高可用性和故障转移

林曦之
2023-03-14

但是在共享存储中,没有group-name这样的概念。我很困惑。如果我必须通过JGroups中的共享存储来实现高可用性,那么该如何实现。

再次,当我尝试通过提供group-name的复制HA策略执行此操作时,集群已经形成,故障转移正在工作,但我得到警告:

2020-10-02 16:35:21,517 WARN  [org.apache.activemq.artemis.core.client] AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have a backup node active at the same time as its live node. nodeID=220da24b-049c-11eb-8da6-0050569b585d
2020-10-02 16:35:21,517 WARN  [org.apache.activemq.artemis.core.client] AMQ212034: There are more than one servers on the network broadcasting the same node id. You will see this message exactly once (per node) if a node is restarted, in which case it can be safely ignored. But if it is logged continuously it means you really do have more than one node on the same network active concurrently with the same node id. This could occur if you have a backup node active at the same time as its live node. nodeID=220da24b-049c-11eb-8da6-0050569b585d
2020-10-02 16:35:25,350 WARN  [org.apache.activemq.artemis.core.server] AMQ224078: The size of duplicate cache detection (<id_cache-size/>) appears to be too large 20,000. It should be no greater than the number of messages that can be squeezed into confirmation window buffer (<confirmation-window-size/>) 32,000.

共有1个答案

冯皓
2023-03-14

正如名称“shared-store”所示,实时代理和备份代理成为一个逻辑对,可以支持高可用性和故障转移,因为它们共享相同的数据存储。因为它们共享相同的数据存储,所以不需要任何类型的group-name配置。这样的选择将是混乱的、多余的,最终是无用的。

JGroups配置(以及cluster-connection)的存在,是因为这两个代理需要相互交换关于各自网络位置的信息,以便在发生故障时live broker可以通知客户端如何连接到备份。

关于网络上重复节点ID的warn消息...在故障转移或故障返回期间,您可能会收到一次或两次警告消息,但如果您看到的次数超过这个次数,那么就有问题了。如果您使用的是shared-store,则表示共享文件系统上的锁有问题。如果你使用复制,那么这表明潜在的配置错误或可能是大脑分裂。

 类似资料:
  • 因此,如果我理解正确的话,在检测并重新启动失败代理的环境中运行Artemis代理集群将提供与运行每个活动服务器都与备份配对的集群相同的语义(以及类似的可用性)。对吗?

  • null 当我使用Ctrl-C停止活动服务器时,从服务器报告的而断开连接,这是正确的,但是备份服务器没有更改其状态,也没有侦听端口61617。那么我在配置中做错了什么呢? 实时服务器配置: 备份服务器配置:

  • 我注意到,当连接的Artemis节点宕机时,连接到节点2-4的客户机不会故障转移到其他3个可用的主节点,基本上不会发现其他节点。即使在原始节点恢复之后,客户端仍然无法建立连接。我从一个单独的堆栈溢出帖子中看到,不支持主到主故障转移。这是否意味着对于每个主节点,我也需要创建一个从节点来处理故障转移?这是否会导致两个实例点失败,而不是集群中有许多节点? 在一个单独的基本测试中,使用一个主从两个节点的集

  • 目前,我正在使用ActiveMQ,并计划将系统迁移到ActiveMQ Artemis。目前,我有3个生产者和3个消费者,只有一个ActiveMQ服务器/代理。

  • 下面是Broker.xml中artemis集群(3台服务器)的设置 我预计broker3在集群中就应该开始接收请求。

  • 问题内容: 在过去的问题中,我询问了如何在不破坏种族的情况下实现pthread屏障: 从迈克尔·伯尔(Michael Burr)那里获得了针对过程本地障碍的完美解决方案,但是对于过程共享的障碍却没有。我们后来研究了一些想法,但从未得出令人满意的结论,甚至没有开始涉及资源故障案例。 在Linux上能否制造出满足以下条件的障碍: 进程共享的(可以在任何共享内存中创建)。 在屏障等待函数返回后,可以安全