理解因果集群规模伸缩
安全地缩小因果集群规模的能力，为实例故障提供了更高的鲁棒性，前提是在故障发生时我们仍能保持法定人数。
在 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。离线实例即使不可用，仍被视为集群的成员。
-
在 3 个实例中只有 2 个在线的情况下，如果另一个实例发生故障，我们将失去法定人数和写入能力。
-
如果添加了不同的核心实例，它仍然可以被投票加入，因为我们仍然有 2 个实例达到法定人数。
此页面有帮助吗？