Configure a Mongo replica set to only replicate certain collections
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.
MongoDB is a popular NoSQL database known for its flexibility and scalability. One of its core features is its ability to replicate data across multiple servers, known as a replica set. This ensures high availability and redundancy, enabling the database to recover from server failures. However, there are scenarios where you may want to replicate only specific collections within a database. This article explores how to configure a MongoDB replica set to replicate only certain collections.
Understanding MongoDB Replication
MongoDB replication is the process of synchronizing data across multiple servers. It involves three types of nodes:
- Primary Node: The node that receives all write operations.
- Secondary Nodes: Nodes that replicate the primary node's data.
- Arbiter Nodes: Nodes that participate in voting but do not contain data.
Data replication occurs at the database level in MongoDB, meaning that by default, the entire database is replicated across the replica set. However, certain use cases may require selective replication. For instance, in scenarios where network bandwidth is constrained or when specific collections are not needed on all nodes.
Replicating Specific Collections
MongoDB does not support out-of-the-box selective collection replication. However, you can achieve this behavior using a combination of configuration settings and application logic.
Approach 1: Filter with Oplog
MongoDB's replication is driven by an oplog (operations log). You must filter out unwanted operations with a custom script or tool that processes the oplog on secondary nodes to achieve collection-level filtering. Below are high-level steps:
- Setup a Change Stream on Oplog: Utilize MongoDB's
change streamsfeature to listen for changes in specific collections. Create a change stream only for the collections you wish to replicate. - Custom Script for Synchronization: Develop a custom script or application that observes these changes and applies them to the desired collections on secondary nodes.
- Disable Direct Replica Set Synchronization: Use network or firewall rules to prevent standard replication traffic to specific secondary nodes directly.
- Apply Changes to Secondary: The script will manually invoke changes to secondaries that you selectively wish to replicate.
Approach 2: Application-Level Logic
Another option is to delegate replication control to the application itself.
- Selective Write Operations: Modify the application’s data write logic to selectively distribute data to specific nodes. This could involve writing to certain nodes only from specific parts of the application.
- Data Synchronization Scripts: Regularly run scripts to sync specific collections to nodes, bypassing MongoDB's replication.
Important Considerations
- Consistency and Atomicity: Manual replication management can introduce consistency issues or violate atomicity guarantees. Ensure your solution maintains data integrity.
- Performance Overhead: Be cautious of potential overheads due to additional scripting and network operations.
- Operational Complexity: Such configurations introduce additional complexity in monitoring and maintaining the database system.
- Maintenance: Updates to MongoDB may change oplog formats or replication mechanisms; thus, require ongoing maintenance of custom scripts.
Summary Table
| Feature | Description |
| Ability to Replicate Specific Collections | Achievable through custom scripts and application logic; not natively supported. |
| Implementations | Oplog change stream handling, application logic changes, custom scripts. |
| Consistency Impact | Requires careful implementation to maintain data consistency. |
| Performance | Additional scripts may introduce latency or processing overhead. |
| Maintenance | Increases operational complexity and requires ongoing maintenance. |
Conclusion
While MongoDB does not directly support selective collection replication through its built-in replication features, it is feasible through custom implementations. These approaches require in-depth knowledge of MongoDB's architecture and are manageable with close monitoring and systematic management. Before proceeding with such a setup, thoroughly evaluate your use case and implement robust testing and monitoring strategies to ensure reliable performance and data consistency.
Related reading
- Configure a new serializer for spring-boot redis cache config
- Configure hadoop/hbase in fully-distributed mode
- Configuring SQL Server 2005 with both server replication and client replication
- Confluent Cloud - Spring Boot Consumer REST Endpoint?
- Configure DynamoDB stream trigger with insert only
- Configure specific in memory database for testing purpose in Spring
- Configure input_map when importing a tensorflow model from metagraph file
- confused about random_state in decision tree of scikit learn

System Design Fundamentals
Build a strong foundation in designing scalable, reliable distributed systems.
View the courseTrack what you have practised
A free account saves your progress, solutions and study plan across every problem on Codemia.
System Design practice on Codemia
Work through 120+ system design problems with detailed solutions, from rate limiters to multi-region storage.