[MongoDB小技巧28]庖丁解牛 MongoDB 配置：WiredTiger、复制集、安全——一篇顶一本书

一、配置文件基础认知与加载机制

1. 配置文件的作用与位置

MongoDB 配置文件（mongod.conf）是运行时配置mongod和mongos实例的首选方法。配置文件包含等效于命令行选项的设置，使用配置文件可以更轻松地管理选项，尤其是在大规模部署时。

不同安装方式下配置文件的默认位置：

核心要点：MongoDB 配置文件采用YAML 格式，不支持制表符缩进，必须使用空格。这一细节看似琐碎，却是最容易掉进去的坑——YAML 解析器对制表符的报错信息往往不够直观，排查起来极其痛苦。

2. 配置文件加载流程

3. 配置文件的层级覆盖规则

MongoDB 的配置参数遵循以下优先级（从高到低）：

• 命令行选项（--前缀）—— 最高优先级，主要用于测试和临时调试
• 配置文件（mongod.conf）—— 生产环境推荐方式
• 操作系统环境变量—— 最低优先级

实战建议：生产环境禁止混用配置文件和命令行参数来设置同一参数的不同值——这会导致不可预测的行为。统一使用配置文件，并在文件头部用注释记录修改历史，是大型团队协作的基本纪律。

二、系统日志模块（systemLog）

1. systemLog.destination——日志输出目标

配置示例：

systemLog:destination:filepath:"/var/log/mongodb/mongod.log"logAppend:truelogRotate:reopen

2. systemLog.logAppend——日志追加模式

• true：每次启动时追加到现有日志文件
• false：每次启动时覆盖现有日志文件

配错后果：设为false会导致每次重启丢失历史日志，故障根因分析时追悔莫及。生产环境必须设为true。

3. systemLog.logRotate——日志轮转策略

4. systemLog.verbosity——日志级别

• 默认值为0（仅记录信息级别及以上）
• 取值范围：0（最少）到5（最详细）
• 生产环境保持0，排查问题时临时提升至1或2，切忌长期高 verbosity 运行——日志量会指数级增长，磁盘 IO 和 CPU 都会被拖垮。

5. 慢查询日志相关参数（operationProfiling）

operationProfiling:mode:slowOp# off / slowOp / allslowOpThresholdMs:100slowOpSampleRate:1.0

• mode: slowOp：仅记录超过阈值的操作
• slowOpThresholdMs：慢查询阈值（毫秒），默认 100ms
• slowOpSampleRate：采样率，默认 1.0（100%）

调优策略：

• OLTP 场景（高并发、低延迟）：阈值设为50-100ms
• OLAP 场景（复杂聚合、批处理）：阈值可放宽至500-1000ms
• 切忌盲目降低阈值——日志量过大会影响性能本身

三、存储引擎模块（storage）

1. storage.engine——存储引擎选择

MongoDB 从 3.2 版本起默认使用WiredTiger存储引擎。除非有极端特殊的兼容性需求，永远不要修改此参数。

storage:engine:wiredTigerdbPath:/var/lib/mongo

2. storage.dbPath——数据目录

数据文件的存储路径。关键注意事项：

• 目录必须对mongod用户有读写权限
• 建议挂载在独立的 SSD 磁盘上，与操作系统和日志分离
• 目录所在文件系统强烈建议使用 XFS（EXT4 在极高并发下可能有性能问题）

3. storage.directoryPerDB——每个数据库独立目录

• false（默认）：所有数据文件存放在dbPath根目录
• true：每个数据库拥有独立子目录

适用场景：需要按数据库进行存储隔离或迁移时启用。但要注意：启用后无法回退，需在初始化集群前决策。

4. storage.journal——预写日志（WAL）

storage:journal:enabled:truecommitIntervalMs:100

• enabled: true：启用 WAL，确保数据库在崩溃后能恢复
• 生产环境必须启用——关闭 journal 意味着丢失最新写入的风险
• commitIntervalMs：日志提交间隔，默认 100ms。调大可提升写入性能但增加崩溃丢失数据的窗口

5. WiredTiger 引擎核心参数（重中之重）

storage.wiredTiger.engineConfig.cacheSizeGB

这是MongoDB 性能调优最关键的参数，没有之一。

• 默认值：系统总内存的50% - 1GB
• 含义：限制 WiredTiger 内部缓存的大小
• 取值范围：建议设置为系统总内存的50%~70%

