[DOCS-1488] Need clarification for voting internals of replica sets Created: 06/May/13  Updated: 30/Oct/23  Resolved: 08/May/13

Status: Closed
Project: Documentation
Component/s: manual
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Task Priority: Major - P3
Reporter: Alexander Komyagin Assignee: Sam Kleinman (Inactive)
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

http://docs.mongodb.org/manual/core/replication-internals/#election-internals


Participants:
Days since reply: 10 years, 41 weeks, 1 day ago

 Description   

To avoid confusion we need additional clarification on how our voting system works [checked with 2.4.2]:

In order for the node to be elected as PRIMARY in a replica set, it needs to collect just a majority of votes (not the votes from the majority of nodes).

That being said, if you have 3-node replica set with votes

{15,1,1}

and eventually it becomes split:

{15}

|

{1,1}

- then the one with 15 votes will elect himself as PRIMARY, and both 1-vote members will be SECONDARIES.
And if instead of 15 you give the same node only 2 votes - there will be NO PRIMARY after split, because no node can get the majority [of votes].

So users can think of additional votes for the server like they are just another mongod arbiter processes who share the same hardware with that server and vote altogether.

Also I think that we could benefit from adding these links (or at least some additional info from them) to the page:
http://openmymind.net/2012/1/7/Does-My-Replica-Set-Need-An-Arbiter/
http://www.kchodorow.com/blog/2012/01/04/replica-set-internals-bootcamp-part-i-elections/



 Comments   
Comment by auto [ 07/May/13 ]

Author:

{u'date': u'2013-05-07T14:25:08Z', u'name': u'Sam Kleinman', u'email': u'samk@10gen.com'}

Message: DOCS-1488: majority of set for elections is vote-based.
Branch: master
https://github.com/mongodb/docs/commit/8609ed0a204dd0d0d10c143fbe80477f1f89969f

Generated at Thu Feb 08 07:41:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.