MongoDB Manual (Version 4.2)> Administration
MongoDB开发检查列表以及操作检查列表提供了一些建议,帮助我们在生产环境下,避免MongoDB部署出现中的问题。
开发检查列表
数据持久性
模式设计
MongoDB中的数据有一个动态设计。集合强制执行文档结构。这有助于迭代开发和多态性。然而,集合通常保存具有高度同质结构的文档。有关详细信息,请参阅数据建模概念。
复制
注意
对于以下MongoDB版本,对于具有仲裁器的副本集,与pv0(MongoDB 4.0+中不再支持)相比, pv1增加了 w:1 回滚的可能性:
参见副本集协议版本。
分片
驱动
操作检查列表
以下清单和开发清单列表一同提供了一些建议,帮助您避免生产环境下MongoDB部署中的问题。
文件系统
- 将磁盘分区与RAID配置对齐。
- 避免对dbPath使用NFS驱动器。使用NFS驱动器可能导致性能下降和不稳定。
有关详细信息,请参阅:远程文件系统 。
- Linux/Unix:将驱动器格式化为 XFS 或 EXT4。如果可能的话,使用 XFS,因为它通常在MongoDB 中运行得更好。
- Windows:使用 NTFS 文件系统。不要使用任何 FAT 文件系统(例如 FAT 16/32/exFAT)。
复制
- 验证所有非隐藏副本集成员在 RAM,CPU,磁盘,网络设置等方面的配置是否相同。
- 配置 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 和虚拟化:
部署到云硬件
- Windows Azure:将 TCP 长连接(TCP长连接时间)调整为100-120。Azure负载均衡器上的TCP空闲超时对于MongoDB的连接池行为太慢。有关详细信息,请参阅Azure产品说明。
- 在具有高延迟存储的系统(如Microsoft Azure)上使用MongoDB版本2.6.4或更高版本,因为这些版本包括这些系统性能的改进。
操作系统配置
Linux
- 关闭透明大页。有关更多信息,请参见透明大页设置。
- 在存储数据库文件的设备上调整文件预读设置 。
- MongoDB专业支持可以提供关于交替文件预读配置的建议和指导。
- 如果在RHEL/CentOS上使用tuned(动态内核调优工具),则必须自定义您的tuned配置文件。RHEL/CentOS附带的许多tuned文件可能会对其默认设置的性能产生负面影响。将您选择的tuned文件自定义为:
- 对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)。对于大型系统,以下值提供了一个良好的起点:
- 确保系统已配置交换空间。有关适当大小的详细信息,请参阅操作系统的文档。
- 确保系统默认的TCP长连接设置正确。TCP长连接时间值300通常为副本集和分片集群提供更好的性能。有关详细信息,请参阅常见问题中的TCP保持时间是否影响MongoDB部署。
Windows
- 考虑禁用 NTFS “最后访问时间”更新。这类似于在 Unix-like 系统上禁用atime。
- 使用默认分配单元大小的4096 字节格式化NTFS磁盘。
备份
- 安排定期测试备份和恢复过程,以便手头有时间估计,并验证其功能。
监控
- 使用MongoDB Cloud Manager或者MongoDB 企业高级版中提供的本地解决方案-Ops Manager, 或者另一个监控系统来监控关键数据库指标并为它们设置警报。包括以下指标的警报:
- 监视服务器的硬件统计信息。尤其要注意磁盘使用、CPU 和可用磁盘空间。
在没有磁盘空间监视的情况下,以下方案作为预防措施:
负载均衡
- 将负载平衡器配置为启用“粘滞会话”或“客户端亲和性”,并为现有连接提供足够的延时。
- 避免在 MongoDB 集群或副本集组件之间放置负载平衡器。
译者:孔令升 MongoDB中文社区翻译小组成员