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

Mitigate oplog impact for findAndModify commands executed with retryWrites=true

    • Type: Icon: Improvement Improvement
    • Resolution: Gone away
    • Priority: Icon: Major - P3 Major - P3
    • 5.1.0, 4.2.16, 4.0.27, 5.0.3, 4.4.9
    • Affects Version/s: None
    • Component/s: None
    • Labels:
      None

      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, 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.

        1. screenshot-1.png
          62 kB
          Adrien Jarthon

            Votes:
            9 Vote for this issue
            Watchers:
            39 Start watching this issue

              Created:
              Updated:
              Resolved: