Optimizing MongoDB Config Server Storage: Reducing Journal File Size for Sharded Clusters


3 views

When deploying a sharded MongoDB cluster, the configuration servers (typically a 3-member replica set) handle critical metadata about chunk distributions and sharding topology. While these servers are indeed "lightweight" in terms of CPU and memory usage, their default storage configuration can be surprisingly heavy.

MongoDB uses write-ahead journaling by default to:

  • Ensure crash recovery
  • Maintain write durability
  • Provide atomicity guarantees

The journal preallocates files in the journal/ directory, typically consuming ~3GB space regardless of actual data volume.

For config servers, we can safely modify journal settings because:

// Sample mongod.conf adjustments
storage:
  journal:
    enabled: true  # Keep enabled for production
    commitIntervalMs: 100  # Increase from default 100ms
  smallFiles: true  # Reduces preallocation sizes
  directoryPerDB: false  # Simplifies storage structure
// Alternative 1: Disable journaling (not recommended for production)
mongod --configsvr --nojournal --dbpath /data/configdb

// Alternative 2: Reduce journal size through filesystem
dd if=/dev/zero of=/journal bs=1M count=100  # Create 100MB journal
mkfs.ext4 /journal
mount -o loop /journal /data/configdb/journal

Key metrics to monitor after making changes:

  • Write latency during config changes
  • Recovery time after restart
  • Disk space utilization patterns

Always test changes in staging before production deployment. The config servers are critical to sharding operations - while optimizing storage is valuable, never compromise reliability for minor space savings.


When deploying a sharded MongoDB cluster, the three config servers (now called "config server replica sets" in newer versions) typically consume 3GB disk space each due to journal preallocation. This seems excessive for servers that primarily store:

  • Cluster metadata (chunk ranges, shard mappings)
  • Authentication configurations
  • Small operational logs

For MongoDB 3.4+ (WiredTiger storage engine), consider these approaches:

# Option 1: Reduce journal size (MongoDB 3.2+)
mongod --configsvr --journal --smallfiles --wiredTigerJournalCompressor=none

# Option 2: Disable journaling entirely (not recommended for production)
mongod --configsvr --nojournal

Based on MongoDB JIRA tickets (SERVER-12468, SERVER-19123) and production deployments:

Approach Disk Savings Risk Level
--smallfiles Reduces to ~500MB Low
Disable journal Saves 3GB Medium (only for replica sets)
Compressed journal ~1.5GB savings Low

For a balanced approach in production environments:

storage:
  dbPath: /data/configdb
  journal:
    enabled: true
    commitIntervalMs: 100
  wiredTiger:
    engineConfig:
      journalCompressor: none
systemLog:
  destination: file
  path: /var/log/mongodb/configsvr.log
  logAppend: true
processManagement:
  fork: true
net:
  bindIp: 192.168.1.100
  port: 27019
sharding:
  clusterRole: configsvr
replication:
  replSetName: configReplSet

After implementing changes, monitor these metrics:

db.serverStatus().storageEngine.supportsCommittedReads
db.serverStatus().backgroundFlushing.last_finished
db.serverStatus().wiredTiger.log