[SERVER-41818] Add a new method in storage API for fetching updateCappedSize support Created: 18/Jun/19  Updated: 06/Dec/22  Resolved: 12/Jul/19

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Task Priority: Major - P3
Reporter: Suganthi Mani Assignee: Backlog - Storage Execution Team
Resolution: Won't Do Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-38356 Forbid dropping oplog in standalone m... Closed
Assigned Teams:
Storage Execution
Participants:

 Description   

Currently, we allow dropping of oplog on standalone nodes which can lead to undesired behavior (see SERVER-38356). To fix it, we will ban the dropping of oplog entirely on wiredTiger storage engine. But, allow oplog dropping on mmapv1 for stand alone nodes as it doesn't support replSetResizeOplog cmd. To implement this behavior, we are planning to check supportsRecoveryTimestamp() (before dropping of oplog in dbcommands.cpp) as it returns true for WT storage engine regardless of EMRC value and for mmapv1, it returns false.

To implement this in a more cleaner way, it would be good if we have a method in storage interface layer which tells the support of replSetResizeOplog cmd (dynamic oplog resizing) for a storage engine.



 Comments   
Comment by Geert Bosch [ 12/Jul/19 ]

There is no more MMAP storage engine since v4.2.0. If there is a need to backport the ban of oplog dropping for non-MMAPv1 storage engines, there are ways to directly check for MMAPv1. While checking for an explicit storage engine is not a great approach for maintainability, it isn't as much of a concern for legacy branches.

Generated at Thu Feb 08 04:58:45 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.