[SERVER-3747] Maintenance mode writability for replica set secondaries Created: 01/Sep/11  Updated: 06/Dec/22

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

Type: Improvement Priority: Minor - P4
Reporter: Richard Kreuter (Inactive) Assignee: Backlog - Replication Team
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-13355 Error if replica set member is starte... Closed
Assigned Teams:
Replication
Participants:

 Description   

Right now, many sorts of operational scenarios for working around bugs or limitations or operator errors require restarting replica set members without --replSet in order to be able to write some collections. This is kind of cumbersome for normal people. If some kind of online maintenance mode could allow users to write to the replicating secondary (possibly pausing replication for the duration of the maintenance), that would make these scenarios easier for people to work with.

Things I'm thinking of:

  • resizing the oplog
  • fixing a replica set configuration if the member doesn't like it and goes into a bad state
  • (maybe) building indexes on secondaries, so that not all secondaries in a set get their index build commands at the same time


 Comments   
Comment by Sheeri Cabral (Inactive) [ 10/Oct/19 ]

Linking the PM ticket for a unified "drain" (unlading) mode.

Comment by Scott Hernandez (Inactive) [ 17/Sep/14 ]

Another option would be to have a wrapper/umbrella command which turns on maintenance, runs the supplied commands and turns off maint. mode when successful.

We could probably just add options to the existing maintenance command, replSetMaintenance:

> var tasks = [{replSetPauseReplication:1}, {createIndex...}, {resizeOplog:...}, ... {replSetResumeReplication:1}];
> rs.maintenance(tasks)
> db.adminCommand({replSetMaintenance:1, tasks: tasks})

This ensures that only those commands would be allowed to run and not any/all externally sent commands if any command was allowed to be run on secondary.

Comment by Eliot Horowitz (Inactive) [ 03/Sep/11 ]

I really like the way compact works.

You run compact, it first changes state to recovering, does compact, turns into secondary again.

So I could imagine that sort of api

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