知识库

形成和运行时集群大小的演示

因果集群形成时的最小核心大小

causal_clustering.minimum_core_cluster_size_at_formation 定义为形成集群最初所需的核心机器的最小数量。当至少有这么多核心成员相互发现时，集群将形成。

以下示例展示了一个 5 核心集群，其中 causal_clustering.minimum_core_cluster_size_at_formation=3。核心 1 和 2 被初始化，并按如下所示进行第一次选举

2019-03-31 14:14:22.028+0000 INFO [o.n.c.n.Server] raft-server: bound to 127.0.0.1:7000
2019-03-31 14:14:22.038+0000 INFO [o.n.c.d.CoreMonitor] Waiting for a total of 3 core members...
2019-03-31 14:14:30.910+0000 INFO [c.n.c.d.SslHazelcastCoreTopologyService] Cluster discovery service started
2019-03-31 14:14:30.955+0000 INFO [c.n.c.d.SslHazelcastCoreTopologyService] Core topology changed {added=[{memberId=
MemberId{fb0bc6e1}, info=CoreServerInfo{raftServer=localhost:7001, catchupServer=localhost:6001,
clientConnectorAddresses=bolt://:7688,https://:7460,https://:7461, groups=[], database=default,
refuseToBeLeader=false}}, {memberId=MemberId{3811e9ed}, info=CoreServerInfo{raftServer=localhost:7000,
catchupServer=localhost:6000, clientConnectorAddresses=bolt://:7687,https://:7474,https://:7470,
groups=[], database=default, refuseToBeLeader=false}}], removed=[]}
2019-03-31 14:14:30.956+0000 INFO [o.n.c.c.c.m.RaftMembershipManager] Target membership: [MemberId{fb0bc6e1},
MemberId{3811e9ed}]
2019-03-31 14:14:31.022+0000 INFO [o.n.c.d.CoreMonitor] Discovered core member at localhost:5001
2019-03-31 14:14:32.099+0000 INFO [o.n.c.d.CoreMonitor] Waiting for a total of 3 core members...
2019-03-31 14:14:42.141+0000 INFO [o.n.c.d.CoreMonitor] Waiting for a total of 3 core members...
2019-03-31 14:14:52.188+0000 INFO [o.n.c.d.CoreMonitor] Waiting for a total of 3 core members...
2019-03-31 14:15:02.225+0000 INFO [o.n.c.d.CoreMonitor] Waiting for a total of 3 core members..

核心 3 现在加入，集群成功形成

2019-03-31 14:15:02.225+0000 INFO [o.n.c.d.CoreMonitor] Waiting for a total of 3 core members...
2019-03-31 14:15:12.281+0000 INFO [o.n.c.d.CoreMonitor] Waiting for a total of 3 core members...
2019-03-31 14:15:22.287+0000 INFO [o.n.c.d.CoreMonitor] Discovered core member at localhost:5002
2019-03-31 14:15:22.298+0000 INFO [c.n.c.d.SslHazelcastCoreTopologyService] Core topology changed
{added=[{memberId=MemberId{9274358d}, info=CoreServerInfo{raftServer=localhost:7002, catchupServer=localhost:6002,
clientConnectorAddresses=bolt://:7689,https://:7476,https://:7472, groups=[], database=default,
refuseToBeLeader=false}}], removed=[]}
2019-03-31 14:15:22.568+0000 INFO [o.n.c.d.CoreMonitor] This instance bootstrapped the cluster.

因果集群运行时的最小核心大小

causal_clustering.minimum_core_cluster_size_at_runtime 定义为动态调整的投票集（只有核心成员才能成为其中的一部分）的最小大小。投票集的调整会随着核心成员可用性的变化而自动发生，这可能是由于显式操作（如启动或停止成员）或意外问题（如网络分区）造成的。请注意，这种投票集的动态缩放通常是可取的，因为在某些情况下，它可以增加可容忍的实例故障数量。在投票加入或排除成员之前，投票集中的大多数成员必须可用。

让我们在一个 3 节点集群上尝试 causal_clustering.minimum_core_cluster_size_at_runtime=2。如果我们失去一个核心，集群仍然具有共识，并且可以缩减到 2。但是如果我们再失去 1 个，我们就只剩下一个节点，并且缺乏共识，所以无法缩减，我们正在等待刚刚失败的节点再次变得可用。此时，如果 3 个节点中第一个失败的节点重新上线，它无法重新添加到集群中，因为我们缺乏共识来将其重新添加。我们只能等待最后一个失败的节点。

