1、从命令行启动

MongoDB 服务器是以 mongod 可执行文件来启动的。mongod 有很多可配置的启动选项，要查看这些选项，可以在命令行中运行 mongod --help。以下是几个常用且需要注意的选项。

–dbpath

指定一个目录作为数据目录，默认为 /data/db/（在Windows 系统中为 MongoDB 可执行文件所在磁盘卷上的 \data\db\ 目录）​。一台机器上的每个 mongod 进程都需要有自己的数据目录，因此如果在一台机器上运行了3 个 mongod 实例，就需要 3 个单独的数据目录。当mongod 启动时，会在其数据目录中创建一个mongod.lock 文件，以防止其他 mongod 进程使用该目录。如果试图使用相同的数据目录启动另一台 MongoDB服务器，则会提示一个错误。

exceptionininitAndListen:DBPathInUse:Unable to lock the lock file:\ data/db/mongod.lock(Resource temporarily unavailable).Another mongod instance is already running on the data/db directory,\ terminating

–port

指定服务器监听的端口号。默认情况下，mongod 会使用 27017 端口，这个端口不太可能被另一个进程（除了其他的 mongod 进程之外）使用。如果希望在一台机器上运行多个 mongod 进程，则需要为每个进程指定不同的端口。如果试图在已经被占用的端口上启动mongod，则会被提示一个错误。

Failed tosetup listener:SocketException:Address alreadyinuse.

–fork

在基于 Unix 的系统中，使用 fork 创建服务器进程，将 MongoDB 作为守护进程运行。

如果是第一次启动 mongod（使用一个空的数据目录）​，那么文件系统可能需要几分钟来分配数据库文件。在完成预分配并且 mongod 准备接受连接之后，父进程才会从 fork 返回。因此，fork 可能会被挂起。可以跟踪日志来获取正在进行的操作。如果指定了 --fork，则必须同时使用 --logpath。

–logpath

将所有输出信息发送到指定文件，而不是在命令行上输出。假设我们对该目录拥有写权限，如果文件不存在，则会自动创建该文件。如果日志文件已经存在，则会覆盖掉该文件，并删除所有旧的日志条目。如果希望保留旧的日志，除了使用 --logpath 之外，还应该使用 --logappend 选项（强烈推荐）​。

–directoryperdb

将每个数据库放在自己单独的目录中。这允许将不同的数据库挂载到不同的磁盘上（如果需要的话）​。这种方法的常见用途是将 local 数据库放在自己的磁盘上，或者在磁盘已满时将数据库移动到另一个磁盘上。也可以将负载较高的数据库放在速度更快的磁盘上，将负载较低的数据库放在速度更慢的磁盘上。总之这个选项可以为之后移动数据提供更多的灵活性。

–config

对于命令行中未指定的其他选项可以额外使用配置文件。这通常用于确保每次重启时的选项都是相同的​。

例如，要作为守护进程启动服务器，监听 5586 端口，并将所有输出发送到 mongodb.log 文件，可以运行如下命令：

$ ./mongod--dbpathdata/db--port5586--fork--logpathmongodb.log--logappend2019-09-06T22:52:25.376-0500 I CONTROL[main]Automatically disabling TLS1.0,\to force-enable TLS1.0specify--sslDisabledProtocols'none'about to fork child process, waitinguntilserver is readyforconnections. forked process:27610child process started successfully, parent exiting

当第一次安装并启动 MongoDB 时，应该查看一下日志。这一点很容易被忽略，特别是使用初始化脚本来启动MongoDB 的时候。但是日志中通常包含重要的警告信息，有助于防止之后发生错误。如果在启动 MongoDB时没有看到任何警告，则表示设置已经完成。​（启动时的警告信息也会出现在 shell 中。​）

如果在启动时出现了警告信息，则应该将其记录下来。MongoDB 会因为以下问题发出警告：正在一台 32 位的机器上运行（MongoDB 不是为 32 位机器设计的）​，启用了 NUMA（可能会严重拖慢应用程序的运行速度）或系统未允许足够的打开文件描述符（MongoDB 需要使用大量的文件描述符）​。

重新启动数据库时，日志的前文不会发生变化，因此可以从初始化脚本运行 MongoDB，并在了解了日志内容后忽略这些日志。然而，在每次安装、升级或从崩溃中恢复时 再次检查日志是一个好主意，这样可以确保 MongoDB和系统是一致的。

