[SERVER-34633] Allow $currentOp to retrieve operations from all members of each shard in a cluster Created: 24/Apr/18 Updated: 29/Oct/23 Resolved: 13/Jun/23 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Aggregation Framework, Diagnostics |
| Affects Version/s: | None |
| Fix Version/s: | 7.1.0-rc0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Bernard Gorman | Assignee: | Adi Agrawal |
| Resolution: | Fixed | Votes: | 1 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Query Execution
|
||||||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||||||
| Sprint: | QE 2023-05-29, QE 2023-06-12, QE 2023-06-26 | ||||||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
With the introduction of the $currentOp aggregation stage, users have the ability to obtain a list of operations running on Secondaries in a sharded cluster by setting the appropriate readPreference. However, this will only provide the operations from a single eligible Secondary in each shard, and the standard approach to more fine-grained targeting - using replica set tags - is both onerous and does not satisfactorily address this shortcoming. Add a new flag to $currentOp which, if set, stipulates that it should target every data-bearing member in each shard and return an exhaustive list of all operations running anywhere in the cluster. |
| Comments |
| Comment by Githook User [ 13/Jun/23 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
Author: {'name': 'Adityavardhan Agrawal', 'email': 'adi.agrawal@mongodb.com', 'username': 'Adityav369'}Message: | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Ana Meza [ 14/Feb/23 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
Note: If the prerequisite | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Davis Haupt (Inactive) [ 10/Feb/23 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
With | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Alex Bevilacqua [ 15/Oct/20 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
We have a helper function that can be used to filter $currentOp results across replica set members within a sharded cluster.
This will produce results similar to:
Note this is a simple example and doesn't factor in authentication, however I'm providing it here as-is to showcase one approach to this problem in the interim. | ||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Andy Schwerin [ 02/May/18 ] | ||||||||||||||||||||||||||||||||||||||||||||||||
|
This is a pretty cool idea. I think a correct solution would need to return results as they arrived, and handle down nodes, which would make this interesting. That said, it would be a very expensive operation on large sharded clusters (hundreds of nodes), and still would omit operations that run exclusively on routers, so it would still be a somewhat incomplete view. |