[SERVER-22766] Dynamic oplog sizing for WiredTiger nodes Created: 19/Feb/16 Updated: 23/Oct/19 Resolved: 05/Jul/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.4.19, 3.5.10 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Shakir Sadikali | Assignee: | Geert Bosch |
| Resolution: | Done | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v3.4
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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 Githook User [ 07/Dec/18 ] |
|
Author: {'name': 'wolfkdy', 'email': 'kdy71107216@aliyun.com', 'username': 'wolfkdy'}Message: (cherry picked from commit 93beb0234eba9dc58ab6070ad472022f96e019e6) |
| Comment by Githook User [ 05/Jul/17 ] |
|
Author: {u'username': u'wolfkdy', u'name': u'wolfkdy', u'email': u'kdy71107216@aliyun.com'}Message: |
| Comment by Geert Bosch [ 08/Jun/17 ] |
|
We'll be merging your change soon |
| Comment by deyukong [ 26/May/17 ] |
|
Would you please take some time to review my last commit, thanks! |
| Comment by deyukong [ 17/May/17 ] |
|
@Geert Bosch |
| Comment by deyukong [ 16/May/17 ] |
|
I refined my code, to update codes below: use checkAuthForCommand instead of addRequiredPrivileges |
| Comment by deyukong [ 15/May/17 ] |
|
Happy Monday! |
| Comment by deyukong [ 11/May/17 ] |
|
I've carefully read @Spencer T Brody's review comments, optimized my code and updated the pull request. |
| Comment by deyukong [ 30/Apr/17 ] |
|
I‘ve carefully read @Geert Bosch's review comments, optimized my code and updated the pull request. |
| Comment by deyukong [ 06/Mar/17 ] |
|
I did not pass “resizeOplog” through the replication subsystem since oplogSize should be metadata of a single mongod rather than a repl-set. |
| Comment by Ramon Fernandez Marina [ 04/Mar/17 ] |
|
Thanks for taking the time to create a pull request wolf_kdy, we'll take a look and get back to you. |
| Comment by deyukong [ 04/Mar/17 ] |
|
Hi, I devoted a pull request to solve this issue. |