集群在创建和运行时的规模演示

因果集群在创建时的最小核心大小

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

以下示例显示了一个具有 causal_clustering.minimum_core_cluster_size_at_formation=3 的 5 个核心集群。核心 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://localhost:7688,http://localhost:7460,https://localhost:7461, groups=[], database=default,
refuseToBeLeader=false}}, {memberId=MemberId{3811e9ed}, info=CoreServerInfo{raftServer=localhost:7000,
catchupServer=localhost:6000, clientConnectorAddresses=bolt://localhost:7687,http://localhost:7474,https://localhost: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://localhost:7689,http://localhost:7476,https://localhost: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 上的唯一有效区别是，当我们只剩下 1 个可操作节点（在缩减到集群大小为 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 设置为小于核心总数的值。

此页面是否有用？

知识库

集群在创建和运行时的规模演示