[SERVER-5788] primary stepdown on reconfig isn't needed in some cases Created: 08/May/12  Updated: 10/Dec/14  Resolved: 10/Oct/14

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Greg Studer Assignee: Spencer Brody (Inactive)
Resolution: Duplicate Votes: 9
Labels: elections
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
depends on SERVER-15160 TopologyCoordinatorImpl should not al... Closed
Duplicate
is duplicated by SERVER-6752 Do not close all connections on repli... Closed
is duplicated by SERVER-7833 mongos need restart after rs.remove Closed
Related
Backwards Compatibility: Minor Change
Operating System: ALL
Participants:

 Description   

... which leads to connections being broken unnecessarily.

One such case - if a majority of members are unchanged and the primary is one of the unchanged members. Ex: one secondary node out of a three-node replica set goes bad and we want to replace it with another good node. If that node being down doesn't require a stepdown, then the node changing shouldn't either?



 Comments   
Comment by Spencer Brody (Inactive) [ 10/Oct/14 ]

Dupe of SERVER-15160

Comment by Quentin Schroeder [ 29/Apr/14 ]

This issue has been problematic for us as well, it would be ideal if removing a secondary member didn't cause all connections to drop.

Comment by Matt Brennan [ 03/Apr/14 ]

This would be an incredibly helpful feature.

Comment by Jeremy [ 27/Dec/13 ]

Same here: rs.remove() triggering an election is disruptive. https://groups.google.com/forum/#!msg/mongodb-user/SVqx5MikVfE/wvKjTCMZzqoJ

Comment by Michael Tewner [ 02/Sep/12 ]

This is also an issue by us. Like other DB systems, removal of a secondary should not affect the operation of the primary.

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