[SERVER-22038] changelog and actionlog become non-capped after drop Created: 31/Dec/15  Updated: 06/Dec/22  Resolved: 18/Nov/21

Status: Closed
Project: Core Server
Component/s: Sharding
Affects Version/s: 3.0.8, 3.2.0
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kevin Pulo Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Done Votes: 0
Labels: max-triage
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Sharding
Operating System: ALL
Steps To Reproduce:

sh.startBalancer();
assert(db.getSiblingDB("config").changelog.stats().capped);
assert(db.getSiblingDB("config").actionlog.stats().capped);
assert(db.getSiblingDB("config").changelog.drop());
assert(db.getSiblingDB("config").actionlog.drop());
assert.commandWorked(sh.enableSharding("test"));
assert.commandWorked(sh.shardCollection("test.test", {_id:1}));  // cause config.changelog entry
sleep(11*1000);  // wait for balancing round to put something in config.actionlog
assert(db.getSiblingDB("config").changelog.stats().capped);  // FAILS
assert(db.getSiblingDB("config").actionlog.stats().capped);  // FAILS

Participants:

 Description   

config.changelog and config.actionlog are created as 10MB and 2MB capped collections. However, if they are dropped, then the next time a document is inserted they get auto-recreated as regular (non-capped) collections. From there they can expand to consume large amounts of disk space.

One solution would be to automatically correct this situation by periodically (eg. each balancer round) checking to see if these collections aren't capped, and if so, running convertToCapped on them.


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