为什么是这个值？

许多人误以为“缓存越大越好”，盲目将cacheSizeGB设为 80% 甚至 90%，结果触发 OOM（Out of Memory）导致进程被 Kill。原因在于：

1. WiredTiger 缓存只是 MongoDB 内存占用的一部分
2. 还需要预留内存给：OS Page Cache、连接线程栈、排序/聚合操作的临时内存、索引构建内存
3. 操作系统本身也需要内存来管理文件系统缓存

不同场景的配置策略：

storage.wiredTiger.engineConfig.journalCompressor

日志压缩算法，可选值：snappy（默认）、zlib、none。

• snappy：压缩率与性能的平衡之选
• zlib：更高压缩率，但 CPU 开销更大
• 生产环境保持snappy即可

storage.wiredTiger.collectionConfig.blockCompressor

集合数据压缩算法，可选值：snappy（默认）、zlib、zstd、none。

• zstd：MongoDB 4.2+ 支持，压缩率优于 snappy，速度接近
• 建议：新集群评估使用zstd，可节省 15%-25% 存储空间

storage.wiredTiger.indexConfig.prefixCompression

索引前缀压缩，默认true。启用后对索引的前缀进行压缩，可显著减少索引占用的内存和磁盘空间，但会增加少量 CPU 开销。建议保持默认开启。

6. 并发控制参数（MongoDB 7.0+ 重要变更）

从 MongoDB 7.0 开始，引擎采用动态并发算法来调整读写票证（tickets）的最大数量：

• 读取票证最大不超过128
• 写入票证最大不超过128
• 单个节点内读写票证最大值始终相等

setParameter:storageEngineConcurrentReadTransactions:128storageEngineConcurrentWriteTransactions:128

注意：动态算法在 7.0 中初始基线较低，升级后可能观察到票证使用量大幅下降——这是预期行为，不是性能问题。只有在极端高并发场景下才需要手动调整这两个参数。

四、网络连接模块（net）

1. net.port——监听端口

net:port:27017bindIp:0.0.0.0bindIpAll:true

默认端口 27017。安全铁律：

• 生产环境绝对不要将bindIp设为0.0.0.0而不配置防火墙——这是 MongoDB 被勒索攻击的头号原因
• 正确做法：bindIp: 127.0.0.1,<内网IP>，仅监听内网

2. net.maxIncomingConnections——最大并发连接数

• 默认值：65536
• 含义：mongod可接受的最大并发连接数
• 调优建议：
  • 应用服务器连接池大小 × 应用服务器数量 = 所需连接数
  • 设置过小会导致连接拒绝，设置过大可能导致文件描述符耗尽
  • 需同时调整操作系统ulimit -n（文件描述符限制）

3. net.compression——网络传输压缩

net:compression:compressors:snappy,zstd,zlib

• 默认：snappy,zstd,zlib（按优先级协商）
• 压缩可减少网络传输量，但增加 CPU 开销
• 内网高带宽低延迟场景可考虑禁用，公网或跨机房场景强烈建议开启

4. net.serviceExecutor——服务执行器

• synchronous（默认）：同步模式，每个连接一个线程
• adaptive：自适应模式，根据负载动态调整线程池

适用场景：高并发（>5000 连接）场景下，adaptive模式可减少线程上下文切换开销。但要注意：adaptive模式在 MongoDB 4.0+ 引入，部分早期版本可能存在稳定性问题。

五、安全与认证模块（security）

1. security.authorization——访问控制

security:authorization:enabledkeyFile:/path/to/keyfile

• enabled：启用基于角色的访问控制（RBAC）
• 生产环境必须启用——未启用时任何人都可通过默认端口无密码访问

2. security.keyFile——副本集内部认证

副本集成员之间进行身份验证的共享密钥文件路径。关键要求：

• 文件内容必须是 6 到 1024 个字符的 Base64 字符串
• 文件权限必须为600（仅所有者可读写）
• 所有副本集成员必须使用相同的 keyFile

3. security.transport——TLS/SSL 配置

security:transport:mode:requireTLScertificateKeyFile:/path/to/server.pemCAFile:/path/to/ca.pem

4. security.authenticationMechanisms——认证机制

security:authenticationMechanisms:SCRAM-SHA-256

