[SERVER-32147] Investigate if createIndexes is holding a global exclusive lock during oplog application Created: 01/Dec/17  Updated: 27/Oct/23  Resolved: 14/Dec/17

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

Type: Bug Priority: Major - P3
Reporter: Judah Schvimer Assignee: Backlog - Replication Team
Resolution: Works as Designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Assigned Teams:
Replication
Operating System: ALL
Participants:

 Description   

In 3.6 we started replicating createIndexes as a command. Commands get applied under the global exclusive lock: https://github.com/mongodb/mongo/blob/master/src/mongo/db/repl/sync_tail.cpp#L394-L405.

I think this means we're now applying createIndexes oplog entries under a global exclusive lock which could take a long time.



 Comments   
Comment by Eric Milkie [ 02/Dec/17 ]

tryPopAndWaitForMore() already treats inserts into system.indexes the same as ā€˜c’ ops when making a new batch.

Comment by Spencer Brody (Inactive) [ 01/Dec/17 ]

Thinking about this more I think milkie is right. We already freeze the world during secondary oplog application via the ParallelBatchWriterLock, so taking the global X lock additionally shouldn't add much overhead. The only difference is that the createIndex would now be processed in a batch on its own instead of alongside other ops, but the impact of that should be small relative to the cost of doing an index build.

Comment by Eric Milkie [ 01/Dec/17 ]

Why would it take longer than building an index via an insert into system.indexes?

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