[SERVER-66672] Support the runBatchWriteCommand on ShardingCatalogClientLocal for direct client Created: 23/May/22  Updated: 29/Oct/23  Resolved: 31/May/22

Status: Closed
Project: Core Server
Component/s: None
Affects Version/s: None
Fix Version/s: 6.1.0-rc0

Type: Improvement Priority: Major - P3
Reporter: Andrew Shuvalov (Inactive) Assignee: Andrew Witten (Inactive)
Resolution: Fixed Votes: 0
Labels: sharding-nyc-subteam2, sharding-nyc-subteam2-catalog-poc
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-66674 Get rid of all calls runBatchWriteCom... Closed
is depended on by SERVER-66700 Port runCommandWithFixedRetryAttempts... Closed
is depended on by SERVER-66711 Get rid of ShardLocal Closed
is depended on by SERVER-66712 Refactor ShardingCatalogClientImpl::g... Closed
Backwards Compatibility: Fully Compatible
Sprint: Sharding NYC 2022-05-30, Sharding NYC 2022-06-13
Participants:
Story Points: 3

 Description   

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.


Generated at Thu Feb 08 06:06:05 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.