MongoDB 安装部署需求（官方文档）

生产平台特定注意事项

https://docs.mongodb.com/manual/administration/production-notes/#prod-notes-ram

1、推荐平台

虽然MongoDB支持多种平台，但建议生产使用以下操作系统：
亚马逊Linux 2
Debian 9和10
RHEL/CentOS 6、7和8
SLES 12和15
Ubuntu LTS 16.04和18.04
Windows服务器2016和2019
另见
平台特定注意事项

 2、使用最新的稳定包

确保你有最新的稳定版本。
所有MongoDB版本都可以在MongoDB下载中心页面上找到。MongoDB下载中心页面是验证当前稳定版本的好地方，即使您是通过包管理器安装的。
对于其他MongoDB产品，请参阅MongoDB下载中心页面或其各自的文档。

 

3、并发性

WiredTiger
WiredTiger支持读写器对集合中文档的并发访问。客户端可以在进行写操作时读取文档，多个线程可以同时修改集合中的不同文档。
另见
分配足够的RAM和CPU提供有关WiredTiger如何利用多个CPU核心以及如何提高操作吞吐量的信息。

 

4、数据一致性

日志记录
MongoDB使用磁盘日志的预写日志记录。日志保证MongoDB可以在mongod因崩溃或其他严重故障而终止的情况下，快速恢复写入日志但未写入数据文件的写操作。
保持日志记录处于启用状态，以确保mongod能够恢复其数据文件，并在崩溃后将数据文件保持在有效状态。有关详细信息，请参见日志记录。
从MongoDB 4.0开始，不能为使用WiredTiger存储引擎的副本集成员指定--nojournal选项或storage.journal.enabled:false。

5、Read Concern

New in version 3.2.

Starting in MongoDB 3.6, you can use causally consistent sessions to read your own writes, if the writes request acknowledgement.

Prior to MongoDB 3.6, you must have issued your write operation with { w: "majority" } write concern and then use either "majority" or "linearizable" read concern for the read operations to ensure that a single thread can read its own writes.

To use read concern level of "majority", replica sets must use WiredTiger storage engine.

You can disable read concern "majority" for a deployment with a three-member primary-secondary-arbiter (PSA) architecture; however, this has implications for change streams (in MongoDB 4.0 and earlier only) and transactions on sharded clusters. For more information, see Disable Read Concern Majority.

阅读关注
版本3.2中的新功能。
从MongoDB 3.6开始，如果写入请求确认，可以使用因果一致的会话来读取自己的写入。
在MongoDB 3.6之前，您必须使用{w:“多数”}写关注点发出写操作，然后对读操作使用“多数”或“可线性化”读关注点，以确保单个线程可以读取自己的写操作。
要使用“多数”的读取关注级别，副本集必须使用WiredTiger存储引擎。
对于具有三个成员的主次仲裁器（PSA）架构的部署，可以禁用read concern“多数”；但是，这会影响更改流（仅在MongoDB 4.0和更早版本中）和分片集群上的事务。有关详细信息，请参阅禁用阅读问题多数。

6、禁用HTTP接口

在版本3.6中更改：MongoDB 3.6将不推荐使用的HTTP接口和REST API删除到MongoDB。
MongoDB的早期版本提供了一个HTTP接口来检查服务器的状态，并可以选择运行查询。默认情况下禁用HTTP接口。不要在生产环境中启用HTTP接口。

 

7、分配足够的RAM和CPU

至少，确保每个mongod或mongos实例都可以访问两个实核或一个多核物理CPU。

 

8、缓存与压缩

