文档菜单
文档首页
/
MongoDB 手册
/ /

自管理部署操作清单

本页内容

  • 文件系统
  • 复制
  • 分片
  • 日志记录:WiredTiger 存储引擎
  • 硬件
  • 云硬件部署
  • 操作系统配置
  • 备份
  • 监控
  • 负载均衡
  • 安全

以下清单以及开发清单 提供了帮助您避免生产 MongoDB 部署中问题的建议。

  • 验证所有非隐藏副本集成员在内存、CPU、磁盘、网络设置等方面是否相同。

  • 配置oplog大小以适应您的用例。

    • 复制操作日志窗口应涵盖正常维护和停机窗口,以避免需要完全重新同步。

    • 复制操作日志窗口应涵盖从最后备份恢复副本集成员所需的时间。

      注意

      复制操作日志窗口不需要涵盖通过初始同步恢复副本集成员所需的时间,因为操作日志记录在数据复制期间被拉取。然而,正在恢复的成员必须在本地数据库中有足够的磁盘空间,以在数据复制阶段暂时存储这些操作日志记录。

  • 确保您的副本集至少包含三个运行着日志记录功能的数据承载投票成员,并且您使用带有w: majority 写入关注的写入来保证可用性和持久性。

  • 在配置副本集成员时使用主机名,而不是IP地址。

  • 确保所有mongod实例之间具有完全的双向网络连接。

  • 确保每个主机可以解析自己。

  • 确保您的副本集包含奇数个投票成员。

  • 确保mongod实例具有01票。

  • 为了高可用性,将副本集部署到至少三个数据中心。

  • 将配置服务器放置在专用硬件上,以在大集群中实现最佳性能。确保该硬件有足够的RAM来完全在内存中保留数据文件,并且有专用存储。

  • 根据生产配置指南部署mongos路由器。

  • 使用NTP同步您的分片集群所有组件的时钟。

  • 确保mongodmongos和配置服务器之间具有完全的双向网络连接。

  • 使用CNAME来识别集群中的配置服务器,这样您可以在不停机的情况下重命名和重新编号配置服务器。

  • 确保所有实例都使用日志记录。

  • 将日志放置在自己的低延迟磁盘上,以便于写入密集型工作负载。请注意,这会影响快照类型的备份,因为构成数据库状态的文件将位于不同的卷上。

  • 使用RAID10和SSD驱动器以获得最佳性能。

  • SAN和虚拟化

    • 确保每个mongod都为其dbPath分配了IOPS,或者有自己的物理驱动器或LUN。

    • 在虚拟环境中运行时,避免使用动态内存功能,例如内存膨胀。

    • 避免将所有副本集成员放置在同一SAN上,因为SAN可能成为单点故障。

  • Windows Azure:调整TCP keepalive(tcp_keepalive_time)为100-120。Azure负载均衡器上的TCP空闲超时对于MongoDB的连接池行为来说太慢了。有关更多信息,请参阅:Azure 生产注意事项

  • 在具有高延迟存储的系统(如Windows Azure)上使用MongoDB版本2.6.4或更高版本,因为这些版本包括针对这些系统的性能改进。

  • 如果运行MongoDB 8.0或更高版本,请开启透明大页。

  • 如果运行MongoDB 7.0或更早版本,请关闭透明大页。

  • 调整存储数据库文件的设备上的预读设置

    • 对于WiredTiger存储引擎,无论存储介质类型(旋转磁盘、SSD等),都设置预读值在8到32之间,除非测试显示更高预读值具有可测量的、可重复的且可靠的收益。

      MongoDB商业支持可以提供有关备用预读配置的建议和指导。

  • 如果您在RHEL / CentOS上使用tuned,您必须自定义您的tuned配置文件。许多随RHEL / CentOS提供的tuned配置文件可能会因为默认设置而负面影响性能。根据您的需要自定义选择的tuned配置文件来

  • 使用 SSD 的 cfqdeadline 磁盘调度器。

  • 使用 cfq 磁盘调度器来管理虚拟机中的虚拟驱动器。

  • 禁用 NUMA 或将 vm.zone_reclaim_mode 设置为 0,并使用节点交错运行 mongod 实例。更多信息请参考:MongoDB 和 NUMA 硬件

  • 根据您的使用情况调整硬件上的 ulimit 值。如果多个 mongodmongos 实例在同一个用户下运行,相应地扩展 ulimit 值。更多信息请参考:自管理部署的 UNIX ulimit 设置

  • dbPath 挂载点使用 noatime

  • 为您的部署配置足够的文件句柄(fs.file-max)、内核 PID 限制(kernel.pid_max)、每个进程的最大线程数(kernel.threads-max)以及每个进程的最大内存映射区域数(vm.max_map_count)。对于大型系统,以下值是一个良好的起点:

    • fs.file-max 的值为 98000,

    • kernel.pid_max 的值为 64000,

    • kernel.threads-max 的值为 64000,

    • 以及 vm.max_map_count 的值为 131060。

  • 确保您的系统已配置交换空间。有关适当大小的详细信息,请参考操作系统的文档。

  • 确保系统默认的 TCP keepalive 设置正确。对于副本集和分片集群,120 通常提供更好的性能。更多信息请参考:TCP keepalive 时间会影响 MongoDB 部署吗? 在常见问题解答中。

  • 考虑禁用 NTFS 的 "最后访问时间" 更新。这类似于在类 Unix 系统上禁用 atime

  • 使用默认的分配单元大小 4096 字节来格式化 NTFS 磁盘。

  • 定期测试您的备份和恢复流程,以便随时掌握时间估计,并验证其功能。

  • 使用MongoDB Cloud ManagerOps Manager,MongoDB Enterprise Advanced中可用的本地解决方案或另一个监控系统来监控关键数据库指标,并为它们设置警报。包括以下指标的警报

    • 复制延迟

    • 复制操作日志窗口

    • 断言

    • 队列

    • 页面错误

  • 监控服务器硬件统计信息。特别是,请注意磁盘使用情况、CPU和可用磁盘空间。

    如果没有磁盘空间监控,或者作为预防措施

    • storage.dbPath驱动器上创建一个4 GB的虚拟文件,以确保磁盘满时可用空间。

    • 如果没有其他监控工具,可以使用cron+df的组合在磁盘空间达到高水位时发出警报。

  • 配置负载均衡器以启用“粘性会话”或“客户端亲和力”,并为现有连接设置足够的超时时间。

  • 避免在MongoDB集群或副本集组件之间放置负载均衡器。

有关保护MongoDB安装的安全措施列表,请参阅MongoDB安全清单。

返回

生产注意事项