The current mergeChunks path is very inefficient because:
It performs three sequential refreshes (router, shard-pre-merge and shard-post-merge)
All this makes the mergeChunks command very expensive both from latency and from impact on the config server points of view.
It would be much better if:
- The router command:
- Didn't do a refresh on entry, but relied on the cached information and the shardVersion (this has backwards compatibility implications)
- The shard command (in order of importance):
- Just checked the major shardVersion (for routing correctness, i.e., to make sure this shard owns that range)
- Only did a refresh on the shard if the chunk bounds that the router sent didn't match with the cached info (this can only happen if a previous merge committed against the ConfigServer, but failed to refresh)
- is related to
-
SERVER-56786 There are three routing info refreshes and two chunk scans on the mergeChunks path
- Closed