启动数据库时，MongoDB 会向 local.startup_log 集合中写入一个文档，来描述 MongoDB 的版本、底层系统以及所使用的标志位。可以使用 mongo shell 查看此文档：

>use local switched to db local>db.startup_log.find().sort({startTime:-1}).limit(1).pretty(){"_id":"server1-1544192927184","hostname":"server1.example.net","startTime":ISODate("2019-09-06T22:50:47Z"),"startTimeLocal":"Fri Sep 6 22:57:47.184","cmdLine":{"net":{"port":5586},"processManagement":{"fork":true},"storage":{"dbPath":"data/db"},"systemLog":{"destination":"file","logAppend":true,"path":"mongodb.log"}},"pid":NumberLong(27278),"buildinfo":{"version":"4.2.0","gitVersion":"a4b751dcf51dd249c5865812b390cfd1c0129c30","modules":["enterprise"],"allocator":"system","javascriptEngine":"mozjs","sysInfo":"deprecated","versionArray":[4,2,0,0],"openssl":{"running":"Apple Secure Transport"},"buildEnvironment":{"distmod":"","distarch":"x86_64","cc":"gcc: Apple LLVM version 8.1.0 (clang-802.0.42)","ccflags":"-mmacosx-version-min=10.10-fno-omit\-frame-pointer-fno-strict-aliasing \-ggdb-pthread-Wall-Wsign-compare-Wno-unknown-pragmas \-Winvalid-pch-Werror-O2-Wno-unused\-local-typedefs-Wno-unused-function-Wno-unused-private-field \-Wno-deprecated-declarations \-Wno-tautological-constant-out-of\-range-compare-Wno-unused-const-variable-Wno\-missing-braces-Wno-inconsistent\-missing-override-Wno-potentially-evaluated-expression \-Wno-exceptions-fstack-protector\-strong-fno-builtin-memcmp","cxx":"g++: Apple LLVM version 8.1.0 (clang-802.0.42)","cxxflags":"-Woverloaded-virtual -Werror=unused-result \ -Wpessimizing-move -Wredundant-move \ -Wno-undefined-var-template -stdlib=libc++ \ -std=c++14","linkflags":"-mmacosx-version-min=10.10 -Wl, \ -bind_at_load -Wl,-fatal_warnings \ -fstack-protector-strong \ -stdlib=libc++","target_arch":"x86_64","target_os":"macOS"},"bits":64,"debug":false,"maxBsonObjectSize":16777216,"storageEngines":["biggie","devnull","ephemeralForTest","inMemory","queryable_wt","wiredTiger"]}}

这个集合对于跟踪升级和更改后的运行状况非常有用。

基于文件的配置

MongoDB 支持从文件中读取配置信息。如果有大量要使用的选项，或者使用了自动化任务来启动 MongoDB，那么这种方式可能会很有用。可以使用 -f 或 --config 标记来告诉服务器从配置文件中获取选项。例如，运行mongod --config ~/.mongodb.conf来使用~/.mongodb.conf作为配置文件。

配置文件中支持的选项与命令行中接受的选项相同。然而，二者格式是不同的。从 MongoDB 2.6 开始，MongoDB 的配置文件使用 YAML 格式。下面是一个配置文件的例子：

systemLog:destination:filepath:"mongod.log"logAppend:truestorage:dbPath:data/dbprocessManagement:fork:truenet:port:5586...

这个配置文件指定的选项与之前启动时使用的常规命令行参数相同。注意，这些相同的选项会反映在上一节提到的startup_log 集合的文档中。唯一的区别是，这些选项使用的是 JSON 而不是 YAML。

MongoDB 4.2 添加了一些扩展指令，以允许加载特定的配置文件选项或加载整个配置文件。扩展指令的优点是，一些机密信息（比如密码和安全证书）不必直接存储在配置文件中。可以使用 --configExpand 命令行选项来启用该特性，并且必须同时包含希望启用的扩展指令。rest 和 exec 是 MongoDB 扩展指令的当前实现。rest 扩展指令可以从 REST 端加载某些特定的配置文件值或整个配置文件。exec 扩展指令可以从 shell 或终端命令加载某些特定的配置文件值或整个配置文件。

2、停止MongoDB

