Database Manual / Self-Managed Deployments / Administration

Operations Checklist for Self-Managed Deployments自我管理部署的操作检查表

The following checklist, along with the Development Checklist list, provides recommendations to help you avoid issues in your production MongoDB deployment.以下清单以及开发清单提供了建议，以帮助您避免生产MongoDB部署中的问题。

Filesystem文件系统

  • Align your disk partitions with your RAID configuration.将磁盘分区与RAID配置对齐。

  • Avoid using NFS drives for your dbPath. Using NFS drives can result in degraded and unstable performance. See: Remote Filesystems (NFS) for more information.避免将NFS驱动器用于dbPath。使用NFS驱动器可能会导致性能下降和不稳定。有关更多信息，请参阅：远程文件系统（NFS）。

    • VMware users should use VMware virtual drives over NFS.VMware用户应通过NFS使用VMware虚拟驱动器。

  • Linux/Unix: format your drives into XFS or EXT4. If possible, use XFS as it generally performs better with MongoDB.Linux/Unix：将驱动器格式化为XFS或EXT4。如果可能的话，使用XFS，因为它通常在MongoDB中表现更好。

    • With the WiredTiger storage engine, use of XFS is strongly recommended to avoid performance issues found when using EXT4 with WiredTiger.对于WiredTiger存储引擎，强烈建议使用XFS，以避免在将EXT4与WiredTiger一起使用时出现性能问题。
    • If using RAID, you may need to configure XFS with your RAID geometry.如果使用RAID，您可能需要使用RAID几何结构配置XFS。

  • Windows: use the NTFS file system.Windows：使用NTFS文件系统。 Do not use any FAT file system (i.e. FAT 16/32/exFAT).不要使用任何FAT文件系统（即FAT 16/32/exFAT）。

Replication复制

  • Verify that all non-hidden replica set members are identically provisioned in terms of their RAM, CPU, disk, network setup, etc.验证所有非隐藏副本集成员在RAM、CPU、磁盘、网络设置等方面的配置是否相同。

  • Configure the oplog size配置oplog大小 to suit your use case:为了适应用例：

    • The replication oplog window should cover normal maintenance and downtime windows to avoid the need for a full resync.复制oplog窗口应涵盖正常维护和停机窗口，以避免需要完全重新同步。

    • The replication oplog window should cover the time needed to restore a replica set member from the last backup.复制oplog窗口应涵盖从上次备份还原副本集成员所需的时间。

      Note

      The replication oplog window doesn't need to cover the time needed to restore a replica set member via initial sync as the oplog records are pulled during the data copy. 复制oplog窗口不需要覆盖通过初始同步恢复副本集成员所需的时间，因为oplog记录是在数据复制过程中提取的。However, the member being restored must have enough disk space in the local database to temporarily store these oplog records for the duration of this data copy stage.但是，要还原的成员必须在本地数据库中有足够的磁盘空间，以便在此数据复制阶段期间临时存储这些oplog记录。

  • Ensure that your replica set includes at least three data-bearing voting members that run with journaling and that you issue writes with w: majority write concern for availability and durability.确保副本集至少包含三个带有数据的投票成员，这些成员通过日志运行，并且您在发出写入时考虑了w: majority写入关注的可用性和持久性。
  • Use hostnames when configuring replica set members, rather than IP addresses.配置副本集成员时使用主机名，而不是IP地址。
  • Ensure full bidirectional network connectivity between all mongod instances.确保所有mongod实例之间的完全双向网络连接。
  • Ensure that each host can resolve itself.确保每个主机都可以自行解析。
  • Ensure that your replica set contains an odd number of voting members.确保副本集包含奇数个投票成员。
  • Ensure that mongod instances have 0 or 1 votes.确保mongod实例有0或1个投票。
  • For high availability, deploy your replica set into a minimum of three data centers.为了实现高可用性，请将副本集部署到至少三个数据中心。

Sharding分片

  • Place your config servers on dedicated hardware for optimal performance in large clusters. 将配置服务器放置在专用硬件上，以在大型集群中获得最佳性能。Ensure that the hardware has enough RAM to hold the data files entirely in memory and that it has dedicated storage.确保硬件有足够的RAM将数据文件完全保存在内存中，并且具有专用存储。
  • Deploy mongos routers in accordance with the Production Configuration guidelines.根据生产配置指南部署mongos路由器。
  • Use NTP to synchronize the clocks on all components of your sharded cluster.使用NTP同步分片集群所有组件上的时钟。
  • Ensure full bidirectional network connectivity between mongod, mongos, and config servers.确保mongod、mongos和配置服务器之间的完全双向网络连接。
  • Use CNAMEs to identify your config servers to the cluster so that you can rename and renumber your config servers without downtime.使用CNAME在集群中标识配置服务器，以便您可以在不停机的情况下重命名和重新编号配置服务器。

