[SERVER-30554] relax locking mode in applyOps when applying CRUD-only ops non-atomically Created: 08/Aug/17 Updated: 30/Oct/23 Resolved: 10/Aug/17 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Replication |
| Affects Version/s: | None |
| Fix Version/s: | 3.4.9, 3.5.12 |
| Type: | Improvement | 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: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Completed: | |||||||||||||
| Sprint: | Repl 2017-08-21 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
With and apply only CRUD. In this mode, applyOps() uses MODE_X to lock the database before calling applyOperation_inlock(). This does not take advantage of storage engines that support document level concurrency. This ticket proposes to relax the locking rules in applyOps() to use MODE_IX instead of MODE_X when applying CRUD-only workloads non-atomically. |
| Comments |
| Comment by Githook User [ 10/Aug/17 ] |
|
Author: {'username': 'benety', 'email': 'benety@mongodb.com', 'name': 'Benety Goh'}Message: This allows concurrent applyOps commands to update the same collection on storage (cherry picked from commit bca3f70566991afa2dfb38dc06494b0f6f04fffa) |
| Comment by Githook User [ 10/Aug/17 ] |
|
Author: {'username': 'benety', 'email': 'benety@mongodb.com', 'name': 'Benety Goh'}Message: (cherry picked from commit b871fce9d308271f95159900c0e41d435f31e5ab) |
| Comment by Githook User [ 10/Aug/17 ] |
|
Author: {'username': 'benety', 'email': 'benety@mongodb.com', 'name': 'Benety Goh'}Message: This allows concurrent applyOps commands to update the same collection on storage |
| Comment by Githook User [ 09/Aug/17 ] |
|
Author: {'username': 'benety', 'email': 'benety@mongodb.com', 'name': 'Benety Goh'}Message: |
| Comment by Steve Briskin (Inactive) [ 09/Aug/17 ] |
|
spencer, The deployments that tend to cause us the most issues tend to have one, maybe two, very active collections and those collections tend to be in the same DB. I'm sure DB and collection-level concurrency will help some cases, but I don't think it'll help the typical case that we struggle with. |
| Comment by Spencer Brody (Inactive) [ 08/Aug/17 ] |
|
steve.briskin, what level of concurrency do you need out of applyOps for backup's use case? We currently have got it down to db-level concurrency (we'll take a db-level lock for the duration of the applyOps in the non-atomic form when applying crud ops). Is that sufficient? Would collection-level concurrency be sufficient? Or do you need true document-level concurrency? I'm not sure if just doing collection-level actually buys us anything over doing document-level, just want to understand the requirements. Thanks! |
| Comment by Spencer Brody (Inactive) [ 08/Aug/17 ] |
|
Seems like it should be possible even if applying non-crud ops. In theory I don't think the applyOps command should need to do any locking in the non-atomic form since every sub-command or operation must already be doing its own locking. |