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

In a MongoDB sharded cluster, the config servers are responsible for storing cluster metadata, including the chunk ranges of sharded collections, data distribution locations, etc. They are typically deployed as a 3-node replica set to ensure high availability. The mongos acts as the query router, fetching metadata from the config servers, directing or broadcasting queries to the appropriate shards based on query conditions, and merging the results. High availability for config servers is achieved through replica sets with automatic failover. Multiple mongos instances should be deployed to enable load balancing and optimize performance through connection pool management. The sharded cluster supports cross-shard transactions, which impose new requirements on both config servers and mongos. Backup strategies for config servers include regular replica set backups and metadata exports. Key metrics to monitor for mongos include query routing latency and config cache hit rates.

Sharding strategies (range sharding, hash sharding, zone sharding)

MongoDB sharding strategies determine how data is distributed across a sharded cluster, primarily including range-based sharding, hash-based sharding, and zone sharding. Range-based sharding allocates data based on the range of shard key values, making it suitable for scenarios with frequent range queries or time-ordered data, but it may lead to uneven data distribution. Hash-based sharding uses a hash function to randomly distribute data, ideal for high-write workloads requiring even load balancing, but it does not support efficient range queries. Zone sharding extends range-based sharding by allowing data allocation based on geographic or logical groupings, suitable for scenarios requiring fine-grained control over data placement, though it involves complex configuration. Choosing a sharding strategy requires considering query patterns, write patterns, data growth, hardware configurations, and compliance requirements. Compound shard keys can combine the advantages of different strategies. After implementation, continuous monitoring of data distribution and query performance is essential. The shard key automatically becomes an index and is closely related to index design, impacting query efficiency.

Shard key selection strategy

The MongoDB shard key is the core mechanism that determines data distribution, and a rational choice ensures load balancing and query efficiency. The shard key must meet immutability, indexing, and cardinality requirements. The three main types include: hashed shard keys, suitable for high-write scenarios; range shard keys, which support efficient range queries; and compound shard keys, which balance query performance and even distribution. When selecting a shard key, considerations such as balanced data distribution, query pattern alignment, and shard key cardinality must be taken into account to avoid hotspot issues. Special scenarios like time-series data, multi-tenant systems, and geospatial data have specific design strategies. Once set, the shard key cannot be changed but can be indirectly adjusted through data migration. Monitoring the shard cluster status, focusing on data volume disparities, read/write loads, and query routing, is crucial for optimization.

A sharded cluster architecture

A MongoDB sharded cluster achieves horizontal scaling through shard configuration servers and query routing, with core components including shards that store subsets of data, config servers that store metadata, and mongos instances that route requests. Data distribution relies on shard keys, supporting three strategies: range sharding, hash sharding, and compound shard keys. Production deployments require config server replica sets and shard server replica sets. Performance optimization includes pre-splitting shard ranges and setting read/write concerns. Common issues involve the immutability of shard keys and cross-shard transaction handling. Monitoring shard balancing status and data distribution is essential. Special collections, such as unsharded collections and small collections, require special handling. Sharded clusters have constraints like aggregation pipeline limitations and the requirement that unique indexes must include the shard key.

Replica set monitoring and troubleshooting

Monitoring MongoDB replica sets is a critical step in ensuring high availability. The `rs.status()` command provides core data such as member status, optime, and heartbeat information. Health checks should focus on the `health` status and optime differences to detect replication delays. Key metrics to monitor include operation counters, replication buffers, and network latency. Common failure scenarios involve primary node unavailability, broken replication chains, and rollback data recovery. Advanced diagnostic tools such as replication stream analysis, Oplog window calculation, and heartbeat packet analysis help in-depth troubleshooting. Automated monitoring can be achieved through Prometheus metric exports and custom alerting rules. Performance optimization practices include read/write concern configuration, index synchronization validation, and batch operation tuning.

Replica set configuration and management