Journaling: WiredTiger Storage Engine日志：WiredTiger存储引擎

  • Ensure that all instances use journaling.确保所有实例都使用日志记录。
  • Place the journal on its own low-latency disk for write-intensive workloads. Note that this will affect snapshot-style backups as the files constituting the state of the database will reside on separate volumes.将日志放在自己的低延迟磁盘上，以用于写密集型工作负载。请注意，这将影响快照式备份，因为构成数据库状态的文件将驻留在单独的卷上。

Hardware硬件

  • Use RAID10 and SSD drives for optimal performance.使用RAID10和SSD驱动器以获得最佳性能。

  • SAN and Virtualization:SAN和虚拟化：

    • Ensure that each mongod has provisioned IOPS for its dbPath, or has its own physical drive or LUN.确保每个mongod都为其dbPath配置了IOPS，或者拥有自己的物理驱动器或LUN。
    • Avoid dynamic memory features, such as memory ballooning, when running in virtual environments.在虚拟环境中运行时，避免动态内存功能，如内存膨胀。
    • Avoid placing all replica set members on the same SAN, as the SAN can be a single point of failure.避免将所有副本集成员放在同一个SAN上，因为SAN可能是单点故障。

Deployments to Cloud Hardware部署到云硬件

  • Windows Azure: Adjust the TCP keepalive (tcp_keepalive_time) to 100-120. The TCP idle timeout on the Azure load balancer is too slow for MongoDB's connection pooling behavior. Windows Azure：将TCP保活（tcp_keepalive_time）调整为100-120。Azure负载平衡器上的TCP空闲超时对于MongoDB的连接池行为来说太慢了。See: Azure Production Notes for more information.有关更多信息，请参阅：Azure生产说明。
  • Use MongoDB version 2.6.4 or later on systems with high-latency storage, such as Windows Azure, as these versions include performance improvements for those systems.在具有高延迟存储的系统（如Windows Azure）上使用MongoDB 2.6.4或更高版本，因为这些版本包括对这些系统的性能改进。

Operating System Configuration操作系统配置

Linux

  • If running MongoDB 8.0 or later, turn on Transparent Hugepages.如果运行MongoDB 8.0或更高版本，请启用透明护圈。
  • If running MongoDB 7.0 or earlier, turn off Transparent Hugepages.如果运行MongoDB 7.0或更早版本，请关闭透明护圈。

  • Adjust the readahead settings on the devices storing your database files.在存储数据库文件的设备上调整预读设置。

    • For the WiredTiger storage engine, set readahead between 8 and 32 regardless of storage media type (spinning disk, SSD, etc.), unless testing shows a measurable, repeatable, and reliable benefit in a higher readahead value.对于WiredTiger存储引擎，无论存储介质类型如何（旋转磁盘、SSD等），都应将预读设置在8到32之间，除非测试显示在更高的预读值下具有可测量、可重复和可靠的优势。

      MongoDB commercial support商业支持 can provide advice and guidance on alternate readahead configurations.可以就替代预读配置提供建议和指导。

  • If using tuned on RHEL / CentOS, you must customize your tuned profile. Many of the tuned profiles that ship with RHEL / CentOS can negatively impact performance with their default settings. Customize your chosen tuned profile to:如果在RHEL/CentOS上使用已调优的配置文件，则必须自定义已调优的概要文件。RHEL/CentOS附带的许多调优配置文件都会对其默认设置的性能产生负面影响。将您选择的调谐配置文件自定义为：

  • Use the none disk schedulers for NVMe or SSD drives.使用NVMe或SSD驱动器的无磁盘调度程序。

  • Use the none disk scheduler for virtualized drives in guest VMs. If there are no neighbors, or if the neighbors do not produce heavy I/O patterns, there will be little HBA contention and the default none scheduler suffices.对来宾VM中的虚拟化驱动器使用无磁盘调度程序。如果没有邻居，或者邻居不产生繁重的I/O模式，则HBA争用很少，默认的无调度器就足够了。

    Use kyber to run multiple workloads in the same VM or in your own data center. 使用kyber在同一虚拟机或您自己的数据中心运行多个工作负载。kyber improves the I/O interpolation under contention, and reduces the impact of noisy neighbors. kyber改进了竞争下的I/O插值，并减少了噪声邻居的影响。Additionally, kyber works efficiently in self hosted situations, such as on-premises virtualization and collocated workloads in one large cloud VM. 此外，kyber在自托管的情况下工作效率很高，例如本地虚拟化和一个大型云VM中的并置工作负载。However, kyber is only available on linux kernels starting in version 4.12.然而，kyber仅在4.12版本开始的linux内核上可用。

  • Disable NUMA or set vm.zone_reclaim_mode to 0 and run mongod instances with node interleaving. 禁用NUMA或将vm.zone_reclaim_mode设置为0，并使用节点交错运行mongod实例。See: MongoDB and NUMA Hardware for more information.有关更多信息，请参阅：MongoDB和NUMA硬件。
  • Adjust the ulimit values on your hardware to suit your use case. 调整硬件上的ulimit值以适应用例。If multiple mongod or mongos instances are running under the same user, scale the ulimit values accordingly. See: UNIX ulimit Settings for Self-Managed Deployments for more information.如果多个mongod或mongos实例在同一用户下运行，请相应地缩放ulimit值。有关更多信息，请参阅：用于自我管理部署的UNIX ulimit设置。
  • Use noatime for the dbPath mount point.

  • Configure sufficient file handles (fs.file-max), kernel pid limit (kernel.pid_max), maximum threads per process (kernel.threads-max), and maximum number of memory map areas per process (vm.max_map_count) for your deployment. For large systems, the following values provide a good starting point:为部署配置足够的文件句柄（fs.file-max）、内核pid限制（kernel.pid_max）、每个进程的最大线程数（kernel.threads-max）和每个进程的内存映射区域的最大数量（vm.max_map_count）。对于大型系统，以下值提供了一个很好的起点：

    • fs.file-max value of 98000,值为98000，
    • kernel.pid_max value of 64000,值为64000，
    • kernel.threads-max value of 64000, and值为64000，以及
    • vm.max_map_count value of 131060值为131060

  • To manage swap space, perform one of the following:要管理交换空间，请执行以下操作之一：

    • Ensure that your system has swap space configured. Refer to your operating system's documentation for details on appropriate sizing.确保系统已配置交换空间。有关适当大小的详细信息，请参阅操作系统的文档。
    • Do not assign swap space on your system, and configure the kernel to disable swapping entirely.不要在系统上分配交换空间，并将内核配置为完全禁用交换。
  • Ensure that the system default TCP keepalive is set correctly. A value of 120 often provides better performance for replica sets and sharded clusters. 确保系统默认TCP keepalive设置正确。值120通常为副本集和分片集群提供更好的性能。See: Does TCP keepalive time affect MongoDB Deployments? in the Frequently Asked Questions for more information.请参阅：TCPkeepalive时间会影响MongoDB部署吗？在常见问题中了解更多信息。

