Rich text fundamentals/clusters

Background Wrapper fundamentals/clusters

Below is an example of how to connect with the MongoDB Shell. Substitute the following configuration settings (MongoDB Atlas cluster name, database name, and username) in the 

Note: When using the MongoDB Shell like above, you will be prompted to type the password that you submitted when the MongoDB deployment was created.

Whether your initial intentions are about developing proof of concept applications or planning for a production environment, a very good starting point is to create a new MongoDB cluster on MongoDB Atlas. By using the free tier, the default setup is to deploy a MongoDB cluster with a 

,  then you have to enable this feature separately and specify the number of shards to have.

A MongoDB replica set ensures replication is enforced by providing data redundancy and high availability over more than one MongoDB server. 

If a MongoDB deployment lacked a replica set, that means all data would be present in exactly one server. In case that main server fails, then all data would be lost - but not when a replica set is enabled. Therefore, we can immediately see the importance of having a replica set for a MongoDB deployment.

In addition to fault tolerance, replica sets can also provide extra read operations capacity for the MongoDB cluster, directing clients to the additional servers, subsequently reducing the overall load of the cluster. 

Replica sets can also be beneficial for distributed applications due to the data locality they offer, so that faster and parallel read operations happen to the replica sets instead of having to go through one main server.

A MongoDB replica set consists of a primary node and multiple secondary nodes working together to ensure data availability and durability.

The primary node handles all write operations and maintains an 

 - a special capped collection that records all data modifications. There can only be one primary node active at any time in a replica set.

Secondary nodes continuously replicate the primary's oplog and apply these operations to maintain identical copies of the data. This asynchronous replication mechanism ensures the replica set can continue functioning even if some members fail.

becomes unavailable, the replica set initiates an election to select a new primary from among the secondary nodes. Elections can be triggered by various events:

Read and write operations in a replica set

MongoDB's replica set implementation is transparent to client applications - they interact with the cluster the same way regardless of whether it's running as a single server or with replication enabled.

While MongoDB directs all write operations to the primary node, it offers flexible read operation routing through read preferences. By default, read operations target the primary node, but applications can optionally specify different read preferences to direct queries to secondary nodes. This capability allows applications to:

Several read preference modes can be configured. For example, if a client application is configured to go directly to secondaries, then the mode parameter in the read preference should be set to 

. If there are specific needs for the least network latency irrespective of whether that happens in the primary or any secondary node, then the 

 read preference mode should be configured. However, in this option, a risk of potentially stale data comes into play (if the nearest node is a secondary node) due to the nature of 

Alternatively, the read preference mode can be set to  

. These two modes also make use of another property called 

 to determine to which node of the replica set should the read operation be directed. In all cases where there is a chance for the read operation to happen on a non-primary node, you must ensure that your application can tolerate stale data.

When writing data in a MongoDB replica set, you can include additional options to ensure that the write has propagated successfully throughout the cluster. This involves adding a 

 property alongside an insert operation. A write concern means what level of acknowledgement we desire to have from the cluster upon each write operation, and it consists of the following options:

, meaning that no write acknowledgement is needed. 

 is the default and it means that it only requires the primary node to acknowledge the write, while any number greater than 1 corresponds to the number of nodes plus the primary that need to acknowledge. For example, 

 secondaries need to signal as well as the primary node.

 value corresponds to whether MongoDB has been written on disk in a special area called the  

. This is used from MongoDB for recovery purposes in case of a hard shutdown, and it is enabled by default.

 value is the time the command should wait before returning any result. If this is not specified and if for any reason the actual write has any network issues, then the command would block indefinitely, so it is a good practice to set this value. It is measured in milliseconds and it is only applicable for 

In the following example, if we had a 5-node replica set, we are requesting that the 

option) of the nodes (3) replies back with a successful write acknowledgment:

. The first parameter is the document that will be inserted into the 

 collection. The second parameter is the write concern, which specifies that the write operation must be acknowledged by a majority of the data-bearing nodes within a five-second timeout period.

 datasets across multiple shards (servers) to achieve horizontal scalability and improved performance for both read and write operations.

In the above diagram, Collection1 is sharded across multiple servers, while Collection2 remains unsharded. If Collection1 were confined to a single server, that server's CPU could become overwhelmed due to insufficient capacity to handle incoming requests. By distributing Collection1 across multiple shards, the system can better handle the workload by spreading it across more computing resources.

A robust production MongoDB deployment requires careful planning around several key aspects:

To ensure business continuity and minimize downtime, deploy MongoDB replica sets across one or multiple regions based on your risk assessment and recovery requirements.

Each replica set consists of a primary mongod process and multiple secondary processes. It is recommended to maintain an odd number of mongod processes to ensure a majority vote can be reached when the primary fails and a new primary needs to be elected.

While proper data modeling, collection design, and indexing strategies are foundational, sharding is essential for handling large-scale production workloads. A well-planned sharding strategy enables your MongoDB cluster to scale horizontally as data volumes grow, maintain performance under heavy workloads, and distribute data and queries across multiple servers.

When designing your production environment, it's important to plan your sharding strategy early, even if you don't implement it immediately. This forward-thinking approach helps ensure your application can scale smoothly as your data and traffic grow.

Rich text2 fundamentals/clusters

Rich text3 fundamentals/clusters

FAQs

FAQs section overview

In MongoDB, a cluster refers to a group of servers or nodes that work together to store and manage data, while a collection is a grouping of documents within a database, similar to a table in a relational database.

You can have multiple clusters, each consisting of multiple nodes, enabling horizontal scaling and high availability.

A MongoDB cluster is a set of connected MongoDB instances (nodes) that work together to provide redundancy, high availability, and scalability for handling large volumes of data.

none

Accordions fundamentals/clusters

Ready to get started?

Launch a new cluster or migrate to MongoDB Atlas with zero downtime.

SEO Section Overview-fundamentals/clusters

Join us Sept 17 at .local NYC! Use code WEB50 to save 50% on tickets Learn more >

MongoDB Clusters

FAQs

What is the difference between a cluster and a collection in MongoDB?

How many clusters can you have in MongoDB?

What is a MongoDB cluster?

Ready to get started?