[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:
Related
related to SERVER-10410 better reporting of mongod collection... Closed
is related to DOCS-12521 Document fullMetadata option for db.c... Closed
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: SERVER-10720 Add a way for getShardVersion on mongos to return the full cached chunk distribution for a collection
Branch: master
https://github.com/mongodb/mongo/commit/0efcbe92a9888c684472439844822e7e98885802

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).

Generated at Thu Feb 08 03:23:53 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.