Configuration Server (Config Server) and Query Router (mongos)

The Role and Deployment of Config Servers

The config server is a core component of a MongoDB sharded cluster, responsible for storing the cluster's metadata. This metadata includes chunk ranges of sharded collections, data distribution locations, and cluster configurations. When using a sharded cluster, all read and write operations must first access the config server to obtain routing information.

A typical config server deployment adopts a replica set format, usually consisting of 3 nodes to ensure high availability. Example deployment command:

// Start a config server replica set
mongod --configsvr --replSet configReplSet --dbpath /data/configdb --port 27019

Config servers use a special "config" database to store metadata, with several key collections including:

• chunks: Records data chunk information for each sharded collection
• collections: Records configurations of sharded collections
• shards: Records information about all shards in the cluster

How mongos Query Routing Works

mongos is the entry point for MongoDB sharded clusters. Applications connect to mongos rather than directly to shards. When a query reaches mongos, it performs the following operations:

1. Retrieves metadata cache from config servers
2. Determines the involved shards based on query conditions
3. Distributes the query to relevant shards
4. Merges results from all shards
5. Returns the final result to the client

Basic command to start mongos:

mongos --configdb configReplSet/config1:27019,config2:27019,config3:27019 --port 27017

Query Routing Strategies in Sharded Clusters

MongoDB employs various routing strategies based on different shard keys:

Targeted Query When the query contains an exact match or range condition on the shard key, mongos can precisely determine which shard contains the data. For example:

// Shard key is {user_id: 1}
db.orders.find({user_id: "U1001"})  // Only needs to query specific shard

Broadcast Query When the query doesn't include the shard key, mongos must send the query to all shards:

db.orders.find({status: "pending"})  // Needs to query all shards

Split Query For queries containing shard key ranges that don't cover the entire key space:

db.orders.find({user_id: {$gt: "U1000", $lt: "U2000"}})

High Availability Implementation for Config Servers

To ensure high availability of config servers, MongoDB 3.4+ requires config servers to be deployed as replica sets. Configuration example:

// Initialize config server replica set
rs.initiate({
  _id: "configReplSet",
  configsvr: true,
  members: [
    { _id: 0, host: "cfg1.example.net:27019" },
    { _id: 1, host: "cfg2.example.net:27019" },
    { _id: 2, host: "cfg3.example.net:27019" }
  ]
})

When the primary config server becomes unavailable, the replica set automatically elects a new primary node. The mongos process caches configuration information and can continue routing queries even during brief config server unavailability.

Load Balancing and Connection Management for mongos

Large production environments typically require deploying multiple mongos instances for load balancing. Best practices include:

1. Deploying mongos locally on application servers to reduce network latency
2. Using connection pools to manage mongos connections
3. Monitoring load conditions of each mongos instance

Example connection pool configuration in Node.js applications:

const { MongoClient } = require('mongodb');
const uri = "mongodb://mongos1:27017,mongos2:27017/?replicaSet=shardReplSet";

const client = new MongoClient(uri, {
  poolSize: 50, // Connection pool size
  connectTimeoutMS: 5000,
  socketTimeoutMS: 30000
});

Metadata Caching Mechanism in Sharded Clusters

mongos optimizes metadata access through the following mechanisms:

1. Lazy Loading: Only retrieves metadata from config servers when needed
2. Periodic Refresh: Refreshes metadata cache every 300 seconds by default
3. Version Verification: Checks if metadata version is stale before each routing

Manual cache refresh commands:

// Refresh metadata for all databases
db.adminCommand({ flushRouterConfig: 1 });

// Refresh metadata for specific collection
db.getSiblingDB("config").cache.databases.flush();

Performance Tuning for Config Servers and mongos

Config Server Optimization:

• Use SSD storage for metadata
• Deploy config servers separately without sharing resources with other services
• Monitor oplog growth

mongos Optimization:

• Increase the number of mongos instances
• Adjust chunk size (default 64MB)
• Optimize query patterns to use shard keys whenever possible

Example monitoring commands:

// View mongos status
db.adminCommand({ mongosStatus: 1 });

// Check config server latency
db.runCommand({ serverStatus: 1 }).metrics.repl.network;

Transaction Support in Sharded Clusters

MongoDB 4.0+ supports cross-shard transactions, which imposes new requirements on config servers and mongos:

1. Config servers need to record transaction states
2. mongos needs to coordinate cross-shard transactions
3. More precise clock synchronization is required

Transaction example code:

const session = client.startSession();
try {
  session.startTransaction({
    readConcern: { level: "snapshot" },
    writeConcern: { w: "majority" }
  });
  
  await orders.insertOne({ user_id: "U1001", amount: 100 }, { session });
  await inventory.updateOne(
    { product: "A001" }, 
    { $inc: { stock: -1 } }, 
    { session }
  );
  
  await session.commitTransaction();
} catch (error) {
  await session.abortTransaction();
  throw error;
} finally {
  session.endSession();
}

Config Server Backup Strategies

Config server backups are critical. Recommended strategies include:

1. Regular replica set backups
2. Configuration file backups
3. Metadata exports

Example backup command:

# Use mongodump to backup config servers
mongodump --host configReplSet/cfg1:27019,cfg2:27019,cfg3:27019 \
  --db config --out /backup/config-$(date +%F)

mongos Monitoring Metrics

Key monitoring metrics include:

1. Query routing latency
2. Config cache hit rate
3. Connection count usage
4. Operation error rate

Example Prometheus monitoring configuration:

scrape_configs:
  - job_name: 'mongos'
    static_configs:
      - targets: ['mongos1:27017', 'mongos2:27017']
    metrics_path: '/metrics'
    params:
      format: ['prometheus']