[
https://issues.apache.org/jira/browse/RATIS-2029?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17821916#comment-17821916
]
Xinyu Tan commented on RATIS-2029:
----------------------------------
Hi, [~szetszwo]
The (A,B,C) and (B,C,D) are in different cluster. So it's possible that the ids
of A and D are the same.
This is mainly due to the fact that some users may have deployed multiple iotdb
clusters, but there may be some misconfiguration that causes such issues in the
logs. We were thinking of ways to detect nodes that were disrupting the cluster
earlier, because the id seemed to be in the same cluster
> Differentiate RaftPeerID among separate clusters
> ------------------------------------------------
>
> Key: RATIS-2029
> URL: https://issues.apache.org/jira/browse/RATIS-2029
> Project: Ratis
> Issue Type: Wish
> Reporter: Song Ziyang
> Priority: Minor
> Attachments: 18751709081632_.pic.jpg
>
>
> Scenario:
> Old cluster contained a RaftGroup G with peers (A, B, C).
> After shutting down old cluster, we started a new cluster which also
> contained a RaftGroup G with peers (B, C, D).
> A and D both have a same RaftPeerID 0.
> However, by mistake, A is not properly shut down and will still send out
> RequestVote RPCs. The new cluster group will consider A a member of the group
> since it has a valid raft peer id and *won't shut it down.* (see the logs, 0
> rejects a requestVote from peer 0)
> Currently we only identify a peer through \{peerId}@group-${groupId}. I am
> wondering if there's way to tell a peer's comm address in the requestVote log
> messages.
> cc [~tanxinyu]. Also what do you think [~szetszwo] ?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