默认情况下，WiredTiger对所有集合使用snapy块压缩，对所有索引使用前缀压缩。压缩默认值在全局级别上是可配置的，也可以在集合和索引创建期间根据每个集合和每个索引进行设置。
WiredTiger内部缓存中的数据与磁盘上的格式相比使用了不同的表示：
文件系统缓存中的数据与磁盘上的格式相同，包括对数据文件进行任何压缩的好处。操作系统使用文件系统缓存来减少磁盘I/O。
加载在WiredTiger内部缓存中的索引与磁盘上的格式具有不同的数据表示形式，但仍然可以利用索引前缀压缩来减少RAM的使用。索引前缀压缩从索引字段中删除常用前缀。
WiredTiger内部缓存中的收集数据是未压缩的，使用与磁盘格式不同的表示形式。块压缩可以显著节省磁盘存储空间，但数据必须解压缩才能由服务器操作。

MongoDB通过文件系统缓存自动使用WiredTiger缓存或其他进程未使用的所有可用内存。

要调整WiredTiger内部缓存的大小，请参见storage.WiredTiger.engineConfig.cacheSizeGB和--wiredTigerCacheSizeGB。避免将WiredTiger内部缓存大小增加到其默认值以上。

注意
storage.wiredTiger.engineConfig.cacheSizeGB限制wiredTiger内部缓存的大小。操作系统将使用可用的空闲内存进行文件系统缓存，这将允许压缩的MongoDB数据文件保留在内存中。此外，操作系统将使用任何空闲RAM缓冲文件系统块和文件系统缓存。
为了适应RAM的其他使用者，您可能必须减小WiredTiger内部缓存的大小。

 

9、使用固态磁盘（ssd）

MongoDB与SATA-SSD（固态磁盘）相比，具有良好的性能和性价比。
如果可用且经济，请使用SSD。
商品（SATA）旋转驱动器通常是一个不错的选择，因为随着更昂贵的旋转驱动器随机I/O性能的提高并没有那么显著（只有2倍的订单）。使用ssd或增加RAM可以更有效地提高I/O吞吐量。

 

10、关闭NaUMnA硬件

在具有非统一内存访问（NUMA）的系统上运行MongoDB可能会导致许多操作问题，包括在一段时间内性能低下和系统进程使用率高。
在NUMA硬件上运行MongoDB服务器和客户端时，应配置内存交错策略，以便主机以非NUMA方式运行。MongoDB在Linux（2.0版以后）和Windows（2.6版以后）机器上部署时，会在启动时检查NUMA设置。如果NUMA配置可能会降低性能，MongoDB会打印一个警告。
另见
MySQL的“交换疯狂”问题和NUMA post的影响，描述了NUMA对数据库的影响。文章介绍了NUMA及其目标，并说明了这些目标如何与生产数据库不兼容。尽管这篇博文讨论了NUMA for MySQL的影响，但是MongoDB的问题是相似的。The MySQL “swap insanity” problem and the effects of NUMA

在Linux上配置NUMA
在Linux上，必须禁用zone reclaim，并确保mongod和mongos实例由numactl启动，numactl通常是通过平台的init系统配置的。您必须执行这两个操作才能正确禁用NUMA以便与MongoDB一起使用。
1）使用以下命令之一禁用区域回收：

echo 0 | sudo tee /proc/sys/vm/zone_reclaim_mode

sudo sysctl -w vm.zone_reclaim_mode=0

2）确保mongod和mongos由numactl启动。这通常是通过平台的init系统配置的。运行以下命令以确定平台上正在使用的init系统：
ps --no-headers -o comm 1

• If “systemd”, your platform uses the systemd init system, and you must follow the steps in the systemd tab below to edit your MongoDB service file(s).

• If “init”, your platform uses the SysV Init system, and you do not need to perform this step. The default MongoDB init script for SysV Init includes the necessary steps to start MongoDB instances via numactl by default.

• If you manage your own init scripts (i.e. you are not using either of these init systems), you must follow the steps in the Custom init scripts tab below to edit your custom init script(s).

• systemd
• Custom init scripts

You must use numactl to start each of your mongod instances, including all config servers, mongos instances, and clients. Edit the default systemd service file for each as follows:

1. Copy the default MongoDB service file:

   copy

   copied

   sudo cp /lib/systemd/system/mongod.service /etc/systemd/system/

