[SERVER-2603] command to resize capped collection (offline oplog size increase) Created: 21/Feb/11 Updated: 06/Dec/22 Resolved: 08/Feb/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication, Storage |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Eliot Horowitz (Inactive) | Assignee: | Backlog - Replication Team |
| Resolution: | Duplicate | Votes: | 5 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Assigned Teams: |
Replication
|
||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||
| Description |
|
If a mongod is started with a different oplog size, we do a full clone of the db with a new oplog size. |
| Comments |
| Comment by Mathias Stearn [ 07/Nov/12 ] |
|
Revision to previous comment: The new plan is to add a command, tentatively invoked as: {resizedCappedCollection:COLLECTION_NAME, size:NEW_SIZE}. For now it will only support growing a collection and will error out if NEW_SIZE < CURRENT_SIZE [1]. It will move the oldest documents in the current extent to the end of the new space, meaning that the new capacity is available immediately after the commend completes and that no more documents will be aged-out from the time the command starts until the new space has been filled. [1] An alternative idea would be to use growTo:NEW_SIZE and possibly add a shrinkTo:NEW_SIZE latter so it is more explicit. |
| Comment by Mathias Stearn [ 05/Nov/12 ] |
|
There are a few ways to go with this. My current plan is to add new extents to the collection, but not move existing data. Old documents will continue to be overwritten until the new extents are reached. This means it should be ok to run on an online server since it won't block for too long, but it does mean that it can't be used to buy more time in an emergency with a lagging member. If we decide the latter functionality is needed, it can be added later. |
| Comment by Eliot Horowitz (Inactive) [ 09/May/11 ] |
|
Yes, timely. YOu will have to take a slave down, but shouldn't entail downtime. |
| Comment by Jason R. Coombs [ 27/Apr/11 ] |
|
With this feature, would it be possible to grow the oplog in a timely fashion without invalidating the slaves (as the Halted Replication docs prescribe)? Even better would be a feature to grow the oplog without downtime. |