安全停止正在运行的 MongoDB 服务器和能够启动服务器一样重要。有几种不同的方式可以有效实现这一点。

关闭正在运行的服务器的最简洁方式是使用 shutdown 命令 {“shutdown” : 1}。这是一个管理命令，必须在 admin数据库上运行。shell 提供了一个辅助函数来简化这个过程：

>use admin switched to db admin>db.shutdownServer()server should be down...

当在主节点上运行时，shutdown 命令在关闭服务器之前会将主节点退位，并等待从节点追赶上同步进度。这可以将回滚的可能性降到最低，但无法保证关闭的成功。如果 在几秒内没有可用的从节点赶上进度，那么 shutdown 命令就会失败，并且（前）主节点也不会被关闭：

>db.shutdownServer(){"closest":NumberLong(1349465327),"difference":NumberLong(20),"errmsg":"no secondaries within 10 seconds of my optime","ok":0}

可以使用 force 选项强制 shutdown 命令关闭主节点：

db.adminCommand({"shutdown":1,"force":true})

这相当于发送一个 SIGINT 或 SIGTERM 信号（这 3 种方式都可以实现安全的关闭，但可能会有未复制的同步数据）​。如果服务器在终端中作为前台进程运行，则可以通过按 Ctrl-C 发送一个 SIGINT 信号。另外，像 kill 这样的命令也可以用来发送信号。假设 mongod 的 PID 是10014，则相应的命令就是 kill -2 10014（SIGINT）或kill 10014（SIGTERM）​。

当 mongod 接收到 SIGINT 或 SIGTERM 时，它会安全地关闭。这意味着它会等待任何正在运行的操作或文件预分配完成（可能需要一些时间）​，然后关闭所有打开的连接，再将所有数据刷新到磁盘，最后停止运行。

3、安全性

不要设置可公开寻址的 MongoDB 服务器。应该尽可能严格地限制外部对 MongoDB 的访问。最好的方法是设置防火墙，只允许内部网络地址对 MongoDB 的访问。

除了防火墙，还有一些选项可以添加到配置文件中以增加安全性。

–bind_ip

指定 MongoDB 要监听的接口。通常，这应该是一个内部 IP 地址：应用程序服务器和集群的其他成员可以访问，但外部无法访问。如果在同一台机器上运行应用程序服务器，则对于 mongos 进程来说，将其设置为localhost 是合适的。而对于配置服务器和分片，它们需要从其他机器上寻址，因此应该使用非 localhost 地址。

从 MongoDB 3.6 开始，mongod 和 mongos 进程会默认绑定到 localhost。当仅绑定到 localhost 时，mongod 和 mongos 将只接受来自运行在同一台机器上的客户端的连接。这有助于限制不受保护的 MongoDB实例的暴露。如果要绑定其他地址，则可以使用 net.bindIp 配置文件设置或 --bind_ip 命令行选项为其指定一个主机名或 IP 地址的列表。

–nounixsocket

禁用对 Unix 域套接字的监听。如果不打算通过文件系统套接字进行连接，那么同样可以禁用此选项。如此一来，只有当应用程序服务器运行在同一台机器上时，才能通过文件系统套接字进行连接：文件系统套接字必须在本地使用。

–noscripting

禁用服务器端 JavaScript 的执行。一些报告出的MongoDB 安全问题都与 JavaScript 相关，因此如果应用程序允许，那么禁用它通常会更安全。

一些 shell 中的辅助函数（尤其是 sh.status()）会假定 JavaScript 在服务器上是可用的。试图在禁用JavaScript 的情况下运行这些辅助函数会出现错误。

3.1、数据加密

MongoDB 企业版提供了数据加密的功能，但 MongoDB的社区版本不支持这些选项。

数据加密过程包括以下步骤：

• 生成一个主密钥；
• 为每个数据库生成密钥；
• 使用数据库密钥加密数据；
• 使用主密钥加密数据库密钥。

当使用数据加密时，文件系统中的所有数据文件都会被加密。数据仅在内存和传输过程中处于解密状态。可以使用TLS/SSL 加密 MongoDB 的所有网络传输。MongoDB企业版用户可以添加到配置文件中的数据加密选项如下。

–enableEncryption