2. Edit the /etc/systemd/system/mongod.service file, and update the ExecStart statement to begin with:

   copy

   copied

   /usr/bin/numactl --interleave=all
   

   Example

   If your existing ExecStart statement reads:

    

   ExecStart=/usr/bin/mongod --config /etc/mongod.conf
   

   Update that statement to read:

    

   ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --config /etc/mongod.conf
   

3. Apply the change to systemd:

   copy

   copied

   sudo systemctl daemon-reload

4. Restart any running mongod instances:

   copy

   copied

   sudo systemctl stop mongod
   sudo systemctl start mongod

5. If applicable, repeat these steps for any mongos instances.

Custom init scripts

You must use numactl to start each of your mongod instances, including all config servers, mongos instances, and clients.

1. Install numactl for your platform if not already installed. Refer to the documentation for your operating system for information on installing the numactl package.

2. Configure each of your custom init scripts to start each MongoDB instance via numactl:

   copy

   copied

   numactl --interleave=all <path> <options>
   

   Where <path> is the path to the program you are starting and <options> are any optional arguments to pass to that program.

   Example

    

   numactl --interleave=all /usr/local/bin/mongod -f /etc/mongod.conf

 

11、RAID              

为了在存储层方面获得最佳性能，请使用由RAID-10支持的磁盘。RAID-5和RAID-6通常不能提供足够的性能来支持MongoDB部署。

 

12、远程文件系统

使用WiredTiger存储引擎，如果远程文件系统符合ISO/IEC 9945-1:1996（POSIX.1），WiredTiger对象可以存储在远程文件系统上。因为远程文件系统通常比本地文件系统慢，使用远程文件系统进行存储可能会降低性能。
如果决定使用NFS，请将以下NFS选项添加到/etc/fstab文件中：bg、nolock和noatime。

 

13、将组件分离到不同的存储设备上

为了提高性能，请考虑根据应用程序的访问和写入模式，将数据库的数据、日志和日志分离到不同的存储设备上。将组件作为单独的文件系统挂载，并使用符号链接将每个组件的路径映射到存储它的设备。
对于WiredTiger存储引擎，还可以将索引存储在不同的存储设备上。有关索引，请参见storage.wiredTiger.engineConfig.directory。
注意
使用不同的存储设备将影响您创建数据快照式备份的能力，因为文件将位于不同的设备和卷上。

 

MongoDB on Linux

Linux上的MongoDB

L i n u x shàng上 de的 M o n g o D B

 

Kernel and File Systems

内核和文件系统 

 

When running MongoDB in production on Linux, you should use Linux kernel version 2.6.36 or later, with either the XFS or EXT4 filesystem. If possible, use XFS as it generally performs better with MongoDB.

在Linux上的生产环境中运行MongoDB时，应该使用Linux内核版本2.6.36或更高版本，并使用XFS或EXT4文件系统。如果可能的话，使用XFS，因为它通常在MongoDB中执行得更好。

 

 

With the WiredTiger storage engine, using XFS is strongly recommended for data bearing nodes to avoid performance issues that may occur when using EXT4 with WiredTiger.

对于WiredTiger存储引擎，强烈建议对数据承载节点使用XFS，以避免将EXT4与WiredTiger一起使用时可能出现的性能问题。

 

 

In general, if you use the XFS file system, use at least version 2.6.25 of the Linux Kernel.

一般来说，如果您使用的是XFS文件系统，请至少使用2.6.25版本的Linux内核。

 

If you use the EXT4 file system, use at least version 2.6.28 of the Linux Kernel.

如果使用EXT4文件系统，请至少使用2.6.28版的Linux内核。

 

On Red Hat Enterprise Linux and CentOS, use at least version 2.6.18-194 of the Linux kernel.

在Red Hat Enterprise Linux和CentOS上，至少使用2.6.18-194版Linux内核。

 

 