Windows

  • Consider disabling NTFS "last access time" updates. This is analogous to disabling atime on Unix-like systems.考虑禁用NTFS“上次访问时间”更新。这类似于在类Unix系统上禁用atime。
  • Format NTFS disks using the default Allocation unit size of 4096 bytes.使用4096字节的默认分配单元大小格式化NTFS磁盘。

Backups备份

  • Schedule periodic tests of your back up and restore process to have time estimates on hand, and to verify its functionality.安排备份和恢复过程的定期测试，以便有时间估计，并验证其功能。

Monitoring监控

  • Use MongoDB Cloud Manager or Ops Manager, an on-premise solution available in MongoDB Enterprise Advanced or another monitoring system to monitor key database metrics and set up alerts for them. 使用MongoDB Cloud Manager或Ops Manager（MongoDB Enterprise Advanced或其他监控系统中提供的内部解决方案）来监控关键数据库指标并为其设置警报。Include alerts for the following metrics:包括以下指标的警报：

    • replication lag复制延迟
    • replication oplog window复制oplog窗口
    • assertions断言
    • queues队列
    • page faults页错误

  • Monitor hardware statistics for your servers. In particular, pay attention to the disk use, CPU, and available disk space.监控服务器的硬件统计数据。特别要注意磁盘使用情况、CPU和可用磁盘空间。

    In the absence of disk space monitoring, or as a precaution:在没有磁盘空间监控的情况下，或作为预防措施：

    • Create a dummy 4 GB file on the storage.dbPath drive to ensure available space if the disk becomes full.在storage.dbPath驱动器上创建一个4 GB的虚拟文件，以确保磁盘已满时有可用空间。
    • A combination of cron+df can alert when disk space hits a high-water mark, if no other monitoring tool is available.如果没有其他监控工具可用，cron+df的组合可以在磁盘空间达到高水位线时发出警报。

Load Balancing负载均衡

  • Configure load balancers to enable "sticky sessions" or "client affinity", with a sufficient timeout for existing connections.配置负载平衡器以启用“粘性会话”或“客户端相关性”，并为现有连接提供足够的超时时间。
  • Avoid placing load balancers between MongoDB cluster or replica set components.避免在MongoDB集群或副本集组件之间放置负载平衡器。

Security安全

For a list of security measures to protect your MongoDB installation, see the MongoDB Security Checklist.有关保护MongoDB安装的安全措施列表，请参阅MongoDB安全检查表。