在 WiredTiger 存储引擎中启用加密。使用此选项，存储在内存和磁盘上的数据会被加密。这种方式有时被称为“静态加密”​（encryption at rest）​。要想传入加密密钥并对加密进行配置，则必须将其设置为 true。该选项默认为 false。

–encryptionCipherMode

设置 WiredTiger 中静态加密的加密模式。有两种模式可以使用：AES256-CBC 和 AES256-GCM。AES256-CBC 是密码块链接模式下 256 位高级加密标准（256bit Advanced Encryption Standard in CipherBlock Chaining Mode）的首字母缩写。AES256-GCM使用了伽罗瓦/计数器（Galois/Counter）模式。两者都是标准的加密密码。从 MongoDB 4.0 开始，Windows系统中的 MongoDB 企业版不再支持 AES256-GCM。

–encryptionKeyFile

如果使用密钥管理互操作性协议（KMIP）以外的进程对密钥进行管理，则需要指定本地密钥文件的路径。

MongoDB 企业版还支持使用 KMIP 进行密钥管理。关于KMIP 的讨论超出了本书的范围。请参阅 MongoDB 文档以了解配合使用 KMIP 的详细信息。

3.2、SSL连接

MongoDB 支持使用 TLS/SSL 对传输进行加密。该特性在 MongoDB 的所有版本中都可用。默认情况下，连接到 MongoDB 的数据传输是不加密的。然而，TLS/SSL 机制保证了传输的加密。MongoDB 会使用操作系统中可用的本地 TSL/SSL 库。可以使用 --tlsMode 及相关选项配置 TLS/SSL。

4、日志

默认情况下，mongod 会将日志发送到标准输出（stdout）​。大多数初始化脚本会使用 --logpath 选项将日志发送到文件。如果在一台机器上有多个 MongoDB实例（比如，一个 mongod 和一个 mongos）​，那么需要确保它们的日志存储在不同的文件中。确保你知道日志的位置，并具有对文件的读取访问权限。

MongoDB 会输出很多日志消息，但是不要使用 --quiet选项（它会隐藏部分日志消息）​。保留默认的日志级别通常可以工作得很好：有足够的信息可以用于基本的调试（为什么这么慢？为什么不启动？等等）​，但同时不会占用太多的空间。

如果要调试应用程序的某个特定问题，那么可以使用一些 选项从日志中获取更多信息。可以运行 setParameter 命令以更改日志级别，或者使用 --setParameter 选项将日志级别作为字符串传递，从而在启动时对其进行设置：

>db.adminCommand({"setParameter":1,"logLevel":3})

还可以对特定组件的日志级别进行更改。如果要调试应用程序的某个特定方面，并且需要更多的信息（但仅来自该组件）​，这种方式就会很有帮助。本例会将默认日志详细信息设置为 1，查询组件详细信息设置为 2：

>db.adminCommand({"setParameter":1,logComponentVerbosity:{verbosity:1,query:{verbosity:2}}})

在完成调试之后，记得将日志级别调回 0，否则日志中可能会产生不必要的信息。可以将日志级别调高至 5，此时mongod 会打印出大部分操作，包括处理的每个请求的内容。这可能会导致大量的 I/O，因为 mongod 将所有内容都写到了日志文件中，从而拖慢了一个繁忙系统的运行速度。如果需要在操作发生时查看每个操作，那么启用分析器是一个更好的选择。

MongoDB 默认会记录运行时间超过 100 毫秒的查询信息。如果 100 毫秒对于你的应用程序来说太短或太长，那么可以使用 setProfilingLevel 更改此阈值：

>// 仅记录耗时超过500毫秒的查询>db.setProfilingLevel(1,500){"was":0,"slowms":100,"ok":1}>db.setProfilingLevel(0){"was":1,"slowms":500,"ok":1}

上面第二条指令会关闭分析器，但是第一条指令给出的以毫秒为单位的值将继续用作日志的阈值（跨所有数据库）​。还可以使用 --slowms 选项重启 MongoDB 以对此参数进行设置。

最后，设置一个每天或每周轮换日志的定期任务。如果MongoDB 启动时使用了 --logpath 选项，则向进程发送 SIGUSR1 信号会使其轮换日志。还可以使用logRotate 命令来执行同样的操作：

>db.adminCommand({"logRotate":1})

如果 MongoDB 不是使用 --logpath 启动的，则无法轮换日志。