[SERVER-22556] Get rid of DBClientReplicaSet Created: 10/Feb/16  Updated: 06/Dec/22  Resolved: 09/Dec/19

Status: Closed
Project: Core Server
Component/s: Networking, Sharding
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Kaloian Manassiev Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
is depended on by SERVER-22485 ShardNotFound error when looking up r... Closed
Related
related to SERVER-27625 Remove dead ANSA and setShardVersion ... Closed
Assigned Teams:
Sharding
Operating System: ALL
Sprint: Sharding 11 (03/11/16)
Participants:

 Description   

DBClientRS and its usage within sharding is becoming a nuisance, due to the need to keep a map from the entire connection string back to a shard object. See SERVER-22485 for example.

We should consider removing it and replacing its usages with a combination of just plain ShardConnections and RemoteCommandTargeter.



 Comments   
Comment by Sheeri Cabral (Inactive) [ 09/Dec/19 ]

This is necessary in the shell, so we can't remove it, but we've fixed most of the places we could get rid of it (e.g. moveChunk).

Comment by Spencer Brody (Inactive) [ 24/Feb/16 ]

Users of ScopedDbConnection:

  • DBClientCursor
  • ReplicaSetMonitor
  • agg
  • serverStatus
  • moveChunk
  • splitChunk
  • Future::spawnCommand
    • geoNear
    • RunOnAllShardCommand
  • killOp
  • M/R
  • shardCollection (we may also want to consider pushing more of the implementation of this down out of the command body and into the catalog manager)
  • createIndexes
  • collStats
  • dataSize
  • listCollections
  • listIndexes
  • dropDatabase

Users of ShardConnection:

  • moveChunk
  • splitChunk
  • mergeChunks
  • DBClientMultiCommand (used by the write commands)
  • Future::spawnCommand
    • geoNear
    • RunOnAllShardCommand
  • findAndModify
  • M/R
  • agg
  • resetError
  • group
  • geoNear
Comment by Spencer Brody (Inactive) [ 24/Feb/16 ]

The main consumers of DBClientRS are:

  • copydb
  • benchRun
  • the shell
  • ScopedDBConnection
  • ShardConnection
  • ParallelSortClusteredCursor

copydb shouldn't be hard to fix if we keep it using DBClientConnection, just using the targeter to connect to a single host

I'm not sure how hard benchRun or the shell will be to fix. I suspect benchRun is straightforward so long as it currently always sends ops to the same single server. The shell I'm less sure about.

ScopedDBConnection and ShardConnection have lots of callers, which I will enumerate in a follow up comment. Most instances of both should be easy to change to targeting a single server.

ParallelSortClusteredCursor can probably also be changed to target a single server, using a direct connection with DBClientConnection.

Generated at Thu Feb 08 04:00:44 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.