Docs 菜单
Docs 主页
/
MongoDB Manual
/
自管理部署
/
管理

自管理部署的操作清单

在此页面上

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

以下检查清单和 开发检查清单 列表提供了部分建议，它们有助于避免在生产 MongoDB 部署中出现问题。

文件系统

复制

  • 请验证所有非隐藏副本集节点在 RAM、CPU、磁盘、网络设置等方面是否配置相同。

  • 根据使用案例配置 oplog 大小：

    • 复制 oplog window 应包括正常维护和停机的时间窗口，以避免需要进行全量重新同步。

    • 复制 oplog window 应包括从上次备份中恢复副本集节点所需的时间。

      注意

      复制 oplog window 无需覆盖通过初始同步恢复副本集节点所需的时间，因为在数据复制期间会拉取 oplog 记录。不过，被恢复的节点必须在本地数据库中有足够的磁盘空间，以便在数据复制阶段临时存储这些 oplog 记录。

  • 确保副本集至少包含三个承载数据的有投票权成员，而这些成员可与日志功能一起运行并发出带 w: majority 写关注的写入操作，从而实现可用性和持久性。

  • 在配置副本集节点时使用主机名，而不是 IP 地址。

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

  • 确保每台主机都能自行解析。

  • 确保副本集包含奇数个投票节点。

  • 确保 mongod 实例有 0 或 1 投票。

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

分片

  • 将配置服务器放在专用硬件上，从而在大型集群中获得最佳性能。确保硬件有足够的 RAM 将数据文件完全保存在内存中，并且硬件具有专用存储。

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

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

  • 确保 mongod、mongos 和配置服务器之间存在完全双向网络连接。

  • 使用 CNAME 向集群标识您的配置服务器，以便在不停机的情况下对您的配置服务器进行重命名和重新编号。

日志：WiredTiger 存储引擎

  • 确保所有实例均使用日志。

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

硬件

  • 使用 RAID10 和固态硬盘驱动器，获得最佳性能。

  • 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 或更高版本，因为这些版本包括针对这些系统的性能改进。

操作系统配置

Linux

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

  • 如果运行 MongoDB 7.0 或更早版本，请禁用透明大页。

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

    • 对于 WiredTiger 存储引擎，无论存储介质类型如何（旋转磁盘、固态硬盘等），都将预读值设置在 8 到 32 之间，除非有测试表明使用较高的预读值具有可测量、可重复且可靠的增益。

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

  • 如果在 RHEL/CentOS 上使用 tuned ，则必须自定义您的 tuned 配置文件。RHEL/CentOS 附带的许多 tuned 配置文件的默认设置都可能对性能造成影响。将您选择的 tuned配置文件自定义为：

  • 为 SSD 使用 cfq 或 deadline 磁盘调度器。

  • 将 CFQ 磁盘调度器用于客户机虚拟机中的虚拟化驱动器。

  • 禁用 NUMA 或将 vm.zone_reclaim_mode 设为 0，然后使用节点交错功能来运行 mongod 实例。请参阅 MongoDB 和 NUMA 硬件以了解更多信息。

  • 调整针对硬件的 ulimit 值以适应您的应用场景。如果同一用户下运行有多个 mongod 或 mongos 实例，则应相应缩放 ulimit 值。请参阅：UNIX ulimit 自管理部署设置以了解更多信息。

  • 使用 noatime 作为 dbPath 挂载点。

  • 为您的部署配置充足的文件句柄数 (fs.file-max)、内核进程 ID (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 部署？了解更多信息。

Windows

  • 考虑禁用 NTFS“上次访问时间”更新。这与在类似 Unix 的系统上禁用 atime 相似。

  • 使用默认 Allocation unit size 的 4096 字节格式化 NTFS 磁盘。

备份

  • 定期安排对备份和恢复流程的测试，以便估算时间并验证其功能。

监控

  • 使用 MongoDB Cloud Manager 或 Ops Manager（MongoDB Enterprise Advanced 中的本地解决方案）或其他监控系统来监控关键数据库指标并为其设置警报。包括以下指标的警报：

    • 复制延迟

    • 复制 oplog 窗口

    • 断言

    • 队列

    • 页面错误

  • 监控服务器的硬件统计信息。应重点关注磁盘使用量、CPU 和可用磁盘空间。

    在无磁盘空间监控时或者作为预防措施：

    • 在 storage.dbPath 驱动上创建一份 4 GB 的伪拟文件，以确保磁盘已满时有可用空间。

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

负载均衡

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

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

安全性

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

后退

生产说明

来年

性能