inconsistent treatment of applyOps during secondary oplog application

XMLWordPrintableJSON

    • Type: Bug
    • Resolution: Fixed
    • Priority: Major - P3
    • 3.7.3
    • Affects Version/s: None
    • Component/s: Replication
    • None
    • Fully Compatible
    • ALL
    • Repl 2018-03-12
    • 19
    • None
    • 3
    • None
    • None
    • None
    • None
    • None
    • None

      We started batching applyOps oplog entries with CRUD operations in SERVER-32913 and unpacking the embedded CRUD operations within the applyOps command for the writer threads to apply during the oplog application process. However, the unpacking is done only on storage engines that support document level concurrency. This penalizes the performance of the CRUD operations in the same batch when we run the applyOps command logic under the global write lock. We should either:

      • unpack the applyOps CRUD operations under all storage engines; or
      • batch applyOps with other CRUD ops when the storage engine supports document level concurrency.

            Assignee:
            Benety Goh
            Reporter:
            Benety Goh
            Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

              Created:
              Updated:
              Resolved: