Operations Checklist操作检查表

On this page本页内容

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. 避免将NFS驱动器用于dbPathUsing NFS drives can result in degraded and unstable performance. 使用NFS驱动器可能导致性能下降和不稳定。See: Remote Filesystems (NFS) for more information.有关详细信息,请参阅:远程文件系统(NFS)

    • VMware users should use VMware virtual drives over NFS.VMware用户应通过NFS使用VMware虚拟驱动器。
  • Linux/Unix: format your drives into XFS or EXT4. Linux/Unix:将驱动器格式化为XFS或EXT4。If possible, use XFS as it generally performs better with MongoDB.如果可能,使用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与WiredTier一起使用时出现性能问题。
    • If using RAID, you may need to configure XFS with your RAID geometry.如果使用RAID,您可能需要使用RAID几何结构配置XFS。
  • Windows: use the NTFS file system. 使用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.复制操作日志窗口应涵盖正常维护和停机时间窗口,以避免需要完全重新同步。
    • The replication oplog window should cover the time needed to restore a replica set member from the last backup.“复制操作日志”窗口应涵盖从上次备份恢复副本集成员所需的时间。

      Changed in version 3.4.在版本3.4中更改

      The replication oplog window no longer needs to cover the time needed to restore a replica set member via initial sync as the oplog records are pulled during the data copy. 复制操作日志窗口不再需要覆盖通过初始同步恢复副本集成员所需的时间,因为在数据复制期间会提取操作日志记录。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.但是,要还原的成员在local数据库中必须有足够的磁盘空间,以便在此数据复制阶段期间临时存储这些oplog记录。

      With earlier versions of MongoDB, replication oplog window should cover the time needed to restore a replica set member by initial sync.对于早期版本的MongoDB,复制操作日志窗口应涵盖通过初始同步恢复副本集成员所需的时间。

  • Ensure that your replica set includes at least three data-bearing nodes 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实例有01票。
  • 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.
  • Deploy mongos routers in accordance with the Production Configuration guidelines.
  • 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.
  • Use CNAMEs to identify your config servers to the cluster so that you can rename and renumber your config servers without downtime.使用CNAMEs将配置服务器标识到集群,以便您可以在不停机的情况下重命名和重新编号配置服务器。

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:

    • Ensure that each mongod has provisioned IOPS for its dbPath, or has its own physical drive or 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. Windows Azure:将TCP保持活动(tcp_keepalive_time)调整为100-120。The TCP idle timeout on the Azure load balancer is too slow for MongoDB's connection pooling behavior. 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

  • Turn off transparent hugepages. 关闭透明hugepages。See Transparent Huge Pages Settings for more information.有关详细信息,请参阅透明大页面设置
  • 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 supportMongoDB商业支持 can provide advice and guidance on alternate readahead configurations.可以提供关于备用预读配置的建议和指导。

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

    • Disable transparent hugepages. 禁用透明hugepages。See Using tuned and ktune for instructions.有关说明,请参阅使用调谐和ktune
    • Set readahead between 8 and 32 regardless of storage media type. 将readahead设置在8和32之间,而不考虑存储介质类型。See Readahead settings for more information.有关详细信息,请参阅预读设置
  • Use the noop or deadline disk schedulers for SSD drives.对于SSD驱动器,请使用noopdeadline磁盘调度器。
  • Use the noop disk scheduler for virtualized drives in guest VMs.对于来宾虚拟机中的虚拟化驱动器,请使用noop磁盘调度程序。
  • Disable NUMA or set vm.zone_reclaim_mode to 0 and run mongod instances with node interleaving. See: MongoDB and NUMA Hardware for more information.
  • Adjust the ulimit values on your hardware to suit your use case. If multiple mongod or mongos instances are running under the same user, scale the ulimit values accordingly. See: UNIX ulimit Settings for more information.
  • 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 value of 98000,
    • kernel.pid_max value of 64000,
    • kernel.threads-max value of 64000, and
    • vm.max_map_count value of 128000
  • Ensure that your system has swap space configured. 确保您的系统已配置交换空间。Refer to your operating system's documentation for details on appropriate sizing.有关适当大小的详细信息,请参阅操作系统的文档。
  • Ensure that the system default TCP keepalive is set correctly. 确保正确设置了系统默认TCP keepalive。A value of 300 often provides better performance for replica sets and sharded clusters. 值300通常为副本集和分片群集提供更好的性能。See: Does TCP keepalive time affect MongoDB Deployments? in the Frequently Asked Questions for more information.

Windows

  • Consider disabling NTFS "last access time" updates. 考虑禁用NTFS“上次访问时间”更新。This is analogous to disabling atime on Unix-like systems.这类似于在类Unix系统上禁用atime
  • Format NTFS disks using the default Allocation unit size of 4096 bytes.

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. Include alerts for the following metrics:包括以下指标的警报:

    • replication lag
    • replication oplog window
    • 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集群或副本集组件之间放置负载平衡器。
←  Production NotesDevelopment Checklist →