从 MongoDB 7.0 起，可指定的认证机制包括SCRAM-SHA-1、SCRAM-SHA-256、PLAIN等。推荐使用SCRAM-SHA-256，安全性更高。

六、副本集模块（replication）

1. replication.oplogSizeMB——Oplog 大小

这是副本集配置中最容易被低估的参数。

• 默认值：可用磁盘空间的5%（最小 990MB，最大 50GB）
• 含义：操作日志（oplog）的最大容量，用于副本集同步

为什么默认 5% 往往不够？

默认 5% 的 oplog 大小在写密集场景下可能只保留几小时甚至几十分钟的日志。一旦从节点宕机超过这个窗口，就必须全量重同步——对于 TB 级数据，这意味着数天不可用。

生产环境最佳实践：

• 推荐配置：oplog 窗口至少覆盖72 小时
• 估算公式：oplog 窗口（小时）≈ oplogSizeMB / (平均写入速率 MB/s × 3600)
• 金融、电商等核心系统：建议72-120 小时窗口
• 配置方法：
  • 初始配置：在mongod.conf中设置replication.oplogSizeMB
  • 运行时调整：使用replSetResizeOplog命令

replication:oplogSizeMB:20480# 20GB，根据实际写入速率评估replSetName:rs0

2. replication.replSetName——副本集名称

所有副本集成员必须使用完全相同的replSetName。一旦设置，不可更改（除非重建副本集）。

3. replication.enableMajorityReadConcern——多数读关注

• 默认：true
• 设为false可提升部分场景下的性能，但会牺牲读的因果一致性保证
• 谨慎修改：仅在彻底理解一致性模型后才考虑调整

七、分片集群专属参数（sharding）

1. sharding.clusterRole——节点角色

配置服务器专属：

sharding:clusterRole:configsvr

分片节点专属：

sharding:clusterRole:shardsvr

2. sharding.archiveMovedChunks——归档已迁移数据块

• 默认：false
• 设为true可在数据块迁移后归档而非立即删除，便于问题排查
• 生产环境建议保持false，避免磁盘空间浪费

3. 分片集群的 balance 相关参数（setParameter）

setParameter:balancerMigrationsThrottlingMs:100balancerMaxChunksToMove:10

八、性能分析器与诊断（operationProfiling）

operationProfiling:mode:slowOpslowOpThresholdMs:100slowOpSampleRate:1.0filter:'{ "op": "query", "ns": "test.*" }'

• filter：对哪些操作进行性能分析，支持 JSON 过滤表达式
• 生产环境建议：mode: slowOp+ 合理的阈值，切忌使用mode: all——会记录每一个操作，对性能有显著影响

九、核心参数速查对照表

十、单点（Standalone）配置文件

