[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:
Depends
Duplicate
duplicates SERVER-22766 Dynamic oplog sizing for WiredTiger n... Closed
is duplicated by SERVER-3878 We do not allow resizing (drop+create... Closed
Related
Assigned Teams:
Replication
Participants:
Case:

 Description   

If a mongod is started with a different oplog size, we do a full clone of the db with a new oplog size.
We warn the user this is slow, and ctrl-c should be safe to kill it.
it just says "new oplog size detected: will make a new local database. this is a slow operation. to abort the migration, ctrl-c and run again with your old --oplogSize of ___".



 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.

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