生产注意事项

EC2¶

MongoDB is compatible with EC2 and requires no configuration changes specific to the environment.

VMWare¶

MongoDB is compatible with VMWare. Some in the MongoDB community have run into issues with VMWare’s memory overcommit feature and suggest disabling the feature.

You can clone a virtual machine running MongoDB. You might use this to spin up a new virtual host that will be added as a member of a replica set. If journaling is enabled, the clone snapshot will be consistent. If not using journaling, stop mongod, clone, and then restart.

OpenVZ¶

The MongoDB community has encountered issues running MongoDB on OpenVZ.

Swap¶

Configure swap space for your systems. Having swap can prevent issues with memory contention and can prevent the OOM Killer on Linux systems from killing mongod. Because of the way mongod maps memory files to memory, the operating system will never store MongoDB data in swap.

RAID¶

Most MongoDB deployments should use disks backed by RAID-10.

RAID-5 and RAID-6 do not typically provide sufficient performance to support a MongoDB deployment.

RAID-0 provides good write performance but provides limited availability, and reduced performance on read operations, particularly using Amazon’s EBS volumes: as a result, avoid RAID-0 with MongoDB deployments.

Remote Filesystems¶

Some versions of NFS perform very poorly with MongoDB and NFS is not recommended for use with MongoDB. Performance problems arise when both the data files and the journal files are both hosted on NFS: you may experience better performance if you place the journal on local or iscsi volumes. If you must use NFS, add the following NFS options to your /etc/fstab file: bg, nolock, and noatime.

Many MongoDB deployments work successfully with Amazon’s Elastic Block Store (EBS) volumes. There are certain intrinsic performance characteristics, with EBS volumes that users should consider.

MongoDB on NUMA Hardware¶

MongoDB and NUMA, Non-Uniform Access Memory, do not work well together. When running MongoDB on NUMA hardware, disable NUMA for MongoDB and run with an interleave memory policy. NUMA can cause a number of operational problems with MongoDB, including slow performance for periods of time or high system processor usage.

To disable NUMA for MongoDB, use the numactl command and start mongod in the following manner:

numactl --interleave=all /usr/bin/local/mongod

Adjust the proc settings using the following command:

echo 0 > /proc/sys/vm/zone_reclaim_mode

To fully disable NUMA you must perform both operations. However, you can change zone_reclaim_mode without restarting mongod. For more information, see documentation on Proc/sys/vm.

See the The MySQL “swap insanity” problem and the effects of NUMA post, which describes the effects of NUMA on databases. This blog post addresses the impact of NUMA for MySQL; however, the issues for MongoDB are similar. The post introduces NUMA its goals, and illustrates how these goals are not compatible with production databases.

iostat¶

On Linux, use the iostat command to check if disk I/O is a bottleneck for your database. Specify a number of seconds when running iostat to avoid displaying stats covering the time since server boot.

For example:

iostat -xm 2

Use the mount command to see what device your data directory resides on.

Key fields from iostat:

• %util: this is the most useful field for a quick check, it indicates what percent of the time the device/drive is in use.
• avgrq-sz: average request size. Smaller number for this value reflect more random IO operations.

bwm-ng¶

bwm-ng is a command-line tool for monitoring network use. If you suspect a network-based bottleneck, you may use bwm-ng to begin your diagnostic process.

64-bit Builds for Production¶

Always use 64-bit Builds for Production. MongoDB uses memory mapped files. See the 32-bit limitations for more information.

32-bit builds exist to support use on development machines and also for other miscellaneous things such as replica set arbiters.

BSON Document Size Limit¶

There is a BSON Document Size – at the time of this writing 16MB per document. If you have large objects, use GridFS instead.

Set Appropriate Write Concern for Write Operations¶

See write concern for more information.

Dynamic Schema¶

Data in MongoDB has a dynamic schema. Collections do not enforce document structure. This facilitates iterative development and polymorphism. However, collections often hold documents with highly homogeneous structures. See 数据建模 for more information.

Some operational considerations include:

• the exact set of collections to be used
• the indexes to be used, which are created explicitly except for the _id index
• shard key declarations, which are explicit and quite important as it is hard to change shard keys later

One very simple rule-of-thumb is not to import data from a relational database unmodified: you will generally want to “roll up” certain data into richer documents that use some embedding of nested documents and arrays (and/or arrays of subdocuments).

Updates by Default Affect Only one Document¶

Set the multi parameter to true to update multiple documents that meet the query criteria. The mongo shell syntax is:

db.my_collection_name.update(my_query, my_update_expression, bool_upsert, bool_multi)

Set bool_multi to true when updating many documents. Otherwise only the first matched will update.

Case Sensitive Strings¶

MongoDB strings are case sensitive. So a search for "joe" will not find "Joe".

Consider:

• storing data in a normalized case format, or
• using regular expressions ending with /i
• and/or using $toLower or $toUpper in the aggregation framework

Type Sensitive Fields¶

MongoDB data – which is JSON-style, specifically, BSON format – have several data types.

Consider the following document which has a field x with the string value "123":

{ x : "123" }

Then the following query which looks for a number value 123 will not return that document:

db.mycollection.find( { x : 123 } )

Locking¶

Older versions of MongoDB used a “global lock”; use MongoDB v2.2+ for better results. See the Concurrency page for more information.

Packages¶

Be sure you have the latest stable release if you are using a package manager. You can see what is current on the Downloads page, even if you then choose to install via a package manager.

Use Odd Number of Replica Set Members¶

Replica sets perform consensus elections. Use either an odd number of members (e.g., three) or else use an arbiter to get up to an odd number of votes.

Don’t disable journaling¶

See Journaling for more information.

Keep Replica Set Members Up-to-Date¶

This is important as MongoDB replica sets support automatic failover. Thus you want your secondaries to be up-to-date. You have a few options here:

1. Monitoring and alerts for any lagging can be done via various means. MMS shows a graph of replica set lag
2. Using getLastError with w:'majority', you will get a timeout or no return if a majority of the set is lagging. This is thus another way to guard against lag and get some reporting back of its occurrence.
3. Or, if you want to fail over manually, you can set your secondaries to priority:0 in their configuration. Then manual action would be required for a failover. This is practical for a small cluster; for a large cluster you will want automation.

Additionally, see information on replica set rollbacks.

Additional Deployment Considerations¶

• Pick your shard keys carefully! There is no way to modify a shard key on a collection that is already sharded.
• You cannot shard an existing collection over 256 gigabytes. To shard large amounts of data, create a new empty sharded collection, and ingest the data from the source collection using an application level import operation.
• Unique indexes are not enforced across shards except for the shard key itself. See 为片式集合强制使用唯一密钥.
• Consider pre-splitting a sharded collection before a massive bulk import. Usually this isn’t necessary but on a bulk import of size it is helpful.
• Use security/auth mode if you need it. By default auth is not enabled and mongod assumes a trusted environment.
• You do not have fully generalized transactions. Create rich documents and read the preceding link and consider the use case – often there is a good fit.
• Disable NUMA for best results. If you have NUMA enabled, mongod will print a warning when it starts.
• Avoid excessive prefetch/readahead on the filesystem. Check your prefetch settings. Note on linux the parameter is in sectors, not bytes. 32KBytes (a setting of 64 sectors) is pretty reasonable.
• Check ulimits settings.
• Use SSD if available and economical. Spinning disks can work well but SSDs capcity for random I/O operations work well with the update model of mongod. See Remote Filesystems for more info.
• Ensure that clients keep reasonable pool sizes to avoid overloading the connection tracking capacity of a single mongod or mongos instance.