[SERVER-31156] Admin command to update the chunk metadata for only one collection Created: 19/Sep/17 Updated: 30/Oct/23 Resolved: 21/Jan/19 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 3.6.11, 4.0.6, 4.1.8 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Andrew Young | Assignee: | Kaloian Manassiev |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | ShardingSupport, former-quick-wins, neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Backport Requested: |
v4.0, v3.6
|
||||||||||||
| Sprint: | Sharding 2019-01-28 | ||||||||||||
| Participants: | |||||||||||||
| Case: | (copied to CRM) | ||||||||||||
| Description |
|
It would be helpful if there were an admin command on the mongos that would force the mongos to retrieve the newest chunk metadata for only one collection using the same method that is used when a StaleShardingException is caught for a given collection. The existing flushRouterConfig() method flushes all of the chunk metadata, which then requires the mongos to retrieve the chunk metadata for every collection as requests for those collections are processed. This results in a much higher load on both the mongos and the config servers than the single-collection update process used when a StaleShardingException is caught. This new method would be useful when an administrator moves a chunk or executes a movePrimary command and wants to be sure that all of the mongos instances have picked up the change without clearing out the metadata for all other collections, especially in larger clusters. |
| Comments |
| Comment by Githook User [ 13/Feb/19 ] |
|
Author: {'name': 'Kaloian Manassiev', 'email': 'kaloian.manassiev@mongodb.com', 'username': 'kaloianm'}Message: (cherry picked from commit e4f26d25632f94a6577028ccefd32069550628b6) |
| Comment by Githook User [ 21/Jan/19 ] |
|
Author: {'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}Message: (cherry picked from commit e4f26d25632f94a6577028ccefd32069550628b6) |
| Comment by Githook User [ 20/Jan/19 ] |
|
Author: {'email': 'kaloian.manassiev@mongodb.com', 'name': 'Kaloian Manassiev', 'username': 'kaloianm'}Message: |
| Comment by Kaloian Manassiev [ 21/Mar/18 ] |
|
With the availability of the forceRoutingTableRefresh command and with the work we are doing to introduce version of the database, similar to chunk version, this should command should be unnecessary from 4.0 onwards. Leaving the ticket open to add it for 3.6 and 3.4. Like Esha suggests, adding a namespace to flushRouterConfig might be the most appropriate solution. |
| Comment by Esha Maharishi (Inactive) [ 25/Sep/17 ] |
|
There is currently a forceRoutingTableRefresh (renamed to _flushRoutingTableCacheUpdates in 3.6.1) command on mongod that refreshes the shard's routing table cache for a particular namespace, but it uses ShardingState, which is not available on mongos. I think the best option would be to make the existing flushRouterConfig command optionally take a namespace, and if the namespace is given, only that namespace is refreshed. |
| Comment by Andrew Young [ 19/Sep/17 ] |
|
It would be helpful if this command could take at least two parameters: |