Uploaded image for project: 'Core Server'
  1. Core Server
  2. SERVER-38356

Forbid dropping oplog in standalone mode on storage engines that support replSetResizeOplog

    • Type: Icon: Improvement Improvement
    • Resolution: Fixed
    • Priority: Icon: Major - P3 Major - P3
    • 4.2.1, 4.3.1
    • Affects Version/s: 4.0.4
    • Component/s: Replication
    • None
    • Fully Compatible
    • v4.2, v4.0
    • Repl 2019-06-03, Repl 2019-06-17, Repl 2019-07-01, Repl 2019-07-15
    • 47

      This ticket banned dropping the oplog in standalone mode entirely on storage engines that support the replSetResizeOplog command.

      Original Description

      Currently the oplog cannot be dropped while running in replset mode, but can be dropped as standalone. Until recently the procedure to resize the oplog included dropping the oplog while in standalone, however, doing this procedure on an uncleanly shutdown 4.0 mongod causes committed writes to be lost (because they only existed in the oplog, and the resize preserves only the final oplog entry, see DOCS-12230 and SERVER-38174 for more details). It would be much better if attempting this procedure in 4.0 did not result in oplog entries being lost, eg. if dropping the oplog failed.

      Completely forbidding oplog drop (even when standalone) would interfere with the use case of restoring a filesystem snapshot as a test standalone. A better alternative would be to forbid dropping the oplog only if local.system.replset contains documents. This way, users who are sure they want to drop the oplog can do so by first removing the documents from local.system.replset (which can't be dropped, but can have its contents removed) and then restarting the standalone. Whereas users who are just trying to perform a manual oplog resize will be stopped before any data loss.

      If we choose not to do this, then at the very least we should improve the "standalone-but-replset-config-exists" startup warning to specifically warn against to manually resizing the oplog.

            Assignee:
            vishnu.kaushik@mongodb.com Vishnu Kaushik
            Reporter:
            kevin.pulo@mongodb.com Kevin Pulo
            Votes:
            0 Vote for this issue
            Watchers:
            20 Start watching this issue

              Created:
              Updated:
              Resolved: