– A combination of cron+df can alert when disk space hits a high-water mark, if no other monitoring tool is available. 

## Load Balancing 

• Configure load balancers to enable “sticky sessions” or “client affinity”, with a sufficient timeout for existing connections. 

• Avoid placing load balancers between MongoDB cluster or replica set components. 

## 5.4.2 Development 

The following checklist, along with the Operations Checklist (page 311), provides recommendations to help you avoid issues in your production MongoDB deployment. 

## Data Durability 

• Ensure that your replica set includes at least three data-bearing nodes with w:majority write concern (page 130). Three data-bearing nodes are required for replica-set wide data durability. 

• Ensure that all instances use journaling (page 308). 

## Schema Design 

• Ensure that your schema design does not rely on indexed arrays that grow in length without bound. Typically, best performance can be achieved when such indexed arrays have fewer than 1000 elements. 

## Replication 

• Do not use secondary reads to scale overall read throughput. See: Can I use more replica nodes to scale 121 for an overview of read scaling. For information about secondary reads, see: Read Preference (page 588). 

## Sharding 

• Ensure that your shard key distributes the load evenly on your shards. See: Considerations for Selecting Shard Keys (page 694) for more information. 

• Use targeted queries (page 678) for workloads that need to scale with the number of shards. 

• Always read from primary nodes for non-targeted queries that may be sensitive to stale or orphaned data$^{122}$. 

• Pre-split and manually balance chunks (page 722) when inserting large data sets into a new non-hashed sharded collection. Pre-splitting and manually balancing enables the insert load to be distributed among the shards, increasing performance for the initial load. 