在下面的示例中，核心 1（领导者）看到核心 3 离开集群，如下所示

2019-03-31 15:10:31.234+0000 WARN [o.n.c.d.CoreMonitor] Lost core member at localhost:5002

此时，集群仍对领导者核心 1 执行的写入操作具有仲裁。但在随后的 causal_clustering.leader_election_timeout（默认 7 秒）期限后，核心 3 被从集群中移除，原因是因为运行时集群大小设置为 2。

如果此时我们将核心 2 也脱机，集群将变为只读

2019-03-31 15:11:08.005+0000 INFO [o.n.c.c.c.s.RaftState] Leader changed from MemberId{e7f79e48} to null
2019-03-31 15:11:08.006+0000 INFO [o.n.c.c.c.s.RaftLogShipper] Stopping log shipper MemberId{a2ef543b}[matchIndex: 5,
lastSentIndex: 5, localAppendIndex: 5, mode: PIPELINE]

然而，如果我们现在在添加核心 2 *之前*重新添加核心 3，我们仍然会得到两个处于*跟随者*状态的核心，导致集群只读，并且我们在核心 1 的日志中看到以下内容

2019-03-31 15:12:06.251+0000 DEBUG [o.n.c.c.c.RaftMachine] Should vote for raft candidate false: requester log up to date:
false (request last log term: 1, context last log term: 1, request last log index: 1, context last append: 5) voted for other
in same term: false (request term: 1, context term: 1, voted for another: false)

并且写入事务导致以下异常

Neo.ClientError.Cluster.NotALeader
Neo.ClientError.Cluster.NotALeader: No write operations are allowed directly on this database. Writes must pass through the
leader. The role of this server is: FOLLOWER

直到核心 2 重新添加后，这三个核心才能再次形成一个可写入的集群

2019-03-31 15:13:04.377+0000 INFO [o.n.c.c.c.RaftMachine] Election started with vote request: Vote.Request from
MemberId{e7f79e48} {term=2, candidate=MemberId{e7f79e48}, lastAppended=5, lastLogTerm=1} and members: [MemberId{a2ef543b},
MemberId{e7f79e48}]
2019-03-31 15:13:04.377+0000 INFO [o.n.c.c.c.RaftMachine] Moving to CANDIDATE state after successful pre-election stage
2019-03-31 15:13:04.384+0000 INFO [o.n.c.c.c.RaftMachine] Moving to LEADER state at term 2 (I am MemberId{e7f79e48}), voted
for by [MemberId{a2ef543b}]
2019-03-31 15:13:04.384+0000 INFO [o.n.c.c.c.s.RaftState] First leader elected: MemberId{e7f79e48}

然而，如果我们坚持使用默认的运行时集群大小 3，那么集群就无法缩减到 2（第一个失败的节点不会被投票出局），但我们将保持共识和写入能力。但是，当第二个节点失败并且我们只剩 1 个节点时，我们就会失去共识和写入能力，就像前面的场景一样，但如果两个失败的节点中的任何一个重新上线，而不仅仅是最近失败的节点，我们就能够重新获得共识和写入能力。

总之，将 minimum_core_cluster_size_at_runtime 设置为 2 而不是默认的 3，唯一有效的区别是，当我们只有一个操作节点（在缩减到集群大小 2 之后），我们必须等待刚刚失败的节点重新上线，而在此之前失败的节点无法重新加入，因为向集群添加“新”节点需要共识。

因此，当基础/静态集群规模较大（例如 5 个节点）时，设置较小的 minimum_core_cluster_size_at_runtime 是一种更相关的优化。在这种情况下，将 minimum_core_cluster_size_at_runtime 设置为 3 而不是 5，允许集群在失去写入能力之前容忍 3 个故障，而不是 2 个，即*前提是*这 3 个故障发生的速度不要快于集群能够将故障成员投票出局的速度（causal_clustering.leader_election_timeout）。使用 2 而不是默认的 3 不会影响在 3 个节点中容忍 1 个故障的能力。然而，通常没有充分的理由将其设置为 2。但是，在 5 个或更多节点的集群中，可以将 minimum_core_cluster_size_at_runtime 设置为小于核心总数的值。

© . All rights reserved.