-
Type: Improvement
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Fully Compatible
-
Sharding NYC 2022-05-30, Sharding NYC 2022-06-13
-
3
This will be a chain of refactorings and let me put a short overview here. The base observation is that choosing between the use of ShardLocal and ShardRemote at low level is too cumbersome because we simply cannot do proper selection at the low level with information we have. What helps us is the fact that the ShardLocal is used only by the Config server while talking to itself.
From this observation we conclude that ShardLocal is a very narrow use case implementation that is still used as a very generic interface that has nothing to do with config server. So we will ultimately get rid of it.
All the cases when the config server talks to itself using direct client should be moved up the hierarchie to the new class ShardingCatalogClientLocal. We will have:
ShardingCatalogClient (interface) -> ShardingCatalogClientBase -> { ShardingCatalogClientRemote, ShardingCatalogClientLocal }
All subclasses of ShardingCatalogClient are stateless, this is just method implementation polymorphism without any state. We currently pick the implementation with:
Grid::get(opCtx)->catalogClient()
there are 100 call sites in 55 files. We will replace them with either `catalogClientLocal()` or `catalogClientRemote()`. You don't need to fix every location. Initially just use catalogClientLocal() where needed and keep catalogClient() unchanged. We can use global grep-replace later.
---------------------
Our goal is to remove the mutations on Config database using Shard interface on
ShardingCatalogClientImpl. For this we need to implement the runBatchWriteCommand() functionality outside the ShardLocal.
Create a new class ShardingCatalogClientLocal that has an additional method runBatchWriteCommand(). We do not touch read commands.
I think the method isRetriableError() should be implemented at the wrapper as well, see if it's possible to remove the original, otherwise file a ticket.
This can be tested on POC but it's essentially no-op refactoring, so port it to mainline from POC.
There is a separate ticket to remove all of runBatchWriteCommand() on Config outside the ShardingCatalogClientImpl.
- is depended on by
-
SERVER-66674 Get rid of all calls runBatchWriteCommand() on config Shard instance
- Closed
-
SERVER-66700 Port runCommandWithFixedRetryAttempts() to DBDirectClientWrapper
- Closed
-
SERVER-66711 Get rid of ShardLocal
- Closed
-
SERVER-66712 Refactor ShardingCatalogClientImpl::getNewKeys() in POC
- Closed