配置你的生产环境

假设你已开发完成一个在线书店管理系统，系统采用MongoDB作为核心的数据存储，涵盖了书籍信息、用户数据及订单记录。现阶段，项目即将从开发环境迁移至生产环境，面向大规模实际用户提供服务。

在生产环境部署MongoDB时，需要远超开发环境的严谨和细致。你必须综合考虑数据安全、系统高可用性、性能优化、日志监控，以及服务的平滑启动与关闭方式。 听起来是不是很吓人，不用担心，我们将带你一步一步地配置你的生产环境。

命令行启动MongoDB

在生产环境部署MongoDB时，启动方式相比开发测试阶段会更加规范和严格。我们应该为每个启动参数做出合理配置，以确保数据库服务稳定、安全地运行。

数据目录配置

MongoDB 默认将数据存储在系统盘的 /data/db/ 目录下，但在生产环境中，推荐将数据库文件放在独立的高性能磁盘分区，以满足更高的数据读写需求，提高系统可靠性和扩展性。

|
$ ./mongod --dbpath /mnt/data/mongodb

这里我们指定了/mnt/data/mongodb作为数据目录。MongoDB会在这个目录中创建各种数据文件，并且会在目录中放置一个mongod.lock文件来防止其他MongoDB进程同时使用这个目录。 如果你的服务器上需要运行多个MongoDB实例（比如在测试分片集群时），每个实例都需要自己的数据目录：

|
# 主数据库实例
$ ./mongod --dbpath /data/prod --port 27017
 
# 测试数据库实例
$ ./mongod --dbpath /data/test --port 27018

端口配置

MongoDB默认使用27017端口，但有时候我们需要修改这个端口，可能是为了避免与其他服务冲突，也可能是为了在同一台机器上运行多个实例。

|
$ ./mongod --port 27018

需要注意，如果你选择的端口号已经被其他服务占用，MongoDB 会提示错误："Failed to set up listener: SocketException: Address already in use."。此时，应当更换为一个空闲端口，确保数据库服务能够正常启动。

后台运行配置

在生产环境部署时，建议将 MongoDB 设置为后台守护进程运行，这样既不会占用终端，也便于长期稳定地提供服务。

|
$ ./mongod --fork --logpath /var/log/mongodb.log

使用--fork参数后，MongoDB会创建一个子进程在后台运行，而父进程会在服务器准备好接受连接后退出。如果你忘记指定--logpath，MongoDB会拒绝启动，因为后台进程无法输出到终端。

日志文件配置

在生产环境中，日志是定位和分析问题的关键工具。建议合理配置日志文件路径，并根据实际需求设置是否以追加模式写入日志文件，以便完整保留历史记录。

|
$ ./mongod --logpath /var/log/mongodb.log --logappend

如果不使用--logappend，每次重启MongoDB都会覆盖之前的日志文件，这可能会导致我们丢失重要的历史信息。

数据库目录分离

在实际的生产环境中，经常会有将每个数据库单独存储到不同子目录的需求。这不仅有助于灵活分配和管理磁盘空间，还便于针对不同数据库制定更加精细化的存储策略。

|
$ ./mongod --directoryperdb

启用该选项后，MongoDB 会为每个数据库在主数据目录下单独创建一个子目录，实现物理上的数据库目录分离。此功能适用于以下专业场景：

• 根据数据库的重要性，将其存储在性能或可靠性要求不同的磁盘上，实现资源的灵活调度与隔离
• 某个数据库空间需求激增时，可便捷地迁移其数据目录至更大或更快的存储介质，无需影响其他数据库的运行
• 实现对单一数据库的定向备份和恢复，精细化满足运维和灾备需求

配置文件使用

虽然可以通过命令行参数配置所有选项，但在生产环境中，我们更倾向于使用配置文件来确保配置的一致性。

|
$ ./mongod --config /etc/mongodb.conf