# ============================================================# MongoDB 单点（Standalone）生产配置文件# 版本：MongoDB 7.0 / 8.0 LTS# 适用环境：开发、测试或非核心生产（无高可用能力）# ============================================================# ---------- 系统日志模块 ----------# 日志输出目标：file 表示写入文件；syslog 表示系统日志；不设则输出到 stdoutsystemLog:destination:file# 日志文件的绝对路径，需确保 mongod 用户有写权限path:"/var/log/mongodb/mongod.log"# 是否追加到现有日志文件：true 为追加（生产推荐），false 为每次启动覆盖logAppend:true# 日志轮转策略：reopen 表示通过命令触发轮转，rename 表示自动重命名logRotate:reopen# 日志详细程度：0（默认）最少，5 最详细；生产环境保持 0，调试时临时调高verbosity:0# ---------- 进程管理 ----------# 是否以守护进程（fork）方式运行：true 为后台运行，false 为前台（容器环境常用 false）processManagement:fork:true# ---------- 网络模块 ----------net:# 监听端口，默认 27017port:27017# 绑定 IP 地址（逗号分隔）：建议仅绑定本地回环和内网 IP，严禁绑定 0.0.0.0（除非有防火墙）bindIp:127.0.0.1,192.168.1.100# 最大并发连接数，默认 65536；需同时调整操作系统 ulimit -nmaxIncomingConnections:65536# ---------- 存储引擎模块 ----------storage:# 数据文件存放目录，需确保 mongod 用户有读写权限dbPath:"/var/lib/mongo"# 存储引擎：固定使用 wiredTiger（MongoDB 3.2+ 默认）engine:wiredTiger# 预写日志（WAL）配置journal:# 是否启用 journal：生产环境必须 true，保证崩溃恢复能力enabled:true# 日志提交间隔（毫秒），默认 100；调大可提高写入性能但增加崩溃丢失数据的窗口commitIntervalMs:100# WiredTiger 引擎专用配置wiredTiger:# 引擎全局配置engineConfig:# WiredTiger 内部缓存大小（GB），建议设为物理内存的 50%~70%cacheSizeGB:6# 日志压缩算法：snappy（默认）、zlib、none；生产推荐 snappyjournalCompressor:snappy# 集合（表）级别的配置collectionConfig:# 数据块压缩算法：snappy（默认）、zstd（4.2+ 支持，压缩率更高）、zlib、noneblockCompressor:zstd# 索引配置indexConfig:# 是否启用索引前缀压缩：true 可减少内存和磁盘占用，推荐保持默认prefixCompression:true# ---------- 性能分析器 ----------operationProfiling:# 分析模式：off（关闭）、slowOp（仅记录慢查询，生产推荐）、all（记录所有操作，慎用）mode:slowOp# 慢查询阈值（毫秒），默认 100；OLTP 场景建议 50~100，OLAP 可放宽slowOpThresholdMs:100# 慢查询采样率，取值范围 0~1，默认 1.0（100% 记录）slowOpSampleRate:1.0# ---------- 安全模块 ----------security:# 是否启用基于角色的访问控制（RBAC）：生产环境必须 enabled（否则无密码可连接）authorization:enabled# ---------- 高级参数（setParameter） ----------setParameter:# 是否允许本地回环（127.0.0.1）绕过认证：false 表示即使本地也要认证（生产建议关闭）enableLocalhostAuthBypass:false

十一、副本集（Replica Set）配置文件

# ============================================================# MongoDB 副本集（Replica Set）生产配置文件# 版本：MongoDB 7.0 / 8.0 LTS# 副本集名称：rs0（所有节点必须一致）# 适用节点：Primary、Secondary、Arbiter（通用）# ============================================================# ---------- 系统日志模块 ----------systemLog:# 日志输出目标：file 表示写入文件destination:file# 日志文件路径，确保 mongod 用户有写权限path:"/var/log/mongodb/mongod.log"# 追加模式（生产必须 true，保留历史日志）logAppend:true# 轮转策略：reopen 通过命令触发，rename 自动重命名logRotate:reopen# 日志详细程度：0 最少，5 最详细；生产保持 0verbosity:0# ---------- 进程管理 ----------processManagement:# 是否以守护进程方式运行：true 为后台运行fork:true# ---------- 网络模块 ----------net:# 监听端口port:27017# 绑定 IP：127.0.0.1 和本节点实际内网 IP（请替换 <节点内网IP>）bindIp:127.0.0.1,<节点内网IP># 最大并发连接数，默认 65536maxIncomingConnections:65536# ---------- 存储引擎模块 ----------storage:# 数据目录dbPath:"/var/lib/mongo"# 存储引擎engine:wiredTiger# WAL 配置journal:enabled:truecommitIntervalMs:100# WiredTiger 配置wiredTiger:engineConfig:# 缓存大小（GB）：建议物理内存的 50%~70%cacheSizeGB:6# 日志压缩算法journalCompressor:snappycollectionConfig:# 集合压缩算法：zstd 压缩率更高blockCompressor:zstdindexConfig:# 索引前缀压缩prefixCompression:true# ---------- 性能分析器 ----------operationProfiling:mode:slowOpslowOpThresholdMs:100slowOpSampleRate:1.0# ---------- 副本集模块（核心差异） ----------replication:# 副本集名称：所有成员必须完全相同，一旦设定不可更改（除非重建）replSetName:rs0# Oplog 大小（MB）：生产环境建议根据写入速率计算，确保覆盖 72 小时窗口# 示例中设为 20 GB（20480 MB），请根据实际负载调整oplogSizeMB:20480# 是否启用“多数读关注”：默认 true，保证因果一致性，通常不建议修改enableMajorityReadConcern:true# ---------- 安全模块 ----------security:# 启用 RBACauthorization:enabled# 副本集内部认证密钥文件路径# 要求：所有节点使用相同文件，文件内容为 6~1024 字符的 Base64 字符串，权限 600keyFile:"/etc/mongo-keyfile"# ---------- 高级参数 ----------setParameter:# 禁止本地回环绕过认证enableLocalhostAuthBypass:false

