[SERVER-47567] Prevent incorrectly dropping oplog on 4.0 Created: 15/Apr/20  Updated: 04/Jun/20  Resolved: 04/Jun/20

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

Type: Improvement Priority: Major - P3
Reporter: Tess Avitabile (Inactive) Assignee: Evin Roesle
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-47558 Revert SERVER-38356 on 4.0 Closed
related to SERVER-38356 Forbid dropping oplog in standalone m... Closed
Participants:

 Description   

SERVER-38356 requested adding guardrails to prevent users from dropping the oplog in standalone mode due to the use of an outdated procedure for resizing the oplog. In versions 4.0 and later, dropping the oplog in standalone mode can cause loss of majority-committed writes. The fix banned dropping the oplog completely for storage engines that support the replSetResizeOplog command on versions 4.0 and later, with the suggested workaround to drop the entire local database in cases where dropping the oplog is necessary, such as restoring a replica set backup to a standalone. This was reverted on 4.0 inĀ SERVER-47558 because it prevented some necessary maintenance procedures. We should consider alternative solutions on 4.0 (and perhaps on later branches), such as adding a force option to the drop command, or banning dropping the oplog only when there is a replica set config.



 Comments   
Comment by Evin Roesle [ 04/Jun/20 ]

Closing as Won't Do as the support team is aware of this and utilizes replSetResizeOplog effectively to mitigate this issue.

Generated at Thu Feb 08 05:14:33 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.