MongoDB's flexibility in supporting different storage engines provides a unique opportunity to optimize read and write performances. One interesting combination that administrators sometimes consider is using the in-memory MongoDB as the primary node, along with WiredTiger as a non-voting replica. This configuration aims to leverage the ultra-fast access times of in-memory databases while maintaining a persistent backup using WiredTiger.

In this article, we will explore the technical feasibility, setup, implications, and limitations of such a configuration. We assume that the reader is already familiar with the basic principles of MongoDB, replica sets, and storage engines.

Technical Explanation

In-Memory Storage Engine (EphemeralForTest)

MongoDB offers an in-memory storage engine primarily for scenarios where performance is critical and data can be considered volatile. This storage engine uses RAM for read/write operations, resulting in extremely fast data access. However, the data is lost when the MongoDB process is stopped or restarted, as it is not persisted to disk.

Key characteristics:

• Speed: In-memory operations provide the lowest possible latency.
• Volatility: All data is lost on restarts. Designed for temporary data storage or testing.
• No journal: Doesn't provide durability guarantees.

WiredTiger Storage Engine

WiredTiger is MongoDB's default storage engine, designed for high-performance and efficient disk storage. It supports advanced features like compression and concurrency within data management.

Key characteristics:

• Durability: Data changes are written to disk with journaling enabled by default.
• Compression: Efficient storage through snappy or zlib compression algorithms.
• Concurrency: Improved performance with document-level concurrency control.

Combining In-Memory and WiredTiger

Application and Feasibility

The idea of using an in-memory storage engine as a primary node with a non-voting WiredTiger replica is interesting but raises several points of consideration:

1. Primary Role: The in-memory node will handle all write operations and provide fast read access. However, any issues or reboots will lead to complete data loss unless data is synchronously replicated to a persistent storage engine.
2. Non-Voting Replica: WiredTiger instances can be added as non-voting replicas to handle persistent storage. They will not participate in election processes and cannot impact the primary node's role.
3. Data Consistency: In-memory nodes might deliver data inconsistencies during failovers or restarts, leading potentially to old snapshots of data being promoted if the WiredTiger node becomes primary for some reason.
4. Best Use Case: Suitable for applications needing rapid data access with well-managed downtime strategies and a tolerance for data loss. Additionally, scenarios needing a non-persistent cache with a reliable data store can utilize this combination effectively.

Example Setup

The following commands provide a step-by-step deployment for setting up an in-memory MongoDB node with a non-voting WiredTiger replica.

1# Start the in-memory MongoDB as primary
2mongod --port 27017 --dbpath /data/db-primary --storageEngine ephemeralForTest --replSet rs0
3
4# Start the WiredTiger as a secondary non-voting node
5mongod --port 27018 --dbpath /data/db-secondary --replSet rs0

Next, configure the replica set:

1rs.initiate({
2  _id: "rs0",
3  members: [
4    { _id: 0, host: "localhost:27017", priority: 1 },
5    { _id: 1, host: "localhost:27018", priority: 0, votes: 0 }
6  ]
7});

Considerations and Limitations

• No Durability on Primary: An abrupt power failure or restart results in data loss.
• Recovery Speed: Although data serving is fast, recovery from any node termination could delay overall application responsiveness due to data replay or re-initiation from secondaries.
• Failover Concerns: Without additional voting nodes, the failover might promote a non-durable data state.
• Data Distribution: As the WiredTiger nodes are non-voting, all read/write operations will be primary-centric.

Summary

Below is a table summarizing the main attributes of the proposed configuration:

Conclusion

Utilizing an in-memory primary with WiredTiger as a non-voting replica is a viable strategy for applications requiring fast access to transient data, with the side benefit of having durable copies available if well-managed. However, robust procedures must be established to prevent data inconsistencies and manage downtime effectively. As always, the specific needs and constraints of the application environment will guide the suitability of this configuration.