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

Mitigate oplog impact for findAndModify commands executed with retryWrites=true

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Major - P3
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: None
    • Labels:
      None
    • Case:

      Description

      OP in PHPC-1523 reported that an application performing many findAndModify commands on large documents can quickly populate its oplog when retryable writes are enabled (as is the case by default since driver's 4.2-compat releases).

      The drivers retryable writes specification has historically only permitted the feature to be configured at the MongoClient level in order to limit the API changes (vs. granular configuration on a database, collection, or per-operation). Therefore, it's difficult for applications to work around this and disable retryable writes just for findAndModify operations without off-loading all of those operations to a dedicated MongoClient.

      That said, the side effect of findAndModify with retryable writes is not very intuitive. Given that retryable writes is advertised as a "set it and forget it" feature, I don't think most users would even consider this side effect if they were not watching their oplog activity (as was the case in PHPC-1523). As for documentation, I suppose we could note this in either the retryable writes or findAndModify docs (or both), but it does seem very specific and could easily be missed.

      In a linked HELP ticket, Andy Schwerin mentioned that "our current implementation of retryable writes isn't the only viable one", so I'm opening this SERVER ticket to start a discussion on how we could alleviate this side effect for users without requiring them to change their applications or disable retryable writes altogether.

        Attachments

          Issue Links

            Activity

              People

              Assignee:
              backlog-server-sharding Backlog - Sharding Team
              Reporter:
              jmikola Jeremy Mikola
              Participants:
              Votes:
              7 Vote for this issue
              Watchers:
              36 Start watching this issue

                Dates

                Created:
                Updated: