[
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)
