[SERVER-80370] Fix shardingStatistics' numHostsTargeted for tracked unsharded collections Created: 24/Aug/23 Updated: 18/Jan/24 Resolved: 18/Jan/24 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | 7.3.0-rc0 |
| Type: | Task | Priority: | Major - P3 |
| Reporter: | Jordi Serra Torrens | Assignee: | Jordi Olivares Provencio |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | oldshardingemea | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Catalog and Routing
|
||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||
| Sprint: | CAR Team 2023-12-25, CAR Team 2024-01-08, CAR Team 2024-01-22 | ||||||||
| Participants: | |||||||||
| Description |
|
NumHostsTargetedMetrics::parseTargetType only returns 'kUnsharded' when there is no routing table (i.e. no chunks). However, tracked unsharded collections do have a routing table. This may cause operations on such collections to be accounted as 'oneShard' operations, rather than the expected 'unsharded'. |
| Comments |
| Comment by Githook User [ 18/Jan/24 ] | ||||||||
|
Author: {'name': 'Jordi Olivares Provencio', 'email': 'jordi.olivares-provencio@mongodb.com', 'username': 'jordiolivares'}Message: GitOrigin-RevId: cd9d0a9309625f98b168f9cb83a69d2d0037717a | ||||||||
| Comment by Jordi Serra Torrens [ 21/Dec/23 ] | ||||||||
|
This ticket refers to the following serverStatus section on mongos:
Specifically around the fact that operations on "tracked unsharded collections" now are tracked as 'oneShard' instead of 'unsharded'. I'd say that this represents a change in reporting semantics. | ||||||||
| Comment by Jordi Olivares Provencio [ 11/Dec/23 ] | ||||||||
|
jordi.serra-torrens@mongodb.com This change involves changing the semantics for the metrics produced by aggregations in a confusing manner for users. Right now aggregations assumes that unsharded collections reside on the dbPrimary since the method returns an empty set of chunk owning shards if they are unsharded. The problem with now assuming that chunks can exist on other shards is that maintaining this semantic is confusing since we're now potentially performing distributed computations (think aggregation on two unsharded collections) but then going back to the user and saying we are targeting unsharded collections but not saying if they resided on the same shard or not. Is there any reason we wouldn't want to remove the notion of unsharded host targetting altogether instead and just explain to the user we are contacting 1/Some/All shards? |