[ https://issues.apache.org/jira/browse/KAFKA-7335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16591871#comment-16591871 ]
Jason Gustafson commented on KAFKA-7335: ---------------------------------------- [~badai] That is one possibility. I was thinking it would be advantageous to have the cluster identity stored in the log directory with the data since it is less likely to be mistakenly altered. A server config for the clusterId could be incorrectly specified just like the zookeeper connect string, so I'm not sure there's a strong advantage to having one. I think it's the association of the data with the cluster that we need to protect. > Store clusterId locally to ensure broker joins the right cluster > ---------------------------------------------------------------- > > Key: KAFKA-7335 > URL: https://issues.apache.org/jira/browse/KAFKA-7335 > Project: Kafka > Issue Type: Improvement > Reporter: Jason Gustafson > Priority: Major > > We have seen situations where a broker somehow got the wrong configuration > and joined a different cluster than the one it was previously registered in. > This can create various kinds of metadata inconsistencies in the cluster and > can be difficult to debug. It was suggested in > [KIP-78|https://cwiki.apache.org/confluence/display/KAFKA/KIP-78%3A+Cluster+Id] > that we could store the clusterId locally after initial registration and > verify upon startup that the locally stored value matches what is in > zookeeper. -- This message was sent by Atlassian JIRA (v7.6.3#76005)