[SERVER-28872] remove ClusterRepairDatabaseCmd from mongos Created: 19/Apr/17  Updated: 30/Oct/23  Resolved: 01/May/17

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.5.6
Fix Version/s: 3.5.7

Type: Task Priority: Major - P3
Reporter: Esha Maharishi (Inactive) Assignee: Esha Maharishi (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Backports
Documented
Duplicate
is duplicated by SERVER-2352 mongos should not take the repairData... Closed
Related
is related to SERVER-35580 remove ReIndexCmd from mongos Closed
Backwards Compatibility: Minor Change
Backport Requested:
v3.4
Sprint: Sharding 2017-05-08
Participants:

 Comments   
Comment by Esha Maharishi (Inactive) [ 01/May/17 ]

osmar.olivo ok, closing the backport ticket. I agree it makes more sense not to backport.

Comment by Githook User [ 01/May/17 ]

Author:

{u'username': u'EshaMaharishi', u'name': u'Esha Maharishi', u'email': u'esha.maharishi@mongodb.com'}

Message: SERVER-28872 remove ClusterRepairDatabaseCmd from mongos
Branch: master
https://github.com/mongodb/mongo/commit/71f6003599e15d6f1be1bb7a0803fa3af248225d

Comment by Esha Maharishi (Inactive) [ 25/Apr/17 ]

osmar.olivo kaloian.manassiev, do we want to backport this to 3.4?

Comment by Osmar Olivo [ 20/Apr/17 ]

Agree repairDatabase does not make sense when ran via mongos. However, it should still be allowed to run on secondaries directly in order to allow rolling-compacts without impacting a primary.

Comment by Kaloian Manassiev [ 19/Apr/17 ]

The standalone 'repairDatabase' command implementation is allowed to run on secondary so that secondary replica set nodes can be repaired or compacted without having to make them primary. However, allowing slaveOK in a sharded cluster doesn't make any sense because there is no way to know exactly to which shard node the command will be directed.

Furthermore, repairing a database takes Global X lock and stops all activity, and in my opinion is an operation which should not be supported through mongos out of a risk of stalling the entire cluster.

How about we completely remove it from mongos? osmar.olivo/alyson.cabral - do you see any problems with that?

Generated at Thu Feb 08 04:19:17 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.