[
https://issues.apache.org/jira/browse/ZOOKEEPER-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15854717#comment-15854717
]
Benjamin Reed commented on ZOOKEEPER-27:
----------------------------------------
had the joy of running into this problem today. this issue was prematurely
closed.
> Unique DB identifiers for servers and clients
> ---------------------------------------------
>
> Key: ZOOKEEPER-27
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-27
> Project: ZooKeeper
> Issue Type: New Feature
> Components: c client, java client, server
> Reporter: Patrick Hunt
> Assignee: Mahadev konar
> Fix For: 3.0.0
>
>
> Moved from SourceForge to Apache.
> http://sourceforge.net/tracker/index.php?func=detail&aid=1937075&group_id=209147&atid=1008547
> here is the text from sourceforge:
> There should be a persistent unique identifier for an instance of ZooKeeper.
> Currently, if you bring a cluster down without stopping clients and
> reinitialize the servers, the servers will start logging client zxid errors
> because the clients have seen a later transaction than the server has. In
> reality the clients should detect that they are now talking to a new instance
> of the database and close the session.
> A similar problem occurs when a server fails in a cluster of three machines,
> and the other two machines are reinitialized and restarted. If the failed
> machine starts up again, there is a chance that the old machine may get
> elected leader (since it will have the highest zxid) and overwrite new data.
> A unique random id should probably get generated when a new cluster comes up.
> (It is easy to detect since the zxid will be zero.) Leader Election and the
> Leader should validate that the peers have the same database id. Clients
> should also validate that they are talking to servers with the same database
> id during a session.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
