[SERVER-64630] Use the received shard version to avoid unnecessary refresh of the catalog cache Created: 18/Mar/22 Updated: 29/Oct/23 Resolved: 23/Mar/22 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Sharding |
| Affects Version/s: | None |
| Fix Version/s: | 6.0.0-rc0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Antonio Fuschetto | Assignee: | Antonio Fuschetto |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||
| Operating System: | ALL | ||||||||||||
| Sprint: | Sharding EMEA 2022-04-04 | ||||||||||||
| Participants: | |||||||||||||
| Description |
|
Each write operation must lock the collection on which it's working on. To do this, the description of the collection is required to determine if the collection is sharded or not. When getting the collection description, if the current metadata is not available, the function throws a StaleConfigInfo error attaching an ignored received shard version. After the write operation is closed, since a StaleConfigInfo error has been raised, the shard manages a shard version mismatch (ignored vs local shard version) and then triggers a full or partial refresh of the catalog cache to recover the shard version. This is inefficient. The context of the write operation could embed a concrete shard version, which must be used when the StaleConfigInfo error is thrown, avoiding to recover the shard version from the CSRS. |
| Comments |
| Comment by Chao Yin [ 19/Jun/23 ] |
|
After creating a shard cluster of r5.0.13 version, a large number of read requests with secondary readconcern and manually splitting the chunk through the splitFind command will also cause unnecessary routing refreshes on the secondary node. After I ported this jira, those unnecessary route refreshes disappeared. Is it the same reason? |
| Comment by Githook User [ 23/Mar/22 ] |
|
Author: {'name': 'Antonio Fuschetto', 'email': 'antonio.fuschetto@mongodb.com', 'username': 'afuschetto'}Message: |