系统C库
MongoDB在Linux上使用GNU C库（glibc）。一般来说，每个Linux发行版都提供了自己经过审查的版本。为了获得最佳结果，请使用此系统提供版本的最新更新。您可以使用系统的包管理器检查是否安装了最新版本。例如：
在RHEL/CentOS上，以下命令更新系统提供的GNU C库：
复制的

sudo yum update glibc

在Ubuntu/Debian上，以下命令更新系统提供的GNU C库：
复制的
sudo apt gelibc6

sudo apt-get install libc6

重要的
MongoDB需要一个在目录上支持fsync（）的文件系统。例如，HGFS和Virtual Box的共享文件夹不支持此操作。

 

将vm.swappiness设置为1或0
“交换”是影响虚拟内存管理器行为的Linux内核设置。vm.swappiness设置的范围从0到100：值越高，它越倾向于将内存页交换到磁盘，而不是从RAM中删除页。
设置为0将完全禁用交换[2]。
设置为1只允许内核交换以避免内存不足问题。
设置60告诉内核经常交换到磁盘，这是许多Linux发行版的默认值。
设置为100将告诉内核积极地交换到磁盘。
MongoDB在可以避免或保持最小交换的地方表现最好。因此，您应该根据应用程序需要和群集配置将vm.swappiness设置为1或0。
[2] 对于3.5之前的Linux内核版本，或2.6.32-303之前的RHEL/CentOS内核版本，vm.swappiness设置为0仍允许内核在某些紧急情况下进行交换。
注意
如果MongoDB实例托管在同时运行其他软件（如Web服务器）的系统上，则应将vm.swappiness设置为1。如果可能，强烈建议您在MongoDB自己的专用系统上运行MongoDB。

• To check the current swappiness setting on your system, run:

  copy

  copied

  cat /proc/sys/vm/swappiness

• To change swappiness on your system:

  1. Edit the /etc/sysctl.conf file and add the following line:

     copy

     copied

     vm.swappiness = 1
     

  2. Run the following command to apply the setting:

     copy

     copied

     sudo sysctl -p

NOTE

If you are running RHEL / CentOS and using a tuned performance profile, you must also edit your chosen profile to set vm.swappiness to 1 or 0.

 

 

推荐配置
对于所有MongoDB部署：
使用网络时间协议（NTP）在主机之间同步时间。这在碎片簇中尤为重要。
对于WiredTiger存储引擎，请考虑以下建议：
关闭包含数据库文件的存储卷的atime。
根据u limit引用中的建议，将文件描述符限制-n和用户进程限制（ulimit），-u设置为20000以上。当大量使用时，低ulimit将影响MongoDB，并可能产生错误，导致与MongoDB进程的连接失败和服务丢失。
禁用透明的大页面。MongoDB在普通（4096字节）虚拟内存页上的性能更好。请参见透明的大页面设置。
在BIOS中禁用NUMA。如果这不可能，请参阅NUMA硬件上的MongoDB。
如果不使用默认的MongoDB目录路径或端口，请为MongoDB配置SELinux。
请参阅：Configure SELinux for MongoDB和Configure SELinux for MongoDB Enterprise以获得所需的配置。
注意
如果您使用的是SELinux，任何需要服务器端JavaScript的MongoDB操作都会导致segfault错误。Disable Server-Side Execution of JavaScript描述如何禁用服务器端JavaScript的执行。

 

对于WiredTiger存储引擎：
无论存储介质类型（旋转磁盘、SSD等）如何，将readahead设置设置为8到32。
较高的预读通常有利于顺序I/O操作。由于MongoDB磁盘访问模式通常是随机的，因此使用更高的readahead设置提供的好处有限，或者可能会降低性能。因此，为了获得最佳的MongoDB性能，请将readahead设置在8到32之间，除非测试在更高的readahead值中显示出可测量、可重复和可靠的好处。MongoDB商业支持可以提供关于备用预读配置的建议和指导。

 

 

 

 

来源：oschina

链接：https://my.oschina.net/u/4396833/blog/4066635