在实际生产环境中，我们推荐使用YAML格式来编写MongoDB的配置文件。这样不仅能提升配置项的结构化和可读性，还方便后续的维护和自动化管理。

启动后，MongoDB会在local.startup_log集合中记录启动信息。你可以通过以下方式查看：

|
> use local
> db.startup_log.find().sort({startTime: -1}).limit(1).pretty()

local.startup_log集合详细记录了MongoDB实例的版本信息、启动参数及系统环境等关键信息，是后续排查历史配置、追踪环境变更的重要依据。

配置文件规范化管理

在企业或团队环境中，为了保障开发、测试与生产等各类环境的一致性与可维护性，强烈推荐通过统一的配置文件进行MongoDB实例的管理。配置文件不仅提升了可读性和复用性，还便于自动化部署和变更审计。

YAML格式配置文件

上面我们已经提到过了，MongoDB支持以YAML格式来编写配置文件，相比命令行参数，YAML配置结构化更强，语义更加清晰。在实际生产部署中，推荐采用此方式集中管理各项参数。例如，以下是针对在线书店业务的生产环境配置样例：

|
systemLog:
  destination: file
  path: "/var/log/mongodb/mongod.log"
  logAppend: true
 
storage:
  dbPath: "/data/mongodb"
  directoryPerDB: true
 
processManagement:
  fork: true
 
net:
  port: 27017
  bindIp: "127.0.0.1,192.168.1.100"

上述配置文件实现了以下功能：

• 将日志以追加方式输出至指定文件，便于日志归档与分析
• 数据文件存储于/data/mongodb目录，并为每个数据库分配独立目录以提升管理性
• 以守护（后台）进程方式运行MongoDB，适用于生产级服务部署
• 监听27017端口，仅允许本地及指定内网IP访问，提高安全性

从命令行到配置文件的转换

对于习惯通过命令行参数启动MongoDB的运维或开发人员，推荐将常用参数规范整理为配置文件形式，这不仅有助于管理，也便于环境迁移与自动化运维。例如，下述命令行启动方式：

|
$ ./mongod --dbpath data/db --port 5586 --fork --logpath mongodb.log --logappend --directoryperdb

对应的配置文件如下：

|
storage:
  dbPath: data/db
  directoryPerDB: true
 
processManagement:
  fork: true
 
net:
  port: 5586
 
systemLog:
  destination: file
  path: mongodb.log
  logAppend: true

配置扩展指令

自MongoDB 4.2版本起，系统支持配置扩展指令，可实现从外部安全源动态加载敏感信息，有效规避将密码及证书等敏感内容明文写入配置文件的风险。

REST扩展指令

__rest指令可以从REST端点加载配置：

|
storage:
  dbPath: "/data/db"
 
__rest:
  - url: "http://config-server.example.com/mongo-config"
    field: "security"

执行扩展指令

__exec指令可以从shell命令或脚本获取配置：

|
storage:
  dbPath: "/data/db"
 
__exec:
  - command: "/usr/local/bin/get-mongo-password.sh"
    field: "security.kmip.clientCertificatePassword"

要启用这些扩展指令，需要在启动时指定：

|
$ ./mongod --config mongo.conf --configExpand "__rest,__exec"

这种方式特别适合云环境或容器化部署，可以将敏感配置集中管理。

MongoDB的停止

在生产环境中，安全、规范地停止MongoDB服务器和安全启动同等重要。若数据库服务被突然中断，容易造成数据丢失甚至数据不一致等问题。

使用管理命令安全关闭

我们推荐使用的关停方式是通过MongoDB的管理命令发起关闭操作。此方法能够保证已发起的请求全部完成，并将内存中的数据可靠落盘，有效降低数据风险。

|
> use admin
> db.shutdownServer()

当你在主节点上执行这个命令时，MongoDB会先尝试将主节点角色转移给其他从节点，确保复制集的连续性。然后等待从节点追赶上最新的数据，最后安全地关闭服务器。

