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

inconsistent treatment of applyOps during secondary oplog application

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

      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.

            benety.goh@mongodb.com Benety Goh
            benety.goh@mongodb.com Benety Goh
            0 Vote for this issue
            1 Start watching this issue