A MongoDB replica set consists of multiple nodes, including a primary node and secondary nodes, providing data redundancy and high availability. The primary node handles write operations, while secondary nodes replicate data from the primary. If the primary node becomes unavailable, a new primary is automatically elected. A typical configuration requires three nodes: a primary, a secondary, and an optional arbiter node. To configure a replica set, start the `mongod` process and specify the replica set name, then initialize it using `rs.initiate()`. You can configure member priorities and hidden nodes. Managing a replica set includes monitoring its status, adding or removing nodes, and testing failover. Advanced configurations involve setting read/write concerns, controlling data synchronization, and adjusting the oplog size. Security configurations include replica set authentication and TLS encryption. Performance optimization covers read/write separation and index management. Common issues involve resolving sync delays and election problems. Backup strategies use `mongodump`, and point-in-time recovery leverages the oplog.

Read-write separation and load balancing

Read-write separation is a database architecture design pattern that distributes read and write operations to different server nodes. MongoDB implements read-write separation through replica sets, where the primary node handles write operations and secondary nodes handle read operations. This architecture improves read performance and system availability, making it suitable for high-read-load scenarios. MongoDB offers various read preference settings to control the routing of read operations. Load balancing can be achieved through connection pool management, sharded clusters, and proxy middleware. Monitoring replication lag and performance metrics is crucial for ensuring normal system operation. Common issues include data consistency, load imbalance, and connection storms. Advanced configurations involve sharding strategies, read/write concern levels, and index optimization. Performance testing and capacity planning are essential steps before implementation. Security considerations include authentication, authorization, network isolation, and encryption.

Data synchronization (Oplog) and delayed nodes

MongoDB replica sets achieve data synchronization through the Oplog, which is a fixed-size capped collection that records all data modification operations and is designed with idempotency. Secondary nodes request the required Oplog entries based on their state, and the synchronization process includes initial sync and continuous replication. Delayed nodes are specially configured replica set members with the `slaveDelay` parameter setting the delay time. They cannot become primary nodes and are typically hidden from clients. Delayed nodes receive Oplog entries normally but apply data changes with a delay, making them suitable for data recovery and read-write separation scenarios. Performance can be improved by adjusting the Oplog size and optimizing the network. Key monitoring metrics include replication lag and Oplog status. Advanced configurations support multiple delayed nodes and hybrid storage engines. In a sharded cluster, each shard is an independent replica set, and delayed node configurations must be combined with shard tags and query routing.

Election mechanism and failover

MongoDB achieves high availability through replica sets, with its core mechanisms being election and failover. A replica set consists of a primary node, secondary nodes, and an arbiter node. The primary node handles write operations, while secondary nodes replicate data, and the arbiter node participates in elections. Elections are triggered when a node fails or is manually demoted, involving heartbeat detection, eligibility checks, and majority voting. Successful elections require majority support. Failover scenarios include physical failures of the primary node and network partitions, where the majority principle prevents split-brain situations. Configuration optimizations involve adjusting election timeouts and using hidden delayed nodes. Monitoring replication lag and election counts is critical. Clients should be configured with multiple node connections to support automatic failover. During elections, write operations are paused, but read operations can be scaled through secondary nodes. All nodes should maintain consistent indexes.

Primary node (Primary) and secondary node (Secondary)

MongoDB replica sets achieve high availability through primary and secondary nodes. The primary node handles all write operations and records them in the oplog, while secondary nodes asynchronously replicate data and participate in elections if the primary fails. The primary is responsible for write and read requests and maintains the replica set state, while secondaries provide data redundancy, read scaling, and disaster recovery. Failover is based on priority, data freshness, and voting rights. Read-write separation can be configured via read preferences, but data latency must be considered. Replica set configurations include priority, hidden nodes, delayed nodes, and arbiters. Write concern levels impact data consistency. Performance optimization involves oplog size, indexing strategies, and network tuning. Common issues include high replication lag, frequent elections, and primary node stalls, requiring targeted troubleshooting.