[SERVER-14424] RID is not a sufficiently unique identifier Created: 02/Jul/14 Updated: 14/Apr/16 Resolved: 06/Feb/15 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Matt Dannenberg | Assignee: | Matt Dannenberg |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Steps To Reproduce: | create 3 node replset on a single machine |
||||||||||||
| Participants: | |||||||||||||
| Description |
|
RIDs can overlap, masking one node's replication progress and failing to correctly report write concern (under counting the number of nodes who have received the write). RIDs can be replaced when not entirely necessary. If a node changes its hostname, it will choose a new RID. This can result in its replication progress being reported to the primary as two different nodes, resulting in falsely satisfied write concerns. Current proposal: use a combination of config version and _id from that config to uniquely identify nodes instead |
| Comments |
| Comment by Matt Dannenberg [ 06/Feb/15 ] |
|
In 3.0, we will favor the usage of config version + memberID from that config over the RID, but leave in RID for backwards compatibility. In 3.2 (3.1 dev), RID will be removed entirely from the replica set code path, but left in for master slave since master slave does not have configs. |