Overview

MongoDB is a document-oriented NoSQL database that stores data in flexible, JSON-like documents (Wikipedia Contributors 2019). Unlike traditional relational databases, MongoDB does not require a predefined schema, allowing for dynamic and hierarchical data structures. This flexibility makes it particularly suitable for applications that handle diverse and evolving data formats, such as content management systems, real-time analytics platforms, and Internet of Things (IoT) applications. Its scalability and performance are further enhanced by features like horizontal scaling and high availability.

Replication Support

MongoDB implements replication through a feature called replica sets. A replica set consists of multiple MongoDB instances (nodes) that maintain the same dataset, providing redundancy and high availability (Team 2025). In a typical replica set, one node is designated as the primary, while the others serve as secondaries. The primary node handles all write operations, and the secondaries replicate the primary’s data asynchronously. If the primary node fails, an automatic election process promotes one of the secondaries to become the new primary, ensuring continuous availability.

To set up replication, MongoDB requires a minimum of three nodes: one primary and two secondaries (ActiveLobby Team 2021). Details in following picture. This configuration ensures fault tolerance and allows for automatic failover. Additionally, MongoDB supports the use of arbiters—nodes that participate in elections but do not hold data—to maintain an odd number of voting members, which is essential for achieving consensus during elections.
MongoDB Replication

Implications for Application Development

When developing applications that interact with a replicated MongoDB setup, several considerations come into play:

  • Read and Write Operations: By default, all write operations are directed to the primary node to maintain data consistency (Ishita Srivastava 2024). However, applications can be configured to read from secondary nodes to distribute the read load and improve performance. This approach, while beneficial for scalability, may introduce eventual consistency, as secondaries replicate data asynchronously.
  • Handling Failover: Applications should be designed to handle automatic failovers gracefully. This involves configuring the MongoDB drivers to detect changes in the primary node and reroute operations accordingly. Proper error handling and retry mechanisms are essential to ensure seamless operation during node transitions.
  • Data Consistency: Developers must be aware of the consistency model of MongoDB. While reading from the primary ensures strong consistency, reading from secondaries may result in stale data due to replication lag. Applications that require up-to-date information should enforce read preferences accordingly.
  • Performance Optimization: Leveraging secondary nodes for read operations can enhance performance, especially in read-heavy applications. Additionally, implementing caching strategies can reduce the load on the database and improve response times.

In general, while MongoDB’s replication features offer significant benefits in terms of availability and scalability, they also introduce complexities that developers must address. Understanding the replication mechanics and designing applications with these considerations in mind is crucial for building robust and efficient systems.

Deploy MongoDB Replica Set In Kubernetes

To deploy a MongoDB replica set in a Kubernetes environment, you can follow these general steps:

  1. Create ConfigMaps and Secrets: Store MongoDB configuration files and sensitive information like passwords using ConfigMaps and Secrets.
  2. Define Persistent Volume Claims (PVCs): Set up PVCs to ensure data persistence for each MongoDB pod.
  3. Create a StatefulSet: Use a StatefulSet to manage the MongoDB pods, ensuring that each pod has a stable network identity and persistent storage.

Prerequisites:

  • Create openssl-cert secret for internal authentication between replica set members.
1
2
3
sudo bash -c "openssl rand -base64 756 > mongodb-keyfile"
sudo chmod 400 mongodb-keyfile
kubectl create secret generic keyfile --from-file=mongodb-keyfile

repository

1
2
3
4
5
kubectl apply -f storageclass.yaml
kubectl apply -f db-configMap.yaml
kubectl apply -f db-secret.yaml
kubectl apply -f db-service.yaml
kubectl apply -f db-statefulSet.yaml

Initial ReplicaSet

1
kubectl exec -it mongodb-rs-0 -- mongosh

1
2
3
4
5
6
7
8
9
use admin
rs.initiate({
  _id: "rs0",
  members: [
    { _id: 0, host: "mongodb-0.mongodb-service:27017", priority: 2 },
    { _id: 1, host: "mongodb-1.mongodb-service:27017", priority: 1 },
    { _id: 2, host: "mongodb-2.mongodb-service:27017", priority: 1 }
  ]
})

Referencing

[1] ActiveLobby Team 2021, 5 Steps to Configure MongoDB Replication: A Complete Guide, Activelobby Support, viewed 4 June 2025, available: https://blog.supportlobby.com/yourdomain-com-mongodb-replication-guide/ , accessed 4 June 2025.
[2] Ishita Srivastava 2024, Understanding Replication and High Availability in MongoDB | Code by Zeba Academy, Code by Zeba Academy, available: https://code.zeba.academy/replication-availability-mongodb/, accessed 4 June 2025.
[3] Team, MD 2025, Replication, Mongodb.com, viewed 4 June 2025, available: https://www.mongodb.com/docs/v7.0/replication. accessed 4 June 2025.
[4] WebHi 2025, MongoDB sharding and replication guide - Tutorial & Documentation, Tutorial & Documentation, viewed 4 June 2025, available: https://www.webhi.com/how-to/mongodb-sharding-and-replication-guide/, accessed 4 June 2025.
[5] Wikipedia Contributors 2019, MongoDB, Wikipedia, Wikimedia Foundation, available: https://en.wikipedia.org/wiki/MongoDB, accessed 4 June 2025.