[SERVER-6496] provide a way to kill a sharded query on all shards Created: 17/Jul/12 Updated: 28/Feb/23 Resolved: 03/Apr/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Querying, Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.0.0-rc0 |
| Type: | New Feature | Priority: | Major - P3 |
| Reporter: | Alon Horev | Assignee: | Backlog - Query Team (Inactive) |
| Resolution: | Done | Votes: | 17 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||||||||||||||||||||||
| Assigned Teams: |
Query
|
||||||||||||||||||||||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||||||||||||||||||||||
| Participants: | |||||||||||||||||||||||||||||||||||||||||
| Case: | (copied to CRM) | ||||||||||||||||||||||||||||||||||||||||
| Description |
|
Issue Status as of April 4, 2018 FEATURE DESCRIPTION
VERSIONS RATIONALE In addition, killing a sharded query on a mongos node was not possible. OPERATION
The reported operation IDs identify operations running on the mongos node. A mongos-local operation ID can be used as an argument to the killOp command in order to terminate the queries that mongos issued to the targeted shards on behalf of the client. For instance, to kill a particular sharded operation matching <filter> use:
Original Description When trying to kill a query through mongos, It requires killing the query manually on every single shard. |
| Comments |
| Comment by David Storch [ 02/Apr/18 ] | ||||||
|
Hi all, This work is completed and will first be available in the 3.7.4 development release, which will evolve into the 4.0 stable release series. Related ticket
Furthermore, mongos operation IDs are now killable due to the changes in
Finally, 3.7.4 contains related enhancements which will cause sharded queries to quickly clean themselves up on all shards in the case of an error (e.g. | ||||||
| Comment by David Storch [ 14/Jul/16 ] | ||||||
|
schwerin, I believe you are correct. As of MongoDB 3.2, if a mongos or mongod receives a find or aggregate command with a batchSize of 0, it will establish the cursor without doing the work to generate a batch of results. I'm not sure if the drivers, however, expose a user-friendly mechanism for passing a batchSize of 0 with the initial find/aggregation and then a separate batchSize on each subsequent getMore. | ||||||
| Comment by Andy Schwerin [ 14/Jul/16 ] | ||||||
|
Beginning in MongoDB 3.2, if you can still connect to the mongos where the query started, you can kill the cursor for aggregations and finds, and it will contact the shards and kill the corresponding cursors. This approach only applies to operations that return cursors, but it's a start. If an operation is long-running before it returns any results at all, I believe that the user can request that the cursor id be returned before any results are produced, but I'm not 100% certain. david.storch or rassi might know. |