在极端情况下，如果你需要无视数据同步状态立即强制关闭主节点，可使用以下强制关闭选项：

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

这个命令会立即关闭主节点，但是可能会导致一些数据未能同步到从节点。所以在使用前请确保你理解这个操作的后果。

信号量关闭

如果你在终端前台运行MongoDB，或者需要从脚本中停止服务，可以使用系统信号。 对于前台运行的MongoDB，按下Ctrl+C会发送SIGINT信号，触发关闭指令。

如果MongoDB在后台运行，你可以使用kill命令：

|
# 优雅关闭 (SIGTERM)
$ kill -15 12345
 
# 或者强制关闭 (SIGKILL) - 不推荐
$ kill -9 12345

其中12345是MongoDB进程的PID。SIGTERM信号会触发与shutdownServer()命令相同的正常关闭过程。 当MongoDB收到关闭信号时，它会按以下顺序执行：

1. 停止接受新的连接请求
2. 等待所有正在进行的操作完成
3. 将内存中的数据刷新到磁盘
4. 关闭所有打开的文件描述符
5. 记录关闭事件到日志
6. 退出进程

这个过程通常只需要几秒钟，但在高负载情况下可能需要更长时间。如果你从终端运行MongoDB，耐心等待关闭完成是很重要的。

MongoDB安全配置

在生产环境中，数据库安全是核心考量之一。MongoDB 作为存储关键业务数据的基础，需确保其访问和数据安全策略均经过严密设计和实施。规范的安全配置不仅可以防止数据泄露，还能抵御潜在的恶意攻击。

网络访问限制

首要措施是限制MongoDB仅监听受信任的网络接口。切勿将MongoDB服务直接暴露在公网环境中，以防未经授权的访问和攻击。

|
net:
  bindIp: "127.0.0.1,192.168.1.100"

这个配置让MongoDB只监听本地回环地址（127.0.0.1）和内网地址（192.168.1.100）。应用服务器可以通过内网访问数据库，而外部攻击者无法直接连接。 从MongoDB 3.6开始，如果不指定bindIp，服务器默认只绑定到localhost，这提供了额外的安全保障。

防火墙配置

除了配置MongoDB的绑定地址外，还可以通过防火墙加强网络安全。例如，如果你的应用服务器地址是192.168.1.10，可以用iptables添加如下规则：

|
# 只允许应用服务器访问MongoDB端口
$ iptables -A INPUT -p tcp -s 192.168.1.10 --dport 27017 -j ACCEPT
$ iptables -A INPUT -p tcp --dport 27017 -j DROP

或者使用firewalld：

|
$ firewall-cmd --add-rich-rule='rule family="ipv4" source address="192.168.1.10" port protocol="tcp" port="27017" accept'
$ firewall-cmd --runtime-to-permanent

禁用UNIX域套接字

如果你的应用服务器和数据库运行在同一台主机上，其实一般也用不到通过文件系统套接字来访问MongoDB。

|
net:
  unixDomainSocket:
    enabled: false

或者使用命令行参数：

|
$ ./mongod --nounixsocket

通过禁用UNIX域套接字，可以有效降低本地未授权用户通过文件系统接口访问MongoDB实例的风险，从而进一步收窄潜在的攻击面。

服务器端脚本执行

MongoDB支持在服务器端执行JavaScript脚本，这为运维和数据处理带来便利，但在生产环境中开启此功能可能增加安全隐患，应谨慎使用。

|
security:
  javascriptEnabled: false

或者：

|
$ ./mongod --noscripting

禁用JavaScript后，一些shell辅助函数可能无法正常工作，比如sh.status()。但在大多数应用场景中，我们可以通过应用层来实现这些功能。

在将MongoDB部署到生产环境之前，建议开展如下安全核查：

