[
https://issues.apache.org/jira/browse/ZOOKEEPER-2476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15380391#comment-15380391
]
Alexander Shraer commented on ZOOKEEPER-2476:
---------------------------------------------
Non-voting follower is what happens if you connect a participant to a leader,
for example, with the intention to add it to the cluster. Logically he's not
yet part of the cluster. But it does act as a follower - votes on commits, etc.
His votes don't count when the leader gathers a majority of votes. This is
something that exists in 3.4 and in fact I remember that such server's votes
were actually counted, which was a bug. I just exploited this for the purpose
of adding new servers. Non-voting followers, just like followers, waste the
leader's bandwidth.
Observers get and send only part of the messages - no voting is going on, they
just listen to commits, and when they come they update their in-memory
database, from which they serve requests. So if you need 10 servers to
withstand client requests, you don't need all of them to be voters - having 5
of them be observers is much more efficient in terms of not wasting the
leader's bandwidth.
> Why can't ZK do this for me?
To do this, we'd need to have observers receive a reconfig request and vote for
it, which they never do otherwise. I chose not to implement it for simplicity -
the changes were already extensive enough and its simple enough to issue two
reconfigs in this case.
> Not possible to upgrade via reconfig a Participant+Observer cluster to a
> Participant+Participant cluster
> --------------------------------------------------------------------------------------------------------
>
> Key: ZOOKEEPER-2476
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-2476
> Project: ZooKeeper
> Issue Type: Bug
> Components: quorum, server
> Affects Versions: 3.5.1
> Reporter: Jordan Zimmerman
> Assignee: Alexander Shraer
> Priority: Critical
> Attachments: ZOOKEEPER-2476.patch
>
>
> Contrary to the documentation, it is not possible to upgrade via reconfig a
> Participant+Observer cluster to a Participant+Participant cluster.
> KeeperException.NewConfigNoQuorum is thrown instead.
> PrepRequestProcessor should recognize this special case and let it pass. Test
> will be enclosed shortly. I'll work on a fix as well, but I imagine that
> [~shralex] will want to look at it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
