[DRIVERS-805] Sharding support for $planCacheStats Created: 09/Dec/19 Updated: 27/May/22 Resolved: 28/Jan/20 |
|
| Status: | Closed |
| Project: | Drivers |
| Component/s: | None |
| Fix Version/s: | None |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Backlog - Core Eng Program Management Team | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Server Compat: | 4.3 | ||||||||
| Description |
|
Downstream Change Summary We need to update the reference page for $planCacheStats (https://docs.mongodb.com/manual/reference/operator/aggregation/planCacheStats/). It currently says that $planCacheStats cannot be run against mongos instances. It should change to say that it can be run via mongos as of version 4.4. We also might want to update the examples to include the "host" and "shard" fiields. Finally, we could add an additional example explaining the "host"/"shard" fields, potentially with an example of how you might filter to get the results for a particular shard, or group by host. See the comment on the ticket for a more detailed description of the new "host" and "shard" fields. Description of Linked TicketCurrently, an aggregate operation which reads the plan cache as a "virtual collection" using $planCacheStats is not supported when connected to mongos:
Instead, users are expected to connect directly to the mongod of interest in order to examine that node's plan cache. In some environments (e.g. Atlas), it may be difficult or discouraged to connect directly to a shardsvr. Furthermore, some users may wish to examine the plan caches on all nodes before drilling down into particular nodes of interest. Therefore, we should add support for $planCacheStats issued via a mongos. The most sensible behavior for such an operation would be to return the union of the plan cache entries from every shardsvr node in the cluster (as opposed to obeying the read preference and returning the plan caches for a particular node in each shard). This may require some work in the sharding infrastructure to allow an aggregate operation to target every node. The current infrastructure typically assumes that at most one host in each shard is targeted. Finally, in order to allow users to filter, sort, group, etc. based on the host, we should augment each plan cache entry document in the result set with host:port information in the case of a sharded $planCacheStats. |
| Comments |
| Comment by Esha Bhargava [ 28/Jan/20 ] |
|
No driver changes needed |
| Comment by Esha Bhargava [ 27/Jan/20 ] |
|
jeff.yemin Do we need this doc for any of your teams? |