1. 检查bindIp参数，确保仅绑定可信任的IP地址；
2. 检查防火墙配置，保证仅允许必要的访问流量通过；
3. 核实身份认证与访问授权机制是否已经启用并正确配置；
4. 确认数据库监听的端口未暴露在公网，减少潜在攻击面；
5. 检查日志记录是否覆盖了关键的安全事件，方便日后审计。

这些安全措施能够显著提升MongoDB的防护能力。但需要注意，安全管理是一个持续演进的过程，务必定期回顾并更新相关配置，以应对新的威胁和变化。

数据加密保护

在涉及敏感数据的应用场景（如在线书店系统，需要处理用户支付信息和个人数据）中，数据加密是提升整体安全性的关键手段，也是防范数据泄露的最后防线。即便攻击者获得了服务器磁盘或备份文件，如果数据经过加密，也无法直接获取明文内容。

MongoDB Enterprise 版本的数据加密功能基于分层密钥管理设计，包括如下几级：

1. 主密钥（Master Key）：系统中的顶层密钥，用于加密数据库密钥，通常由外部密钥管理系统（如KMS服务）托管。
2. 数据库密钥（Database Key）：每个数据库各自独立的密钥，用于加密对应数据库的数据密钥。
3. 数据加密（Data Encryption）：实际的数据由数据库密钥加密和解密，确保持久化在磁盘上的信息始终处于加密状态。

上述架构确保了数据在内存中解密，磁盘上的所有数据文件都保持加密状态。

启用数据加密

在MongoDB Enterprise版本中，要启用WiredTiger存储引擎的数据加密，需要在配置文件中设置：

|
security:
  enableEncryption: true
  encryptionCipherMode: AES256-GCM

或者使用命令行：

|
$ ./mongod --enableEncryption --encryptionCipherMode AES256-GCM

加密模式选择

MongoDB 提供了两种主流的 AES 加密模式可供选择：

• AES256-CBC：基于 256 位密钥的密码块链（CBC）模式，兼容性较强，适用于大多数通用场景。
• AES256-GCM：基于 256 位密钥的 Galois/Counter Mode（GCM）模式，具备数据加密和完整性认证能力，能够有效防止数据被篡改，安全性更高。

根据实际安全需求和性能需求，建议优先考虑 AES256-GCM 模式。 AES256-GCM不仅加密数据，还能检测数据是否被篡改，提供额外的安全保障。

|
security:
  encryptionCipherMode: AES256-GCM

密钥文件管理

在密钥管理方面，常见且直接的方法是采用本地密钥文件：

|
security:
  encryptionKeyFile: /etc/mongodb/keyfile

密钥文件必须是96字节的二进制文件，可以使用openssl生成：

|
$ openssl rand -base64 96 > /etc/mongodb/keyfile
$ chmod 600 /etc/mongodb/keyfile
$ chown mongodb:mongodb /etc/mongodb/keyfile

KMIP密钥管理

在企业级应用场景中，建议采用 KMIP（密钥管理互操作性协议）实现集中化的密钥管理，以提升密钥生命周期管理的安全性与合规性：

|
security:
  kmip:
    serverName: kmip.example.com
    port: 5696
    clientCertificateFile: /etc/mongodb/kmip-client.pem
    clientCertificatePassword: securePassword
    serverCAFile: /etc/mongodb/kmip-ca.pem

KMIP允许密钥在专门的硬件安全模块（HSM）中生成和管理，提供企业级的密钥安全保障。 实施数据加密必然会引入一定的系统开销，主要体现在以下几个方面：

• 存储空间：加密后的数据体积通常会略有增加，占用更多磁盘空间。
• 计算资源：加解密过程需消耗一定的CPU算力，可能对处理性能产生影响。
• 内存资源：密钥管理和加密元数据等操作会占用额外的内存。

实际应用中，这些性能损耗在大部分场景下是可以接受的，尤其是在安全性要求较高的环境。如果对系统性能有严格要求，建议仅对敏感字段进行加密，而不是对整个数据库实施加密，从而实现安全性与性能的平衡。

