MongoDB Manual (Version 4.2）> Administration
MongoDB开发检查列表以及操作检查列表提供了一些建议，帮助我们在生产环境下，避免MongoDB部署出现中的问题。
开发检查列表
- 数据持久性
- 模式设计
- 复制
- 分片
- 驱动
数据持久性
- 确保您的副本集包含至少三个带有w:majority写关注的数据承载节点。副本集范围内的数据持久性需要三个数据承载节点。
- 确保所有实例都使用日志。
模式设计
MongoDB中的数据有一个动态设计。集合强制执行文档结构。这有助于迭代开发和多态性。然而，集合通常保存具有高度同质结构的文档。有关详细信息，请参阅数据建模概念。
- 确定支持查询所需的集合集和所需的索引。除了_id 索引之外，您必须显式地创建所有索引：MongoDB不会自动创建除_id之外的任何索引。
- 确保模式设计支持您的部署类型：如果您计划使用分片集群进行水平扩展，请设计您的模式以包含一个强健的片键。片键通过确定MongoDB如何划分数据来影响读写性能。请参见：片键对集群操作的影响以获取有关片键应具有哪些质量的信息。一旦设置了片键，就不能更改它。
- 请确保您的模式设计不依赖长度不受限制的索引数组。通常，当这种索引数组的元素少于1000个时，可以获得最佳性能。
- 模式架构时请考虑文档大小限制。BSON文档大小限制为每个文档16MB。如果需要更大的文档，请使用GridFS。
复制
- 使用奇数个有投票权的成员来确保选举顺利进行。最多可以有7个有投票权的成员。如果您有偶数个投票成员，并且限制条件（如成本）禁止添加另一个辅助成员作为投票成员，则可以添加仲裁节点以确保票数为奇数。有关对3成员副本集（P-S-A）使用仲裁节点时的其他注意事项，请参阅副本集仲裁节点。
注意
对于以下MongoDB版本，对于具有仲裁器的副本集，与pv0（MongoDB 4.0 中不再支持）相比， pv1增加了 w:1 回滚的可能性：
- MongoDB 3.4.1
- MongoDB 3.4.1
- MongoDB 3.4.0
- MongoDB 3.4.0
- MongoDB 3.2.11 or earlier
- MongoDB 3.2.11 或者更早的版本
参见副本集协议版本。
- 通过使用监视工具 和指定适当的写入机制,，确保您的辅助文件保持最新。
- 不要使用辅助读取来扩展总体读吞吐量。请参阅：是否可以使用更多副本节点进行扩展，以了解读取扩展的概述。有关辅助读取的信息，请参阅：读取偏好 。
分片
- 确保片键将负载均匀地分配到分片上。请参见：片键以获取更多信息。
- 对需要根据切片数量进行扩展的工作负载使用目标操作。
- 对于MongoDB 3.4和更早版本，从主节点读取非目标或广播查询，因为这些查询可能对过时或孤立的数据敏感。
- 对于MongoDB 3.6和更高版本，辅助设备不再返回孤立数据，除非使用可用的读策略。{这是与因果一致会话不关联时针对辅助设备读取的默认读取策略}。 从 MongoDB 3.6 开始，分片副本集的所有成员都维护块元数据，允许它们在不使用“可用”时过滤出孤立的数据。因此，不使用“可用”的非目标或广播查询可以安全地在任何成员上运行，并且不会返回孤立的数据。 "可用"的读取策略可以从辅助成员返回孤立文档，因为它不检查更新的块元数据。但是如果孤立文档的返回对于应用程序来说无关紧要，那么"可用"的读取策略提供了各种读取关注点中可能的最低延迟读取。
- 在将大数据集插入新的非哈希分片集合时需要预分割并手动平衡块。预分割和手动平衡使插入负载能够在分片之间分布，从而提高初始负载的性能。
驱动
- 利用连接池。大多数MongoDB驱动程序支持连接池。调整连接池大小以适合您的用例，从典型并发数据库请求数的110-115%开始。
- 请确保您的应用程序在副本集选择期间处理短暂的写入和读取错误。
- 请确保应用程序处理失败的请求，并在适用的情况下重试。驱动程序不会自动重试失败的请求。
- 对数据库请求重试使用指数退避逻辑。
- 如果需要限制数据库操作的执行时间。使用 cursor.maxTimeMS()读取和 wtimeout 写入。
操作检查列表
- 文件系統
- 复制
- 分片
- 日志：WiredTiger存储引擎
- 硬件
- 部署到云硬件
- 操作系统配置
- 备份
- 监控
- 负载均衡
以下清单和开发清单列表一同提供了一些建议，帮助您避免生产环境下MongoDB部署中的问题。
文件系统
- 将磁盘分区与RAID配置对齐。
- 避免对dbPath使用NFS驱动器。使用NFS驱动器可能导致性能下降和不稳定。
有关详细信息，请参阅：远程文件系统 。
- VMware 用户应该通过 NFS 使用 VMware 虚拟驱动器。
- Linux/Unix：将驱动器格式化为 XFS 或 EXT4。如果可能的话，使用 XFS，因为它通常在MongoDB 中运行得更好。
- 对于 WiredTiger 存储引擎，强烈建议使用XFS，以避免在将 EXT4 与 WiredTiger 一起使用时产生性能问题。
- 如果使用 RAID，可能需要使用 RAID 几何阵列配置 XFS。
- Windows：使用 NTFS 文件系统。不要使用任何 FAT 文件系统（例如 FAT 16/32/exFAT）。
复制
- 验证所有非隐藏副本集成员在 RAM，CPU，磁盘，网络设置等方面的配置是否相同。
- 配置 oplog 的大小适合您的使用案例：
- 复制 oplog 窗口包括正常维护和停机时间窗口，以避免需要完全重新同步。
- 复制 oplog 窗口应涵盖从上次备份还原副本集成员所需的时间。
在 3.4 版本中更改：复制oplog窗口不再需要覆盖通过初始同步还原副本集成员所需的时间，因为在数据复制期间会提取oplog记录。但是，正在还原的成员必须在本地数据库中具有足够的磁盘空间，以便在此数据复制阶段的持续时间内临时存储这些oplog记录。
- 对于早期版本的 MongoDB，复制oplog窗口应涵盖通过初始同步还原副本集成员所需的时间。
- 确保您的副本集至少包含三个数据承载节点，这些节点与日志记录一起运行，并且为了可用性和持久性，您使用 w:"majority" 写策略发出写操作。
- 配置副本集成员时使用主机名，而不是IP地址。
- 确保所有mongod实例之间的完全双向网络连接。
- 确保每个主机都可以自行解决。
- 确保副本集包含奇数个投票成员。
- 确保mongod实例有0票或1票。
- 对高可用性，将副本集部署到至少三个数据中心。
分片
- 将配置服务器放在专用硬件上，以便在大型集群中获得最佳性能。确保硬件有足够的 RAM 将数据文件完全保存在内存中，并且有专用的存储器。
- 根据生产配置指南部署mongos前端路由。
- 使用NTP来同步切分集群所有组件上的时钟。
- 确保mongod, mongos和配置服务器之间的完全双向网络连接。
- 使用CNAMEs将配置服务器标识到集群，以便可以在不停机的情况下重命名和重新编号配置服务器。
日志：WiredTiger存储引擎
- 确保所有实例都使用日志。
- 将日志放在其自己的低延迟磁盘上，以适应写密集型的工作负载。请注意，这将影响快照样式备份，因为构成数据库状态的文件将位于单独的卷上。
硬件
- 使用 RAID10 和 SSD 驱动器可获得最佳性能。
- SAN 和虚拟化：
- 确保每个mongod 已为其 数据库文件存储路径配置了 IOPS，或者具有自己的物理驱动器或 LUN。
- 在虚拟环境中运行时，请避免使用动态内存特性，如内存膨胀。
- 避免将所有副本集成员放在同一个 SAN 上，因为 SAN 可能是单点故障。
部署到云硬件
- Windows Azure：将 TCP 长连接（TCP长连接时间）调整为100-120。Azure负载均衡器上的TCP空闲超时对于MongoDB的连接池行为太慢。有关详细信息，请参阅Azure产品说明。
- 在具有高延迟存储的系统（如Microsoft Azure）上使用MongoDB版本2.6.4或更高版本，因为这些版本包括这些系统性能的改进。
操作系统配置
Linux
- 关闭透明大页。有关更多信息，请参见透明大页设置。
- 在存储数据库文件的设备上调整文件预读设置 。
- 对于WiredTiger存储引擎，无论存储介质类型（旋转磁盘、固态硬盘等）如何，请将文件预读设置在8到32之间，除非测试显示在较高的文件预读值中有可测量、可重复和可靠的好处。
- MongoDB专业支持可以提供关于交替文件预读配置的建议和指导。
- 如果在RHEL/CentOS上使用tuned（动态内核调优工具），则必须自定义您的tuned配置文件。RHEL/CentOS附带的许多tuned文件可能会对其默认设置的性能产生负面影响。将您选择的tuned文件自定义为：
- 禁用透明大页。有关说明，请参见使用 tuned 和 ktune。
- 无论存储介质类型如何，都将文件预读设置为8到32之间。有关详细信息，请参阅预读设置。
- 对SSD驱动器使用noop或deadline磁盘调度程序。
- 对来宾虚拟机中的虚拟化驱动器使用noop磁盘调度程序。
- 禁用NUMA或将vm.zone_reclaim_mode设置为0并运行具有节点交错的mongod实例。请参阅：MongoDB和NUMA硬件了解更多信息。
- 调整硬件上的ulimit值以适合您的用例。如果多个mongod或者mongos实例在同一用户下运行，请相应地缩放ulimit值。有关详细信息，请参见：UNIX ulimit设置。
- 使用noatime作为dbPath挂载点。
- 为部署配置足够的文件句柄（fs.file max）、内核 pid 限制（kernel.pid_max）、每个进程的最大线程数（kernel.threads max）和每个进程的最大内存映射区域数（vm.max_map_count）。对于大型系统，以下值提供了一个良好的起点：
- fs.file-max 值为98000,
- kernel.pid_max 值为64000,
- threads-max 值为64000, 和
- vm.max_map_count 值为128000
- 确保系统已配置交换空间。有关适当大小的详细信息，请参阅操作系统的文档。
- 确保系统默认的TCP长连接设置正确。TCP长连接时间值300通常为副本集和分片集群提供更好的性能。有关详细信息，请参阅常见问题中的TCP保持时间是否影响MongoDB部署。
Windows
- 考虑禁用 NTFS “最后访问时间”更新。这类似于在 Unix-like 系统上禁用atime。
- 使用默认分配单元大小的4096 字节格式化NTFS磁盘。
备份
- 安排定期测试备份和恢复过程，以便手头有时间估计，并验证其功能。
监控
- 使用MongoDB Cloud Manager或者MongoDB 企业高级版中提供的本地解决方案-Ops Manager, 或者另一个监控系统来监控关键数据库指标并为它们设置警报。包括以下指标的警报:
- 复制滞后
- 复制 oplog 窗口
- 断言
- 队列
- 页面错误
- 监视服务器的硬件统计信息。尤其要注意磁盘使用、CPU 和可用磁盘空间。
在没有磁盘空间监视的情况下，以下方案作为预防措施：
- 在storage.dbPath驱动器上创建一个4 GB的虚拟文件，以确保磁盘满时有可用空间。
- 如果没有其他监视工具可用，cron df 的组合可以在磁盘空间达到高水位时发出警报。
负载均衡
- 将负载平衡器配置为启用“粘滞会话”或“客户端亲和性”，并为现有连接提供足够的延时。
- 避免在 MongoDB 集群或副本集组件之间放置负载平衡器。
译者：孔令升 MongoDB中文社区翻译小组成员
