In-Memory Storage Engine
On this page
Changed in version 3.2.6.
Starting in MongoDB Enterprise version 3.2.6, the in-memory storage engine is part of general availability (GA) in the 64-bit builds. Other than some metadata and diagnostic data, the in-memory storage engine does not maintain any on-disk data, including configuration data, indexes, user credentials, etc.
By avoiding disk I/O, the in-memory storage engine allows for more predictable latency of database operations.
To select the in-memory storage engine, specify:
--storageEngineoption, or the
storage.enginesetting if using a configuration file.
storage.dbPathif using a configuration file. Although the in-memory storage engine does not write data to the filesystem, it maintains in the
--dbpathsmall metadata files and diagnostic data as well temporary files for building large indexes.
For example, from the command line:
Or, if using the YAML configuration file format:
See inMemory Options for configuration options specific to this storage engine. Most
mongod configuration options are available for use with in-memory storage engine except for those options that are related to data persistence, such as journaling or encryption at rest configuration.
The in-memory storage engine does not persist data after process shutdown.
The in-memory storage engine uses document-level concurrency control for write operations. As a result, multiple clients can modify different documents of a collection at the same time.
In-memory storage engine requires that all its data (including indexes, oplog if
mongod instance is part of a replica set, etc.) must fit into the specified
--inMemorySizeGB command-line option or
storage.inMemory.engineConfig.inMemorySizeGB setting in the YAML configuration file.
By default, the in-memory storage engine uses 50% of physical RAM minus 1 GB.
If a write operation would cause the data to exceed the specified memory size, MongoDB returns with the error:
Or use the command-line option
The in-memory storage engine is non-persistent and does not write data to a persistent storage. Non-persisted data includes application data and system data, such as users, permissions, indexes, replica set configuration, sharded cluster configuration, etc.
If any voting member of a replica set runs without journaling (i.e. either runs an in-memory storage engine or runs with journaling disabled), you must set
Starting in version 3.6.14, if a replica set member uses the in-memory storage engine (voting or non-voting) but the replica set has
writeConcernMajorityJournalDefault set to true, the replica set member logs a startup warning.
writeConcernMajorityJournalDefault set to
false, MongoDB does not wait for
w: "majority" writes to be written to the on-disk journal before acknowledging the writes. As such,
majority write operations could possibly roll back in the event of a transient loss (e.g. crash and restart) of a majority of nodes in a given replica set.
Write operations that specify a write concern
journaled are acknowledged immediately. When an
mongod instance shuts down, either as result of the
shutdown command or due to a system error, recovery of in-memory data is impossible.
In addition to running as standalones,
mongod instances that use in-memory storage engine can run as part of a replica set or part of a sharded cluster.
You can deploy
mongod instances that use in-memory storage engine as part of a replica set. For example, as part of a three-member replica set, you could have:
mongodinstances run with in-memory storage engine.
mongodinstance run with WiredTiger storage engine. Configure the WiredTiger member as a hidden member (i.e.
With this deployment model, only the
mongod instances running with the in-memory storage engine can become the primary. Clients connect only to the in-memory storage engine
mongod instances. Even if both
mongod instances running in-memory storage engine crash and restart, they can sync from the member running WiredTiger. The hidden
mongod instance running with WiredTiger persists the data to disk, including the user data, indexes, and replication configuration information.