[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? |