[SERVER-36354] Show outstanding locks acquired by secondary oplog application in CurrentOp Created: 30/Jul/18 Updated: 27/Oct/23 Resolved: 08/Oct/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Replication |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Judah Schvimer | Assignee: | Backlog - Replication Team |
| Resolution: | Gone away | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Assigned Teams: |
Replication
|
| Participants: |
| Description |
|
This was a request that came out of the design for "Prepare Support for Transactions" that will become increasingly useful when locks are held longer on secondaries. |
| Comments |
| Comment by Gregory McKeon (Inactive) [ 08/Oct/18 ] |
|
In the current design, you will now be able to view locks held by prepared transactions by running currentOp on a secondary, this has gone away. |
| Comment by Judah Schvimer [ 31/Jul/18 ] |
|
After talking to milkie, this does not impact prepared transactions on secondaries as tess.avitabile explained. This would still be good for generalizing to all lock holders. |
| Comment by Eric Milkie [ 30/Jul/18 ] |
|
Currently, the currentOp command loops through all Clients with associated CurOp structures, and then it also scans through all idle Sessions, to find all lock holders. Secondary oplog application threads do not use a Client and therefore do not appear in the currentOp list, even though such threads may hold locks. |