[SERVER-18094] currentOp on a mongoS should also show current mongoS operations Created: 17/Apr/15 Updated: 17/May/19 Resolved: 15/Mar/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.7.4 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Joanna Cheng | Assignee: | Bernard Gorman |
| Resolution: | Done | Votes: | 2 |
| Labels: | curop, currentop, supportgrab2018Q1 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Backport Requested: |
v3.6, v3.4
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | Query 2018-02-26, Query 2018-03-12, Query 2018-03-26 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
When there is a long running operation in a sharded cluster, if you run currentOp() on the mongoS, you can see the shard operations:
While it's possible to tell which mongoS it came from, it's not possible to trace it back further unless you have verbose logging on the mongoS. It would be nice to be able to find the source of the long running operation directly from currentOp output. If you are running a query, you could use $comment to annotate the query. However for other operations (writes, commands, internal things like chunk migrations, etc) there is no such feature. |
| Comments |
| Comment by Bernard Gorman [ 31/May/18 ] |
|
david.storch: correct - localOps has not been backported nor will it be, and the 3.6 commit above just extracts a client metadata bugfix that was included in the full localOps patch on master. |
| Comment by David Storch [ 31/May/18 ] |
|
bernard.gorman, it looks like the cherry-pick to 3.6 was in fact just a fix for ClientMetadata, correct? We have not backported the localOps parameter to the 3.6 branch, nor do we intend to. Should we delete the comment from the githook above in order to clarify the situation? |
| Comment by Githook User [ 29/May/18 ] |
|
Author: {'username': 'gormanb', 'name': 'Bernard Gorman', 'email': 'bernard.gorman@gmail.com'}Message: Note: this commit does not include the complete patch, but only backports the fix for a client metadata issue discovered during work on localOps. (cherry picked from commit 5ecf2c0a5bffa837c96ad20dea23a94c5165739a) |
| Comment by Githook User [ 16/Mar/18 ] |
|
Author: {'email': 'bernard.gorman@gmail.com', 'name': 'Bernard Gorman', 'username': 'gormanb'}Message: |
| Comment by Githook User [ 15/Mar/18 ] |
|
Author: {'email': 'bernard.gorman@gmail.com', 'name': 'Bernard Gorman', 'username': 'gormanb'}Message: |
| Comment by Kaloian Manassiev [ 11/Jan/18 ] |
|
Sounds good to me. |
| Comment by David Storch [ 11/Jan/18 ] |
|
kaloian.manassiev, the query team is looking into achieving this work as part of the logging improvements we're making for mongos. I'm going to move this one to our team's backlog as well. Let me know if you have any objections. |