SSL/TLS传输加密

在数据安全体系中，网络传输加密是防止敏感信息在客户端与服务器之间被窃听和篡改的重要措施。以在线书店为例，用户下单时传输的信用卡等敏感数据，若未加密，极易被恶意第三方截获。通过网络传输加密，可有效降低数据泄露风险，保障业务安全合规。

启用TLS连接

MongoDB 原生支持 TLS/SSL 协议对网络流量进行加密。可以通过配置文件实现 TLS 加密：

|
net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/mongodb/ssl/mongodb.pem
    CAFile: /etc/mongodb/ssl/ca.pem

或者使用命令行：

|
$ ./mongod --tlsMode requireTLS --tlsCertificateKeyFile /etc/mongodb/ssl/mongodb.pem --tlsCAFile /etc/mongodb/ssl/ca.pem

TLS模式选项

MongoDB提供了不同的TLS模式来适应各种部署场景：

• disabled：不使用TLS（默认值，不推荐生产环境使用）
• allowTLS：允许TLS连接，也接受非TLS连接
• preferTLS：优先使用TLS，但接受非TLS连接
• requireTLS：要求所有连接都使用TLS

|
net:
  tls:
    mode: requireTLS

在生产环境中，建议使用requireTLS模式确保所有连接都被加密。

生成SSL证书

要使用TLS，需要准备服务器证书。可以使用openssl生成自签名证书用于测试：

|
# 生成私钥
$ openssl genrsa -out mongodb.key 2048
 
# 生成证书签名请求
$ openssl req -new -key mongodb.key -out mongodb.csr -subj "/C=CN/ST=Beijing/L=Beijing/O=BookStore/CN=mongodb.example.com"
 
# 生成自签名证书
$ openssl x509 -req -days 365 -in mongodb.csr -signkey mongodb.key -out mongodb.crt
 
# 合并证书和私钥
$ cat mongodb.crt mongodb.key > mongodb.pem

在生产环境中，应该使用由受信任的证书颁发机构（CA）签发的证书，而不是自签名证书。

客户端连接配置

客户端也需要配置TLS连接。以Node.js应用为例，可以使用mongoose库：

|
const mongoose = require('mongoose');
 
const connectionString = 'mongodb://mongodb.example.com:27017/bookstore?tls=true&tlsCAFile=/path/to/ca.pem&tlsCertificateKeyFile=/path/to/client.pem';
 
mongoose.connect(connectionString, {
  tls: true,
  tlsCAFile: '/path/to/ca.pem',
  tlsCertificateKeyFile: '/path/to/client.pem'
});

Python应用可以使用pymongo库：

|
from pymongo import MongoClient
 
client = MongoClient(
    'mongodb://mongodb.example.com:27017/',
    tls=True,
    tlsCAFile='/path/to/ca.pem',
    tlsCertificateKeyFile='/path/to/client.pem'
)

证书验证

MongoDB支持多种证书验证模式，可以在配置文件中设置：

|
net:
  tls:
    mode: requireTLS
    certificateKeyFile: /etc/mongodb/ssl/mongodb.pem
    CAFile: /etc/mongodb/ssl/ca.pem
    allowInvalidCertificates: false
    allowInvalidHostnames: false

• allowInvalidCertificates: 是否允许无效证书（生产环境设为false）
• allowInvalidHostnames: 是否允许证书主机名不匹配（生产环境设为false）

同样的，启用TLS也会带来一些性能开销，主要体现在以下几个方面：

• 握手开销：建立连接时需要额外的TLS握手过程，会增加一定的延迟。
• 加密解密开销：每个数据包都需要加密和解密，会增加一定的计算开销。
• CPU使用增加：加密操作需要更多CPU资源，会增加一定的CPU使用率。