十二、高频面试题精析

面试题 1：WiredTiger 的 cacheSizeGB 设得越大越好吗？为什么？

答案要点：

不是。这是一个常见的认知误区。

底层原理：WiredTiger 使用两级缓存架构——WiredTiger 内部缓存 + 操作系统页缓存（Page Cache）。WiredTiger 缓存存储的是未压缩的数据页和索引页，而 OS Page Cache 存储的是磁盘上的数据页副本。两者是互补而非替代关系。

为什么不能设太大：

1. 设得过大（如 90% 内存）会导致操作系统没有足够内存做 Page Cache，反而增加磁盘 I/O
2. MongoDB 还需要内存用于：连接线程栈（每个连接约 1MB）、排序和聚合操作的临时内存、索引构建内存
3. 内存耗尽会触发 OOM Killer，直接杀死 mongod 进程

最佳实践：控制在50%-70%之间，具体取决于工作负载类型。OLTP 偏向 60%-70%，OLAP 偏向 40%-50%。

面试题 2：某副本集从节点宕机 6 小时后恢复，发现无法同步，应该怎么处理？如何防止这种情况？

答案要点：

根因：oplog 窗口不足以覆盖 6 小时的宕机时间。从节点的 oplog 与主节点差距过大，主节点的 oplog 中对应的条目已被轮转覆盖。

恢复方案：

1. 全量重同步（最直接）：清空从节点数据目录，重新执行初始同步
2. 从备份恢复：如果有物理备份或 mongodump，可先恢复再追赶

预防措施：

1. 合理设置 oplogSizeMB：生产环境建议 oplog 窗口覆盖72 小时
2. 监控 oplog 窗口：定期检查rs.printReplicationInfo()输出的 oplog 时间窗口
3. 动态调整：使用replSetResizeOplog命令在线扩容，无需重启
4. 估算公式：oplog 窗口 ≈ oplogSizeMB / (写入速率 MB/s)

面试题 3：生产环境的 bindIp 应该怎么配置？为什么？

答案要点：

安全第一原则：bindIp决定了 mongod 监听哪些网络接口。

错误做法：

• bindIp: 0.0.0.0且无防火墙 → 任何人都可连接，这是 MongoDB 勒索攻击的头号原因
• bindIp: 127.0.0.1且应用在另一台机器 → 应用无法连接

正确做法：

net:bindIp:127.0.0.1,192.168.1.100# 本地 + 内网IP# 或bindIpAll:true# 监听所有接口，但配合防火墙

最佳实践组合：

1. bindIp仅绑定内网 IP，不绑定公网
2. 配合安全组/防火墙限制访问来源 IP
3. 启用security.authorization: enabled强制认证
4. 关键业务启用TLS/SSL加密传输

面试题 4：MongoDB 7.0 中并发控制机制发生了什么变化？升级后观察到票证使用量下降是问题吗？

答案要点：

变化：MongoDB 7.0 引入了动态并发存储引擎事务算法，用于动态调整读写票证（tickets）的最大数量。

机制：

• 读写票证最大值不超过128个
• 单个节点内读写票证最大值始终相等
• 动态算法会优化集群过载期间的数据库吞吐量

升级后票证使用量下降——是正常现象吗？
是的，这是预期行为。文档明确指出：“动态算法会降低总体票证使用量，因为该算法一开始的可用票证基线数量要低得多”。这不是性能问题，而是算法设计使然。

如需手动干预：可通过setParameter设置storageEngineConcurrentReadTransactions和storageEngineConcurrentWriteTransactions来指定最大值。

面试题 5：设计一个高可用 MongoDB 生产集群的配置文件，你会重点关注哪些参数？给出你的配置清单思路。

答案要点：

这是一道综合性架构题，考察的是系统性思维。

核心配置清单思路：

架构层面的额外考量：

• 使用SSD而非 HDD
• 数据目录、日志目录、oplog分盘挂载，避免 IO 争用
• 配置文件纳入版本控制（Git），所有变更需 Code Review
• 配合监控告警（Prometheus + MongoDB Exporter），监控 oplog 窗口、缓存命中率、连接数等核心指标