[SERVER-33509] inconsistent treatment of applyOps during secondary oplog application Created: 27/Feb/18  Updated: 29/Oct/23  Resolved: 01/Mar/18

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: 3.7.3

Type: Bug Priority: Major - P3
Reporter: Benety Goh Assignee: Benety Goh
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-33618 Initial sync should consider applyOps... Closed
is related to SERVER-32913 Parallelize application of applyOps o... Closed
Backwards Compatibility: Fully Compatible
Operating System: ALL
Sprint: Repl 2018-03-12
Participants:
Linked BF Score: 19

 Description   

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.


 Comments   
Comment by Githook User [ 01/Mar/18 ]

Author:

{'email': 'benety@mongodb.com', 'name': 'Benety Goh', 'username': 'benety'}

Message: SERVER-33509 unpack applyOps commands on all storage engines during oplog application
Branch: master
https://github.com/mongodb/mongo/commit/18a75455402f5a86a55b8e4f85eb02f6575b4651

Generated at Thu Feb 08 04:33:38 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.