对于大多数应用，这个性能影响是可接受的，特别是考虑到安全性收益。现代服务器硬件通常能够很好地处理TLS开销。 在生产环境中，建议禁用过时的TLS版本，只允许TLS 1.2和TLS 1.3连接，提供更好的安全性。

|
net:
  tls:
    disabledProtocols: "TLS1_0,TLS1_1"

日志管理和监控

日志详尽地记录了数据库的各类关键事件，不仅为问题定位和性能分析提供支撑，也为系统稳定运行保驾护航。例如，当你的在线业务数据库响应变慢时，及时分析日志有助于快速查明并追踪瓶颈查询或故障原因。

日志输出配置

MongoDB 默认将日志输出到标准输出（stdout）。在生产环境中，为了便于问题追踪和长期归档，更推荐将日志写入文件：

|
systemLog:
  destination: file
  path: "/var/log/mongodb/mongod.log"
  logAppend: true

如果运行多个MongoDB实例，你就需要确保每个实例有独立的日志文件，而不是共享同一个日志文件：

|
# 主节点日志
systemLog:
  destination: file
  path: "/var/log/mongodb/primary.log"
  logAppend: true
 
# 从节点日志
systemLog:
  destination: file
  path: "/var/log/mongodb/secondary.log"
  logAppend: true

日志级别控制

MongoDB支持多级日志控制，可以根据需要调整详细程度：

|
// 设置全局日志级别为3（更详细）
db.adminCommand({"setParameter": 1, "logLevel": 3})
 
// 为查询组件设置级别2
db.adminCommand({
  "setParameter": 1,
  "logComponentVerbosity": {
    "verbosity": 1,
    "query": {"verbosity": 2}
  }
})

日志级别从0（最少信息）到5（最多信息）。生产环境通常使用默认级别（0或1），在调试时临时提高级别，但不要设置得太高，否则会生成大量的日志，占用过多的磁盘空间。

慢查询日志

慢查询日志帮助识别性能瓶颈。默认情况下，超过100毫秒的查询会被记录，如果100毫秒太短或太长，可以在配置文件中设置：

|
// 设置慢查询阈值为500毫秒
db.setProfilingLevel(1, 500)

这个设置会影响所有数据库，也可以在配置文件中设置：

|
operationProfiling:
  slowOpThresholdMs: 500

日志轮转管理

日志文件会不断增长，需要定期轮转以避免占用过多磁盘空间，可以使用logrotate工具：

|
// 手动轮转日志
db.adminCommand({"logRotate": 1})

推荐设置cron任务自动轮转，每天凌晨1点轮转日志：

|
0 1 * * * logrotate /etc/logrotate.d/mongodb

对于高并发、大数据量的生产环境，建议将日志文件存放至独立磁盘，以规避因日志写入造成的数据磁盘I/O竞争，从而提升整体系统性能与稳定性：

|
systemLog:
  destination: file
  path: "/data/logs/mongodb/mongod.log"
  logAppend: true

或者使用日志轮转工具如logrotate，配置如下：

|
/var/log/mongodb/*.log {
    daily
    rotate 30
    compress
    delaycompress
    missingok
    notifempty
    create 644 mongodb mongodb
    postrotate
        kill -SIGUSR1 $(cat /var/run/mongodb/mongod.pid)
    endscript
}

除了标准日志，MongoDB还提供性能监控功能，启用后会记录详细的性能指标：

|
// 启用性能监控
db.adminCommand({"setParameter": 1, "diagnosticDataCollectionEnabled": true})

这会生成包含系统性能数据的日志，帮助分析CPU、内存和磁盘使用情况，比如：

|
{
  "cpu": {
    "user": 100,
    "system": 50
  }
  "memory": {
    "used": 1024,
    "total": 4096
  },
  "disk": {
    "used": 1024,
    "total": 4096
  }
}

通过合理配置和管理日志，我们可以确保及时发现和解决问题，维护MongoDB数据库的稳定运行。