[DOCS-12763] Document the replSetStepUp admin command Created: 30/May/19  Updated: 30/Oct/23  Resolved: 30/May/19

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

Type: Improvement Priority: Major - P3
Reporter: Dan Dascalescu Assignee: Unassigned
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 4 years, 36 weeks, 6 days ago
Epic Link: DOCSP-1769

 Description   

Description

In a rs, I was trying to force the secondary I was connected to, to become primary. The process listed at https://docs.mongodb.com/manual/tutorial/force-member-to-be-primary/#force-a-member-to-be-primary-using-database-commands seem unnecessarily laborious when one can simply run one command:

 

rs:SECONDARY> db.adminCommand({replSetStepUp: 86400, force: 1})
{ "ok" : 1, ... }
rs:PRIMARY> 

 

 

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Ravind Kumar (Inactive) [ 30/May/19 ]

Hi dandv,

replSetStepUp was designed for use by the primary as part of the stepdown procedure.  Once the primary safely steps down, it does a handoff to the appropriate secondary. This flow prevents a two-primary scenario.

Running replSetStepUp directly from a secondary doesn't trigger a simultaneous stepdown of the existing primary, allowing for a transient multi-primary deployment. This increases the risk of rollbacks.

We generally don't document commands that are designed for use in a strictly internal context, even if they are user-discoverable. While the existing procedure for temporarily promoting a specific secondary to primary requires more than a single command, it has significantly lower risk. That said, you are welcome to open a SERVER ticket requesting optimizations to replSetStepUp for the purpose of supporting this use case.

Generated at Thu Feb 08 08:06:02 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.