[SERVER-10720] Add a way for getShardVersion on mongos to return the full cached chunk distribution for a collection Created: 09/Sep/13 Updated: 10/Oct/19 Resolved: 10/Oct/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 4.3.1 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Randolph Tan | Assignee: | Cheahuychou Mao |
| Resolution: | Done | Votes: | 0 |
| Labels: | ShardingSupport, neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Sprint: | Sharding 2019-10-21 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Currently, the mongos version of getShardVersion (which returns mongos's routing table cache entry for a collection or a database) returns the collection version (the highest version of any chunk in the collection out of the chunks present in the cache entry) and logs the chunks. It is much more useful for the command to return the chunks (instead of only logging them), similarly to how the shard version of getShardVersion (which returns the shard's filtering table entry for a collection) does. |
| Comments |
| Comment by Githook User [ 10/Oct/19 ] |
|
Author: {'username': 'cheahuychou', 'email': 'cheahuychou.mao@mongodb.com', 'name': 'Cheahuychou Mao'}Message: |
| Comment by Esha Maharishi (Inactive) [ 03/Oct/19 ] |
|
kaloian.manassiev Ok, cool, we'll give it a try. |
| Comment by Kaloian Manassiev [ 03/Oct/19 ] |
|
Yeah, we could do that. It looks like the BSONObjBuilder class also already has a method called len(), which can be used to get the size accumulated so far. |
| Comment by Esha Maharishi (Inactive) [ 03/Oct/19 ] |
|
kaloian.manassiev, hm, good point. It looks like that can already happen in the shard's getShardVersion, since if 'fullMetadata: true' is passed, then it calls CollectionMetadata::toBSONChunks, which tries to append all the chunks. Do you think we could fix both commands by having them attempt to return the chunks if they fit in 16MB, using some comparison like we do in the write path? We could also make the shard's getShardVersion log the chunks if they don't fit in 16MB. Let me know if you think this is worth doing. |
| Comment by Kaloian Manassiev [ 03/Oct/19 ] |
|
I believe the original reason the command logs is that the size of the routing table is unbounded, but the getShardVersion command doesn't return a cursor and is limited by the max BSON size of 16MB. I don't think it is a good idea to change that behaviour, because if someone has more than 16MB of chunks, the command will not be useful (although it's not that useful in the first place to look at 16MB of chunks anyways). |