The following checklist, along with the Operations Checklist, provides recommendations to help you avoid issues in your production MongoDB deployment.下面的清单以及操作检查表提供了一些建议，帮助您避免生产MongoDB部署中的问题。
Data Durability数据耐久性
Ensure that your replica set includes at least three data-bearing nodes with w:majoritywrite concern. 请确保您的副本集至少包括三个具有w:majority写入关注的数据承载节点。Three data-bearing nodes are required for replica-set wide data durability.需要三个数据承载节点才能实现副本集范围内的数据耐久性。
Data in MongoDB has a dynamic schema. MongoDB中的数据具有动态模式。Collections do not enforce document structure. 集合不强制文档结构。This facilitates iterative development and polymorphism. 这有助于迭代开发和多态性。Nevertheless, collections often hold documents with highly homogeneous structures. 尽管如此，集合通常包含具有高度同质结构的文档。See Data Modeling Concepts for more information.有关详细信息，请参阅数据建模概念。
Determine the set of collections that you will need and the indexes required to support your queries. 确定支持查询所需的集合集和索引。With the exception of the _id index, you must create all indexes explicitly: MongoDB does not automatically create any indexes other than _id.除了_id索引之外，您必须显式创建所有索引：MongoDB不会自动创建_id以外的任何索引。
Ensure that your schema design supports your deployment type: if you are planning to use sharded clusters for horizontal scaling, design your schema to include a strong shard key. 确保您的架构设计支持您的部署类型：如果您计划使用分片集群进行水平扩展，请将架构设计为包含强分片键。While you can change your shard key later, it is important to carefully consider your shard key choice to avoid scalability and perfomance issues.虽然您可以稍后更改分片键，但仔细考虑分片键的选择以避免可伸缩性和性能问题非常重要。
Ensure that your schema design does not rely on indexed arrays that grow in length without bound. 确保您的架构设计不依赖长度增长而没有绑定的索引数组。Typically, best performance can be achieved when such indexed arrays have fewer than 1000 elements.通常，当此类索引数组的元素少于1000个时，可以实现最佳性能。
Consider the document size limits when designing your schema. 设计架构时，请考虑文档大小限制。The BSON Document Size limit is 16MB per document. BSON文档大小限制为每个文档16MB。If you require larger documents, use GridFS.如果需要较大的文档，请使用GridFS。
Replication复制
Use an odd number of voting members to ensure that elections proceed successfully. 使用奇数个投票成员以确保选举顺利进行。You can have up to 7 voting members. 您最多可以有7名投票成员。If you have an even number of voting members, and constraints, such as cost, prohibit adding another secondary to be a voting member, you can add an arbiter to ensure an odd number of votes. 如果您有偶数个投票成员，并且限制（如成本）禁止添加另一个辅助成员作为投票成员，则可以添加仲裁器以确保奇数个投票。For additional considerations when using an arbiter for a 3-member replica set (P-S-A), see Replica Set Arbiter.有关为3成员副本集（P-S-a）使用仲裁器时的其他注意事项，请参阅副本集仲裁器。
Note注意
For the following MongoDB versions, pv1 increases the likelihood of w:1 rollbacks compared to pv0(no longer supported in MongoDB 4.0+) for replica sets with arbiters:对于以下MongoDB版本，对于具有仲裁器的副本集，与pv0（MongoDB 4.0+不再支持）相比，pv1增加了w:1回滚的可能性：
For MongoDB 3.6 and later, secondaries no longer return orphaned data unless using read concern "available" (which is the default read concern for reads against secondaries when not associated with causally consistent sessions).对于MongoDB 3.6及更高版本，辅助设备不再返回孤立数据，除非使用读关注点"available"（这是在不与因果一致会话关联时对辅助设备进行读取的默认读关注点）。 Starting in MongoDB 3.6, all members of the shard replica set maintain chunk metadata, allowing them to filter out orphans when not using "available". 从MongoDB 3.6开始，分片副本集的所有成员都维护块元数据，允许它们在不使用"available"时筛选掉孤儿。As such, non-targeted or broadcast queries that are not using "available" can be safely run on any member and will not return orphaned data.因此，不使用"available"的非目标或广播查询可以在任何成员上安全运行，并且不会返回孤立数据。 The "available" read concern can return orphaned documents from secondary members since it does not check for updated chunk metadata. "available"读取关注点可以从辅助成员返回孤立文档，因为它不检查更新的块元数据。However, if the return of orphaned documents is immaterial to an application, the "available" read concern provides the lowest latency reads possible among the various read concerns.但是，如果孤立文档的返回对应用程序无关紧要，"available"读取关注点提供了各种读取关注点中可能的最低延迟读取。
Pre-split and manually balance chunks when inserting large data sets into a new non-hashed sharded collection. 在将大型数据集插入新的非散列分片集合时，预分割并手动平衡块。Pre-splitting and manually balancing enables the insert load to be distributed among the shards, increasing performance for the initial load.预拆分和手动平衡使插入负载能够在分片之间分布，从而提高初始负载的性能。
Drivers驱动程序
Make use of connection pooling. Most MongoDB drivers support connection pooling. 利用连接池。大多数MongoDB驱动程序支持连接池。Adjust the connection pool size to suit your use case, beginning at 110-115% of the typical number of concurrent database requests.调整连接池大小以适应您的用例，从并发数据库请求的典型数量的110-115%开始。
Ensure that your applications handle transient write and read errors during replica set elections.确保应用程序在副本集选择期间处理暂时的写和读错误。
Ensure that your applications handle failed requests and retry them if applicable. 确保应用程序处理失败的请求，并在适用时重试。Drivers do not automatically retry failed requests.驱动程序不会自动重试失败的请求。
Use exponential backoff logic for database request retries.对数据库请求重试使用指数回退逻辑。