[DOCS-10544] Docs for SERVER-22766: Dynamic oplog sizing for WiredTiger nodes Created: 18/Jul/17 Updated: 13/Nov/23 Resolved: 24/Mar/23 |
|
| Status: | Closed |
| Project: | Documentation |
| Component/s: | Server |
| Affects Version/s: | None |
| Fix Version/s: | 3.5.10, 3.4.19, Server_Docs_20231030, Server_Docs_20231106, Server_Docs_20231105, Server_Docs_20231113 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Emily Hall | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||
| Days since reply: | 45 weeks, 5 days ago | ||||||||||||||||||||||||||||
| Epic Link: | DOCS: 3.6 Server | ||||||||||||||||||||||||||||
| Description |
Documentation Request Summary:A new command replSetResizeOplog allows changing oplog size on replica set members using the WiredTiger storage engine. Engineering Ticket Description:Proposed title: Dynamic oplog sizing of replica set Issue Status as of Jul 10, 2017 FEATURE DESCRIPTION VERSIONS RATIONALE This new feature bypasses the need for maintance and allows users to dynamically change the size of the oplog in MongoDB nodes running with the WiredTiger storage engine only (nodes running the MMAPv1 storage engine still need to follow the maintenance procedure linked above). OPERATION
The size of the oplog is displayed at deployment time in the logs as follows:
Users can change the size of the oplog with the replSetResizeOplog command, specifying a size in MB. For example:
The command above changes the oplog size to 16384 MB (16GB/17179869184 bytes). This operation is recorded in the logs as follows:
The output of the stats() command also reflects the change:
ADDITIONAL NOTES Original descriptionIt would be very, very handy to have a method to alter the oplog size for an entire replicaset at the same time. That is, issue a command on the primary, it expands its oplog size, and the changes trickle down to the replicas. Better yet would be a dynamic oplog where it doesn't need to be a specific size. Capped collections have advantages, I understand, but perhaps there are ways around limitations of uncapped ones for oplog purposes. |
| Comments |
| Comment by Sarah Olson [ 24/Mar/23 ] |
|
Closing this out on the grounds that:
Based on this, closing as WON'T DO. Please don't hesitate to give me a shout or to reopen if you disagree.
|
| Comment by Eric Milkie [ 10/Dec/18 ] |
|
Docs please note: Due to the way mongos works in 3.2, I had to change the backport for this command to use a pre-existing action type instead of creating a new one. This means to run the command on 3.4, one must have a role with replSetConfigure action type, not replSetResizeOplog as is the case on 3.6. The replSetConfigure action type is part of the clusterManager role, whereas on 3.6, the new replSetResizeOplog action type was placed in the hostManager role. |
| Comment by Shannon Bradshaw (Inactive) [ 07/Dec/18 ] |
|
Thanks, kay.kim |
| Comment by Kay Kim (Inactive) [ 20/Sep/17 ] |
|
https://github.com/mongodb/docs/commit/ce9d7a352a5640dfd93113aa93484e32dd9c72de |
| Comment by Louis Williams [ 08/Sep/17 ] |
|
Updated to reflect that the command accepts the size in MB. |