ActiveMQ Artemis群集故障转移支持
目前，我正在使用ActiveMQ，并计划将系统迁移到ActiveMQ Artemis。目前，我有3个生产者和3个消费者，只有一个ActiveMQ服务器/代理。
共有1个答案
在ActiveMQ Artemis中，集群和故障转移是相互关联但又截然不同的概念。
在集群中，消息可以跨节点负载平衡，但每个节点“拥有”其上的消息。如果集群中的某个节点出现故障，那么该节点上的消息将不再对客户端可用。群集的设计目的是在处理大量客户端时通过水平伸缩来增加消息吞吐量。
故障转移提供消息的高可用性，因此，如果节点发生故障，则其备份将接管，并确保来自故障节点的消息仍可供客户端使用。请参阅文档中的更多详细信息。
如果您认为可能采用集群配置，我鼓励您使用单个代理对应用程序进行基准测试。ActiveMQ Artemis的性能相当不错。在某些用例中，它可以每秒处理数百万条消息。单个代理的性能可能足以支持您的用例。不要盲目地对代理进行集群，因为这可能会不必要地使配置和维护复杂化，并浪费资源。
-
我正在尝试用6台机器实现一个Redis集群。我有一个由六台机器组成的流浪集群： 运行redis服务器 我编辑了上述所有服务器的/etc/redis/redis.conf文件，添加了这个 然后我在六台机器中的一台上运行了这个程序； Redis集群已启动并运行。我通过在一台机器上设置值手动检查它显示在其他机器上。 我的问题是，当我关闭或停止任何一台主机上的redis server时，整个集群都会停止运
-
因此，如果我理解正确的话，在检测并重新启动失败代理的环境中运行Artemis代理集群将提供与运行每个活动服务器都与备份配对的集群相同的语义（以及类似的可用性）。对吗？
-
我注意到，当连接的Artemis节点宕机时，连接到节点2-4的客户机不会故障转移到其他3个可用的主节点，基本上不会发现其他节点。即使在原始节点恢复之后，客户端仍然无法建立连接。我从一个单独的堆栈溢出帖子中看到，不支持主到主故障转移。这是否意味着对于每个主节点，我也需要创建一个从节点来处理故障转移？这是否会导致两个实例点失败，而不是集群中有许多节点？ 在一个单独的基本测试中，使用一个主从两个节点的集
-
故障自动转移是指在 TiDB 集群的某些节点出现故障时，TiDB Operator 会自动添加一个节点，保证 TiDB 集群的高可用，类似于 K8s 的 Deployment 行为。 由于 TiDB Operator 基于 StatefulSet 来管理 Pod，但 StatefulSet 在某些 Pod 发生故障时不会自动创建新节点来替换旧节点，所以，TiDB Operator 扩展了 Stat
-
我们有一个mongodb副本集，其中包含两个实例（127.0.0.1:27017-主要，127.0.0.1:27018-次要）和一个仲裁器（127.0.0.1:27019）。当我使用rs.steppdown（60）从主实例中退出时，它应该成为辅助实例，辅助实例应该成为主实例，所有写操作都应该在辅助实例中发生（退出后的主实例）。但在卸任后，我遇到了一个异常“无法将数据写入传输连接：远程主机强制关闭了
-
null 当我使用Ctrl-C停止活动服务器时，从服务器报告的而断开连接，这是正确的，但是备份服务器没有更改其状态，也没有侦听端口61617。那么我在配置中做错了什么呢？ 实时服务器配置： 备份服务器配置：