[DOCS-792] Documentation incorrect regarding RS configuration members Created: 26/Nov/12 Updated: 30/Oct/23 Resolved: 26/Nov/12 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | manual |
| Affects Version/s: | None |
| Fix Version/s: | Server_Docs_20231030 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Jed Smith | Assignee: | Sam Kleinman (Inactive) |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: | |
| Days since reply: | 11 years, 12 weeks, 2 days ago |
| Description |
|
There are numerous cases here: http://docs.mongodb.org/manual/administration/replica-sets/ Where the _id of a member and its index in the rs.conf().members array are conflated (they are not equivalent). As an example, here is a live configuration on one of our replica sets:
I cannot index that replica by its _id, 109:
That is instead me asking for the 110th member of the members array. I only saw those errors on the given page, so I'm not sure if it's a systemic misunderstanding and repeated elsewhere; the root assumption seems to be that index in the members array will always match _id, which isn't the case in any of our sets for various reasons. |
| Comments |
| Comment by auto [ 27/Nov/12 ] |
|
Author: {u'date': u'2012-11-26T19:48:58Z', u'email': u'samk@10gen.com', u'name': u'Sam Kleinman'}Message: |
| Comment by auto [ 27/Nov/12 ] |
|
Author: {u'date': u'2012-11-26T17:11:41Z', u'email': u'samk@10gen.com', u'name': u'Sam Kleinman'}Message: |
| Comment by Jed Smith [ 26/Nov/12 ] |
|
Three still there, though I see the two new notes. > After re-configuring the set, the member with the _id of 0 has a priority of 0 so that it cannot become primary. > After the replica set reconfigures, the set member with the _id of 0 has a priority of 0 and cannot become primary. > This sequence gives 0 votes to set members with the _id values of 3, 4, and 5. |
| Comment by Sam Kleinman (Inactive) [ 26/Nov/12 ] |
|
fixed in public, will merge into upstream later this week. |