Operations Checklist

在本页面

• Filesystem

• Replication

• Sharding

• 日记：MMAPv1 存储引擎

• Hardware

• 部署到云硬件

• os 配置

• Backups

• Monitoring

• Load Balancing

以下清单以及Development Checklist清单提供了一些建议，以帮助您避免生产 MongoDB 部署中出现问题。

Filesystem

• 将磁盘分区与 RAID 配置对齐。

• 避免为dbPath使用 NFS 驱动器。使用 NFS 驱动器会导致性能下降和不稳定。有关更多信息，请参见：Remote Filesystems。

• VMware 用户应通过 NFS 使用 VMware 虚拟驱动器。

• Linux/Unix：将驱动器格式化为 XFS 或 EXT4.如果可能的话，请使用 XFS，因为它通常在 MongoDB 中表现更好。

• 对于 WiredTiger 存储引擎，强烈建议使用 XFS，以避免将 EXT4 与 WiredTiger 一起使用时出现性能问题。

  • 如果使用 RAID，则可能需要使用 RAID 几何配置 XFS。

• Windows：使用 NTFS 文件系统。 请勿 使用任何 FAT 文件系统(即 FAT 16/32/exFAT)。

Replication

• 验证所有非隐藏副本集成员在其 RAM，CPU，磁盘，网络设置等方面是否均配置相同。

• 配置操作日志大小以适合您的用例：

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

  • 复制操作日志窗口应涵盖从上次备份还原副本集成员所需的时间。

在版本 3.4 中进行了更改：复制 oplog 窗口不再需要通过初始同步来恢复副本集成员所需的时间，因为在数据复制期间会提取 oplog 记录。但是，要恢复的成员必须在local数据库中具有足够的磁盘空间，才能在此数据复制阶段持续存储这些操作日志记录。

对于早期版本的 MongoDB，复制操作日志窗口应涵盖通过初始同步还原副本集成员所需的时间。

• 确保您的副本集至少包括三个运行日记功能的数据承载节点，并且为了可用性和持久性而使用w:"majority" write concern发出写入。

• 配置副本集成员时，请使用主机名，而不要使用 IP 地址。

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

• 确保每个主机都能自行解决。

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

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

• 对于high availability，将副本集部署到三个数据中心中(最少)。

Sharding

• 将config servers放在专用硬件上，以在大型群集中获得最佳性能。确保硬件具有足够的 RAM 以将数据文件完全保留在内存中，并且具有专用的存储。

• 根据Production Configuration准则部署mongosRouter。

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

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

• 使用 CNAME 可以识别群集中的配置服务器，以便您可以重命名和重新编号配置服务器而不会造成停机。

日记：MMAPv1 存储引擎

• 确保所有实例都使用journaling。

• 将日志放在其自己的低延迟磁盘上，以处理写密集型工作负载。请注意，这将影响快照式备份，因为构成数据库状态的文件将驻留在单独的卷上。

Hardware

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

• SAN 和虚拟化：

• 确保每个mongod为其dbPath设置了 IOPS，或者具有自己的物理驱动器或 LUN。

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

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

部署到云硬件

• Windows Azure：将 TCP keepalive(tcp_keepalive_time)调整为 100-120.对于 MongoDB 的连接池行为，Azure 负载平衡器上的 TCP 空闲超时太慢。有关更多信息，请参见：Azure 生产说明。

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

os 配置

Linux

• 关闭透明的大页面。有关更多信息，请参见透明的大页面设置。

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

• 对于 WiredTiger 存储引擎，无论存储介质类型(旋转磁盘，SSD 等)如何，都将预读设置在 8 到 32 之间，除非测试显示以更高的预读值显示出可测量，可重复且可靠的好处。

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

• 对于 MMAPv1 存储引擎，如果您的工作集大于可用的 RAM，并且文档访问模式是随机的，请考虑将预读降低到 32 或 16.评估不同的设置以找到一个最佳值，该值可以最大化驻留内存并降低存储空间。页面错误数。

• 如果在 RHEL/CentOS 上使用tuned，则必须自定义tuned配置文件。 RHEL/CentOS 附带的许多tuned配置文件可能会对默认设置产生负面影响。自定义您选择的tunedProfile 以：

• 禁用透明的大页面。有关说明，请参见使用调整和调整。

  • 不管存储媒体类型如何，将预读设置在 8 到 32 之间。有关更多信息，请参见Readahead settings。

• 将noop或deadline磁盘调度程序用于 SSD 驱动器。

• 将noop磁盘调度程序用于来宾 VM 中的虚拟驱动器。

• 禁用 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)和每个进程的最大内存 Map 区域数(vm.max_map_count)。对于大型系统，以下值是一个很好的起点：

• fs.file-max值 98000，

  • kernel.pid_max值 64000，

  • kernel.threads-max值 64000，以及

  • vm.max_map_count值 128000

• 确保系统已配置交换空间。有关适当的大小调整的详细信息，请参阅 os 的文档。

• 确保正确设置了系统默认的 TCP keepalive。值 300 通常可以为副本集和分片群集提供更好的性能。有关更多信息，请参阅：TCP 保持活动时间是否会影响 MongoDB 部署？。

Windows

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

• 使用默认分配单元大小4096 bytes格式化 NTFS 磁盘。

Backups

• 安排对备份和还原过程进行定期测试，以掌握时间，并验证其功能。

Monitoring

• 使用MongoDB 云 Management 器或Ops Manager，MongoDB Enterprise Advanced 中提供的本地解决方案或其他监视系统来监视关键数据库 Metrics 并为其设置警报。包括以下 Metrics 的警报：

• 锁定百分比(对于MMAPv1 存储引擎)

  • replication lag

  • 复制操作日志窗口

  • assertions

  • queues

  • page faults

• 监视服务器的硬件统计信息。特别要注意磁盘使用，CPU 和可用磁盘空间。

在没有磁盘空间监视的情况下，或作为预防措施：

• 如果磁盘已满，请在storage.dbPath驱动器上创建一个 4 GB 的虚拟文件，以确保有可用空间。

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

Load Balancing

• 配置负载平衡器以启用“粘性会话”或“Client 端相似性”，并为现有连接提供足够的超时。

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