[
https://issues.apache.org/jira/browse/ZOOKEEPER-2031?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14134786#comment-14134786
]
some one commented on ZOOKEEPER-2031:
-------------------------------------
I just thought about another scenario where the tag would be useful.
Let's say we have servers a and b, they are joined together, so the zk config
looks like:
server.1=<a's ip-port config>;<a-uuid>
server.2=<b's ip-port config>;<b-uuid>
Now lets say the machine server.1 <a> is on, is permanently destroyed, but b
doesn't update it's config to remove server.1 yet.
Now lets spin up server c, whose config looks like:
server.1=<c (same ip-port config as a above)>;<c-uuid>
Currently, when server c starts up, server b will immediately sync with c,
thinking that it is server a.
Server c's config gets overridden with server b's view of the config and
effectively now acts as a replacement for server a.
This is an undesirable behavior that could be fixed by having server c verify
that the config received from server b doesn't actually match up (by checking
<c-uuid> != <a-uuid>).
I've been looking to see where I could put this check and so far, it looks like
FastLeaderElection:run() (right before self.processReconfig) or even
QuorumPeer:processReconfig() itself would be the best place to put it. Also,
once we have this check, what would be the best course of action to deal with
this issue? Would we just ignore the received message in FastLeaderElection?
> Support tagging a QuorumServer
> ------------------------------
>
> Key: ZOOKEEPER-2031
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2031
> Project: ZooKeeper
> Issue Type: Improvement
> Components: server
> Reporter: some one
> Assignee: some one
> Fix For: 3.5.1, 3.6.0
>
> Attachments: ZOOKEEPER-2031.patch
>
>
> Currently ZooKeeper only allows using the server id which is an integer for
> identifying servers. For my (unavoidable) use case, there may be concurrent
> dynamic removes and adds of servers which may eventually have id collisions.
> When this occurs, there is no good way to determine if the server (given an
> id collision) that we want to remove is the right server.
> To support my use case, I propose that we add a tag field to the server
> string.
> For my specific use case, this tag field will be used to store a uuid as a
> string.
> So for example:
> server.1=127.0.0.1:1234:1236:participant;0.0.0.0:1237;743b9d23-85cb-45b1-8949-930fdabb21f0
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
