make the analyse startup check more understandable when build the cluster

[neuyilan]

No description provided.

[OneSizeFitsQuorum]

Current logic:
if one node finds all other nodes's config is consistent, then start server;
else if this node get some but not all reponse indicating their config are consistent and this node never find that there is a inconsistent node, then try to check in next turn.
else indicating there must be at lease one node's config is inconsistent with the cluster, then throw exception and stop server.

In my opinion, I think may be we can start server if quorum nodes return consistent check response, so that we can start cluster even one node will never come back after a node hang. Of course, we must ensure the inconsistent node can't join cluster, maybe we need some manual test to see whether a inconsistent node can join the cluster if we change totalNum from allnode.size() to allnode.size()/2 + 1.

In this commit, it seems that the startupCheck will perform next turn even it find a inconsistent node, but the cluster will never be establishd

[neuyilan]

Current logic:
if one node finds all other nodes's config is consistent, then start server;
else if this node get some but not all reponse indicating their config are consistent and this node never find that there is a inconsistent node, then try to check in next turn.
else indicating there must be at lease one node's config is inconsistent with the cluster, then throw exception and stop server.

In my opinion, I think may be we can start server if quorum nodes return consistent check response, so that we can start cluster even one node will never come back after a node hang. Of course, we must ensure the inconsistent node can't join cluster, maybe we need some manual test to see whether a inconsistent node can join the cluster if we change totalNum from allnode.size() to allnode.size()/2 + 1.

In this commit, it seems that the startupCheck will perform next turn even it find a inconsistent node, but the cluster will never be establishd

Thanks for your reply, In the beginning, I think we can build the cluster as long as the quorum nodes start successful, in the end, I think in the init building of the cluster, it's ok to make sure that all seed nodes start successful, then the cluster can build success, if some seed nodes do hang, we can remove it from the seed nodes. So I think the initial design logic is ok.

As for the commit, you're right, I misunderstanding the code, I prefer to change it to more comprehensible.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[mychaow]

LGTM