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

3节点群集情况下的Hazelcast高可用性

云项禹
2023-03-14

我们使用Hazelcast IMDG作为内存网格。我们集群中的节点数是三个,我们有一个同步备份,并且集群是分区感知的。在这种情况下,我希望分布式映射将均匀分布在3个节点上(或多或少)。如果节点发生故障,领导层应转移到健康的节点(该节点具有丢失数据的同步备份)。如果对这个新分配的leader节点有写请求,那么应该将相同的分区同步复制到一个活动节点。这是否意味着在节点故障的情况下,应该复制大约三分之一的分布式映射,并且在复制期间,所有读取都会被阻止?如果三个节点中的一个在一次同步备份的情况下停机,直到大约三分之一的分发恢复,可用性会受到影响?

共有1个答案

范兴文
2023-03-14

如果某个节点宕机,集群将把备份分区升级到主分区。迁移将开始为这些新的主分区创建备份。请检查数据分区部分。

在迁移期间,不会阻止读取操作。只有在正在积极迁移的分区上阻止写入操作。由于分区是一个接一个地迁移的,因此对可用性的影响很小。

 类似资料:
  • 本文档介绍用 3 台服务器构建 Seafile 高可用集群的架构。这里介绍的架构仅能实现“服务高可用”,而不能支持通过扩展更多的节点来提升服务性能。如果您需要“可扩展 + 高可用”的方案,请参考Seafile 可扩展集群文档。 在这种高可用架构中包含3个主要的系统部件: Seafile 服务器:提供 Seafile 服务的软件 MariaDB 数据库集群:保存小部分的 Seafile 元数据,比如

  • 配置keepalived服务 在每个seafile后端节点上安装和配置 keepalived 来实现浮动 IP 地址。 CentOS 7: yum install keepalived -y 假设配置了两个seafile后台任务节点:background1、background2 在background1上修改 keepalived 配置文件(/etc/keepalived/keepalived.

  • 本文档提供一个可扩展、高可用的 Seafile 集群架构。这种架构主要是面向较大规模的集群环境,可以通过增加更多的服务器来提升服务性能。如果您只需要高可用特性,请参考3节点高可用集群文档。 架构" class="reference-link"> 架构 Seafile集群方案采用了3层架构: 负载均衡层:将接入的流量分配到 seafile 服务器上。并且可以通过部署多个负载均衡器来实现高可用。 Se

  • 这就是我如何开始我的3个Kafka节点: 动物园管理员和Kafka集群在独立测试时表现良好。 我的意思是,我可以连接到一个Zookeeper节点(比如zoo1),并创建一个zNode。我可以在之后停止节点(例如,docker停止zoo1),并且我仍然可以从Zookeeper集群中的任何其他节点查询znode。 我将收到一个未知的HostException: 但是,我确实需要Kafka集群能够充分发

  • 有什么方法可以确定已经附加到场景但设置为不可见的节点的边界(尤其是高度和宽度)吗? 我想仅在其宽度超过100px时才在屏幕上显示标签...但它始终为 0: sysout的结果:(还有n.getWidth()也好不到哪里去) BoundingBox[minX: 0.0, minY: 0.0, minZ: 0.0,宽度: 0.0,高度: 0.0,深度: 0.0, maxX: 0.0, maxY: 0.

  • 我在生产中的压缩策略是LZ4压缩。但我将其修改为Deflate 对于压缩更改,我们必须使用nodetool升级表来强制升级所有表上的压缩策略 但是,一旦在集群中的所有5个节点上完成升级命令,我的请求开始失败,包括读取和写入 问题被追踪到5个节点集群中的一个特定节点以及该节点上的一个特殊表。我的整个集群具有大致相同数量的数据和配置,但有一个节点特别出现故障是行为不端的 < code >节点工具状态的