了解因果集群大小扩展
能够安全地缩减因果集群的大小使我们能够在实例出现故障时获得更高的稳健性，前提是我们保持故障发生时的法定人数。
在 3.4 之前，我们使用单个配置属性来定义形成时所需的最小核心集群大小和缩减时所需的最小集群大小。
causal_clustering.expected_core_cluster_size
从 3.4 开始，上述配置属性已被弃用，其行为已分为 2 个配置属性。
causal_clustering.minimum_core_cluster_size_at_formation
和
causal_clustering.minimum_core_cluster_size_at_runtime
虽然第一个（形成所需的集群核心大小）很容易理解，但运行时的最小核心集群大小并不简单，需要了解一些关于 raft 共识和集群大小扩展的知识。
在继续之前，应该注意的是，causal_clustering.minimum_core_cluster_size_at_runtime 的默认值为 3，这对于大多数集群部署来说已经足够了，并且能够最大限度地安全地缩减集群大小。只有在非常特殊的跨数据中心需求或特殊情况下，才需要使用不同的值。
Raft 中的共识操作
因果集群使用 Raft 共识协议，该协议要求大多数核心集群实例才能执行大多数集群操作。
这是一个易于理解的 Raft 中分布式共识操作的直观演练。
虽然这通常被理解为适用于对集群的提交，但这同样适用于集群成员的投票（进出）。
-
接受新成员加入集群需要法定人数。
-
将集群成员投票出去需要法定人数。
这两者都会改变核心集群成员的运行时大小，可能改变法定人数所需的核心集群成员数量，从而改变集群在失去法定人数（和写入能力）之前可以容忍的故障数量。
将新成员投票到集群中
第一点应该很容易理解。
这也是为什么如果一个集群失去法定人数（和写入能力），我们无法通过动态地向集群添加新成员来恢复它：需要在线集群成员的法定人数才能将新集群成员投票进来。
恢复法定人数的唯一方法是恢复足够多的那些脱机实例（但由于失去法定人数而没有被投票出集群）。
将集群成员投票出去并缩减集群
第二点稍微复杂一些。
将集群成员投票出去的行为（至少是尝试）发生在所有情况下，无论是计划的还是意外的，只要核心集群实例不再参与集群，就会发生。
这可能是对该实例上的 Neo4j 进行关闭或重启的响应，其中实例告诉集群的其他部分它将要离开，或者更意外的情况是实例被终止（或者可能存在网络问题），并且实例心跳没有在预期的超时时间间隔内收到，集群的发现服务确定该实例处于脱机状态。
在这一点上，如果我们当前没有达到 minimum_core_cluster_size_at_runtime，集群将尝试将该实例从集群中投票出去，并且只有在核心集群实例的法定人数在线时才能通过。
如果存在法定人数，则该实例会被投票出去，核心集群大小会相应地缩减，从而改变法定人数所需的内核实例数量。
如果不存在法定人数，或者我们处于 minimum_core_cluster_size_at_runtime，投票将不会进行，我们无法将该实例投票出去，尽管它可能处于脱机状态，但就 Raft 而言，我们无法缩减集群大小，因此法定人数所需的数字将不会改变，集群可以容忍的故障数量也不会改变。
3 个节点的集群和最小集群大小为 3 的示例
causal_clustering.minimum_core_cluster_size_at_runtime 的默认值为 3。
这意味着，当我们达到 3 个节点的集群大小并且丢失一个实例时，我们就无法进一步缩减集群。
-
如果这 3 个核心集群实例中的一个脱机，即使我们有 2 个实例的法定人数，也不会进行删除该实例的投票。
-
集群大小将保持在 3 并且不会缩减到 2。脱机实例仍然被认为是集群的成员，即使它不可用。
-
只有 2 个实例在线，如果另一个实例出现故障，我们将失去法定人数和写入能力。
-
如果添加了不同的核心实例，它仍然可以被投票进来，因为我们仍然有 2 个实例的法定人数。
此页面是否有帮助？