[SERVER-11540] db.repairDatabase() doesn't work on Secondarys Created: 04/Nov/13 Updated: 10/Dec/14 Resolved: 07/Mar/14 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | 2.4.6 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Steffen | Assignee: | Unassigned |
| Resolution: | Duplicate | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Environment: |
3.2.0-54-generic #82-Ubuntu SMP Tue Sep 10 20:08:42 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux |
||
| Issue Links: |
|
||||||||||||
| Operating System: | ALL | ||||||||||||
| Steps To Reproduce: | On primary create DB with test collection.
On secondary go to DB an try to run Repair command
|
||||||||||||
| Participants: | |||||||||||||
| Description |
|
We try to run Repair in our ReplicaSet to improve disk usage. If we try to run repair on a secondary we receive an error:
We used the mongo shell and set rs.slaveOk(). We also wrote a python script to do this task, which fails with the same Error. Some more debugging:
We ran the createCollection command on the Primary before as well, but still don't see the namespace in the listing.
|
| Comments |
| Comment by Kevin J. Rice [ 14/Mar/14 ] |
|
I'd like to upvote what Eric Milkie said. That is, the concept of making repairDatabase() work like compact(). I'm having to script a solution to repairDatabase() so I can reclaim disk space. Doing this via a script requires, for each of our 48 shards running on 4 different boxes:
Obviously, just being able to connect to a secondary and run db.repairDatabase() would be FAR easier. |
| Comment by Eric Milkie [ 05/Mar/14 ] |
|
We could make repairDatabase() work the same way that compact() does on secondaries, by setting maintenance mode. |
| Comment by Steffen [ 04/Nov/13 ] |
|
We would like to be able to run repair on secondarys. If we run the repair on the primary, the primary would go into maintenance and a fail over will happen. Another secondary will be elected as primary. Thus the old primary becomes a secondary repairing the database. |
| Comment by J Rassi [ 04/Nov/13 ] |
|
> But I don't see the point to be able to do it just on a primary in a repset, which will become a secondary. Thus, how can I change this to a feature request? Can you explain more the behavior you'd like to see? I'm not able to understand exactly what you mean. |
| Comment by Steffen [ 04/Nov/13 ] |
|
Hello. I see that it makes sense for a single host. But I don't see the point to be able to do it just on a primary in a repset, which will become a secondary. Thanks |
| Comment by J Rassi [ 04/Nov/13 ] |
|
Running write operations on secondaries is disallowed. See the repairDatabase documentation: "to run repair on a secondary/slave restart the instance in standalone mode without the --replSet or --slave options." See the rolling index build tutorial for more detailed instructions on temporarily bringing a replica set member into standalone mode. |