很多同学学完分布式缓存专题的第一篇对MongoDB能做什么已经心里有数了它介于Redis和传统关系型数据库之间既能像缓存一样扛住高吞吐读写又能提供查询、索引、过期、副本集这些正经数据层能力。但真到了实操阶段不少人会愣在第一步——服务装好了mongosh也能连上接下来呢配置文件里那么多参数是干什么的哪些命令是高频操作副本集、分片这些和单机最不一样的地方命令该怎么下这篇文章没有废话直接围绕“常用命令及配置”这条线把从单机跑到分布式形态落地要用到的东西全部串一遍。系列第一篇讲的是定位与选型这篇就是纯粹的动手篇适合已经理解MongoDB缓存定位、准备上手搭建和排查问题的开发者。1. 配置文件里的每个关键块到底在管什么MongoDB的启动参数有三个来源命令行参数、环境变量、配置文件。实际生产环境里没有人会把一堆参数敲在命令行上都是用YAML格式的配置文件启动所以先把配置文件读透是第一步。下面这份配置是从一个真实的模拟项目里摘出来的不算最复杂但覆盖了生产环境绝大部分必配项# mongod.conf storage: dbPath: /data/mongodb wiredTiger: engineConfig: cacheSizeGB: 8 systemLog: destination: file path: /var/log/mongodb/mongod.log logAppend: true net: port: 27017 bindIp: 127.0.0.1,192.168.1.10,10.0.0.2 replication: replSetName: rs_core sharding: clusterRole: shardsvr security: authorization: enabled setParameter: enableLocalhostAuthBypass: false几个关键点逐个说。storage.dbPath和cacheSizeGB是首先要确认的。dbPath就是数据文件目录磁盘不足会导致实例直接拒绝写入建议单独挂数据盘。cacheSizeGB这个参数很多人忽略WiredTiger引擎默认情况下会占用“物理内存的一半减1GB”最保守也有256MB。在一个混布了Redis、应用进程、监控组件的机器上这个默认值很可能导致MongoDB把内存吃得过狠然后整个机器开始疯狂swap。所以要么显式设置要么确保这台机器是专职给MongoDB用的。8GB是比较常见的起步值具体按你的工作集大小来定工作集放不下时会频繁读盘这个后面讲慢查询的时候会再提。systemLog配置里destination、path、logAppend这三个是黄金组合。生产环境必须写文件必须追加而不是覆盖否则重启一次日志就没了排查问题直接抓瞎。logrotate可以交给系统层做这里不展开。net.bindIp这个参数生产环境要特别小心。默认只监听127.0.0.1只在本机可连如果不小心配成了0.0.0.0又没开认证那等于把数据库裸奔在内网甚至公网上扫描工具一抓一个准。正规做法是显式列出需要访问的网卡IP比如上例里同时监听了本机、内网网段和应用网段的IP。注意bindIp是逗号分隔不能有空格。replication.replSetName和sharding.clusterRole这两个是“分布式形态”的开关。只要配了replSetName实例启动后就会进入副本集成员的角色需要后续用rs.initiate()初始化sharding.clusterRole如果是shardsvr那这个实例是分片集群里的一个分片节点不能单机独立使用。配置了clusterRole之后再想改回来很麻烦所以上线之前就要想清楚这台机器是干什么的。security.authorization和enableLocalhostAuthBypass这对组合容易踩坑。官方默认配置下即使开了authorization本地通过localhost连接时仍然有一个认证旁路——也就是本机进程可以不带账号密码直接连上来这在很多安全审计里是个隐患。生产环境建议显式把enableLocalhostAuthBypass设为false彻底关掉旁路。但注意如果你还没创建任何用户就把authorization开了又关了本机旁路那你会把自己锁在门外只能进单用户模式重启、临时改配置才能救回来。所以初始化顺序应该是先以无认证模式启动创建admin用户再开启authorization重启。1.1 启动参数优先级和常用命令行覆盖配置文件不是唯一入口命令行参数和环境变量仍然会覆盖或补充配置文件里的值。三者的优先级从上到下是命令行参数环境变量配置文件这意味着你用命令行指定了一个和配置文件冲突的port实际生效的是命令行。这个优先级搞反了会出现“我改了配置文件端口怎么不生效”的灵异事件。排查时第一件事就是看启动命令和systemd unit文件里有没有残留参数。从运维角度启动阶段常用的命令行参数并不多这里记下几个高频的# 指定配置启动 mongod -f /etc/mongod.conf # 指定数据目录、端口、日志临时起一个纯测试实例不碰生产配置 mongod --dbpath /tmp/mongo-test --port 27018 --logpath /tmp/mongo-test.log --fork # 只做配置校验不真正启动 mongod -f /etc/mongod.conf --configExpand none --configCheck--fork这个参数实测很实用但不建议在systemd托管模式下用systemd自己会管理后台进程你再加fork会出现pid文件冲突。测试环境图省事可以用生产环境交给systemd或容器编排更稳。1.2 配置完成后如何快速验证配置改完不是重启就完事了我习惯按顺序跑一遍验证缺一不可mongod -f /etc/mongod.conf --configCheck先看语法。启动后看日志尾部有没有ready to accept connections有这句话才算真的起来了。mongosh --eval db.runCommand({ping: 1})验证可连接。mongosh --eval rs.status()或sh.status()验证分布式形态是否生效。这个验证链路很短但能筛掉八成配置错误。比如日志都显示ready了但rs.status()报错那大概率是replSetName没配或者没初始化。2. 确定性读取readPreference与readConcern的搭配原则单机模式下你不需要关心这篇文章的这一节但一旦副本集建立起来读写就有了主从之分。这也是分布式缓存专题里最容易翻车的地方很多人以为MongoDB副本集像MySQL一样主从同步之后随便读实际上读哪个节点、读到的数据是否“多数派确认过”是由一组参数决定的而且不同参数组合的语义差别巨大。readPreference决定了“往哪读”readConcern决定了“读多新”。前者是路由层面的后者是隔离层面的两者要配合着看。readPreference有五个取值模式行为适合场景primary只读主节点默认值强一致读场景primaryPreferred优先主节点主不可用才读从节点主节点故障时仍可读secondary只读从节点数据分析、离线任务secondaryPreferred优先从节点从不可用才读主节点缓存查询、报表类读多写少nearest按网络延迟就近读多机房部署缓存场景里最常见的做法是写走主、读走secondaryPreferred或nearest把读流量从主节点上卸掉主节点专心处理写入。但要注意从节点上有同步延迟你刚写入的数据可能读不到。这正是缓存一致性问题的源头MongoDB不是Redis那种单线程全内存模型它落在从节点上的数据要经过oplog回放延迟可能在几十毫秒到秒级之间浮动。readConcern的常用取值local、available、majority、linearizable、snapshot。前两个基本等价差异只在分片场景是否检查orphan document日常可以不用细化区分。majority意味着读到的数据是多数节点确认过的、不会因为回滚而消失linearizable最强要求读操作前面的写入已被多数节点持久化并且读操作本身也会被多数节点确认代价是延迟显著上升。实操中我见过一个很典型的配置组合mongodb://user:passhost1:27017,host2:27017/?replicaSetrs_corereadPreferencesecondaryPreferredreadConcernLevelmajority这个组合的问题是secondaryPreferredmajority会组合出一个不太理想的行为优先从节点读但要等这个数据在多数节点确认。结果就是读请求往往要等待从节点追平主节点日志反而比直接读主节点更慢。如果业务对一致性容忍度很高干脆用readPreferencesecondaryPreferredreadConcernLevellocal这样性能最好如果业务要求严格一致就老老实实用primary读主。2.1 写关注不亚于读偏好的一致性开关写了半天读写入侧的一致性由写关注writeConcern控制。写关注的核心参数是w和jw: 0不等待确认丢消息都不知道。w: 1默认值主节点写入成功即返回。w: majority写入要复制到多数派节点并持久化后才返回。缓存场景有个心理预期“缓存丢了可以重建”所以大部分缓存性质的数据用w:1就够。但如果是订单、账户余额这类数据哪怕只是临时放在MongoDB里也要w:majority否则主节点宕机时你会看到数据回滚——客户端返回成功但最终没有落盘。这个坑一旦出现数据对账的工作量会大到让人怀疑人生。开发者在代码里设置写关注的姿势也很重要。不要在每一条语句里写{ w: majority }这会让新手漏写某条、老手看花眼。正确做法是在连接串或配置文件里统一指定mongodb://localhost:27017/?replicaSetrs_corewmajority驱动层统一兜底业务代码里就不需要处处关心写关注。这样既保证了默认数据安全又保留了逐条覆盖的灵活性。3. 高频命令参考连上之后真正常用的那些操作mongosh现在是官方默认的Shell早期那种mongo shell已经下线了。打开mongosh之后的常用操作分几类基础导航、CRUD、索引、聚合、执行计划诊断。这一节不写API文档式的罗列只挑缓存场景里真正高频的部分。3.1 导航与基础增删改// 看有哪些库 show dbs // 切换到业务库MongoDB里use一个不存在的库也没关系写第一条数据时库会自动创建 use cache_db // 看当前库有哪些集合 show collections // 插入单条 db.sessions.insertOne({ _id: sess_1001, userId: u_8823, data: { cart: [123, 456] }, expireAt: new Date(Date.now() 3600 * 1000) }) // 批量插入性能远好于循环单条插入 db.sessions.insertMany([ { _id: sess_1002, userId: u_8824 }, { _id: sess_1003, userId: u_8825 } ])_cache_db这个库名我在模拟项目中见过不少次正式项目里不要这样命名。_id是唯一的不传时会自动生成ObjectId但既然做缓存建议业务主键自己生成传进去这样后续做幂等、对账、去重都方便。比如上面例子里的sess_1001就是典型的业务主键。更新操作有三个易混的方法updateOne、updateMany、replaceOne。updateOne和updateMany只更新指定字段replaceOne是整个文档替换。还有个细节MongoDB 4.0之后update默认只更新单条想更新多条必须显式updateMany这跟旧版本行为不一样很多人在这里踩过坑。缓存场景最常用的更新操作符是$inc和$set// 给某个缓存计数加1原子操作并发安全 db.counters.updateOne( { _id: daily:20250101 }, { $inc: { pv: 1 } } ) // 只更新某些字段不重建整个文档 db.sessions.updateOne( { _id: sess_1001 }, { $set: { data.cart: [789] }, $inc: { version: 1 } } )删除操作对应deleteOne和deleteManyTTL过期删除由MongoDB后台线程自动完成不需要业务代码显式执行deleteMany({ expireAt: { $lt: new Date() } })——除非你想手动清脏数据。3.2 查询条件与索引匹配查询条件的写法比较直观但有几个操作符很容易被误用。$in对应SQL里的IN$nin是NOT IN$regex可以做模糊匹配但你要知道它在索引上的行为前缀匹配比如^abc能用索引中间或后缀匹配通常会全面扫描。缓存中按键查询大部分时候是等值匹配写法就是{ _id: sess_1001 }比较简单。真正容易出问题的组合是排序和范围查询。MongoDB的复合索引匹配有一套“最左前缀”规则和MySQL的联合索引类似。我们建了{ userId: 1, createTime: -1 }这个索引之后以下查询能用上// 等值userId 排序createTime完美命中 db.sessions.find({ userId: u_8823 }).sort({ createTime: -1 }) // 范围查询createTime也能用但排序字段不能跳过前面的等值字段 db.sessions.find({ userId: u_8823, createTime: { $gt: ISODate(2025-01-01) } }).sort({ createTime: -1 })以下查询用不上或者只能用一半// 跳过userId直接按createTime排序复合索引用不上退化成全集合排序 db.sessions.find({}).sort({ createTime: -1 })用explain(executionStats)一下就能验证db.sessions.find({ userId: u_8823 }).sort({ createTime: -1 }).explain(executionStats)重点看返回结果里的winningPlan和executionStats。如果stage是COLLSCAN说明没走索引全集合扫描数据量大时性能感人如果是IXSCAN走到了FETCHthen正常。还有一个关键指标是totalDocsExamined和totalKeysExamined理想情况下docsExamined应该等于实际返回条数。3.3 聚合管道的日常用法聚合管道aggregation pipeline比find查询灵活得多适合做轻量级的缓存统计和离线分析。最常用的阶段就是$match、$group、$sort、$project、$unwind、$lookup这几个。管道里阶段的顺序直接决定性能原则很朴素能用索引过滤的字段放在最前面的$match里而不是等所有数据都load进来之后再做条件过滤。db.orders.aggregate([ // 第一个阶段用时间范围缩小数据量这个条件应该命中索引 { $match: { createTime: { $gte: ISODate(2025-01-01), $lt: ISODate(2025-02-01) } } }, // 按用户维度做分组统计 { $group: { _id: $userId, totalAmount: { $sum: $amount }, orderCount: { $sum: 1 } } }, // 金额大的排前面 { $sort: { totalAmount: -1 } }, // 控制返回字段别把整条文档都拖出来 { $project: { _id: 1, totalAmount: 1, orderCount: 1 } }, // 限制只取前100 { $limit: 100 } ])要注意$group默认不排序如果后续要按totalAmount排序排序必须在$group之后的$sort阶段显式指定。还有一个性能大坑$lookup做关联时如果外表foreign collection的关联字段没有索引性能会很差因为每一条左表记录都会触发一次右表查询。缓存场景里能用冗余字段解决的尽量别用$lookup。4. 副本集与分片和单机最不一样的分布式命令这一节是“分布式专题”的分量所在。单机MongoDB用mongod直接启动而分布式形态下需要部署副本集甚至分片集群命令和使用方式完全不同。很多人的困惑恰恰在这里单机命令都熟了一上副本集各种报错。4.1 副本集初始化与增删节点副本集最少三节点或一主一从一仲裁仲裁者arbiter不存数据只参与选举投票。初始化命令如下// 在其中一个节点上执行 rs.initiate({ _id: rs_core, members: [ { _id: 0, host: 10.0.0.11:27017 }, { _id: 1, host: 10.0.0.12:27017 }, { _id: 2, host: 10.0.0.13:27017, arbiterOnly: true } ] }) // 查看复制集状态重点是members里的stateStrPRIMARY/SECONDARY/ARBITER才是正常 rs.status() // 后续扩容加入新节点 rs.add(10.0.0.14:27017) // 移除节点 rs.remove(10.0.0.14:27017) // 主动让主节点退位做选举 rs.stepDown(60)有几个细节值得注意。rs.initiate()里指定的host必须是其他节点能访问到的地址别填127.0.0.1否则集群里的节点之间没法互相通信。新增节点时如果数据量很大新节点会经历一个较长的initial sync过程期间rs.status()里它的stateStr可能是STARTUP或STARTUP2这是正常的等它变成SECONDARY才算同步完成。oplog是副本集的核心机制它记录的是所有写操作的日志从节点就是通过拉取并重放主节点的oplog来保持同步的。oplog的大小在初始化时就定了默认策略是磁盘可用空间的5%最小50MB最大50GB。如果你预计有大批量写入但又没显式设置oplog大小同步延迟可能会急剧上升。排查从节点追不上主节点时先看rs.status()里的optimes如果lastCommittedOpTime和appliedOpTime差得远说明从节点同步滞后了。4.2 分片集群的启动与建片命令分片集群的架构是mongos作为路由入口后面挂多个分片shard每个分片本身是一个副本集。搭建顺序不能乱先起config server它自己也是一个副本集再起各分片最后起mongos。config server启动时配置文件里要这样指定sharding: clusterRole: configsvr分片节点按前面第一份配置里的clusterRole: shardsvr启动。mongos用的配置文件则是sharding: configDB: rs_config/10.0.0.21:27019,10.0.0.22:27019,10.0.0.23:27019所有组件起来之后在mongos上初始化分片// 把分片节点加入集群 sh.addShard(rs_core/10.0.0.11:27017,10.0.0.12:27017,10.0.0.13:27017) // 启用某个库的分片能力 sh.enableSharding(cache_db) // 对集合进行分片片键是核心决策 sh.shardCollection(cache_db.sessions, { userId: 1 }, { unique: false }) // 查看分片状态 sh.status()分片键的选择是这门手艺里最重要的决策之一。选择分片键的核心指标是基数、分布均匀性、以及查询是否带得上。拿userId做片键是比较常见的做法因为访问模式通常按用户维度天然均匀带userId的查询可以直接路由到对应分片不会广播到所有分片。如果担心某个热点用户的的数据量过大或者写入集中在单一分片导致热点可以考虑hash分片sh.shardCollection(cache_db.sessions, { userId: hashed })hashed片键能保证写入均匀散列到各个分片但range查询就没那么友好了。cache场景通常也是点查多、范围查少所以不少模拟项目直接用hashed。具体选哪种要结合实际查询模式没有银弹。4.3 mongos、mongod与mongosh的使用边界分片集群里连的是mongos不是mongod。mongos本身不存储数据只是一个路由层它根据片键把请求转发到对应的分片。所以mongosh --host mongos_host --port 27017进去之后你看到的是集群的全局视图而直接连某个mongod你看到的是单个分片里的局部数据。这在排查数据不一致时是个大坑db.sessions.find()在mongos上查是全量连到某个shard上查就只查到了该分片的那一部分。如果你按分片键查路由是正确的如果不带分片键mongos会把请求广播到全部分片再做合并性能可想而知这也是分片键必须匹配业务查询模式的直接原因。5. 实战中的故障排查链路与常见根因这一节写的都是实操中反复出现的真实故障。做技术分享如果没有这些一手经验文章其实是有很大缺失的因为命令和配置谁都能查文档但“遇到的坑以及排查思路”只能在实战中积累。5.1 故障一客户端一直报“not primary”这个报错的完整说法通常是not primary and secondaryOkfalse或类似意思是当前节点不是主节点且客户端也没有声明可以读从节点。看命令是简单的但根因往往不在命令本身而在集群状态。我的排查链路是这样的先看这个报错是从哪个节点返回的。如果从节点返回not primary说明客户端把写请求发到了从节点——检查连接串里的readPreference是否配置了secondaryPreferred以及写操作是否被驱动显式指定了从节点路由。再看rs.status()确认当前集群是否有主节点。如果有主节点问题大概率在上一步如果整个集群没有主节点那就是选举出问题了。选举问题看三个地方每个节点是否都存活仲裁者能否被其他节点访问到各节点的priority是否一致导致没人能自动当选。曾经遇到过一次很隐蔽的情况三节点副本集其中一个节点挂掉剩下两个节点无法形成多数派整个集群变成只读。排查时发现复制集配置里三个节点的host都绑在各自机器的内网IP上但其中一台机器的防火墙没放通其他节点的27017端口。所以网络层面的连通性也是排查重点。用mongo --host 10.0.0.12 --port 27017手动连一次比看配置快得多。5.2 故障二查询突然从毫秒级变成秒级这个故障场景在缓存层出现时尤其打击业务因为缓存本来就是为了扛性能的。排查链路比较固定第一步确认慢查询定位// 开启慢查询日志超过300ms的操作记录到system.profile db.setProfilingLevel(1, { slowms: 300 }) // 查看最近慢日志 db.system.profile.find().sort({ ts: -1 }).limit(20)第二步用explain看执行计划重点确认是否走了索引。如果是COLLSCAN去检查有没有缺索引如果走了索引却还是慢看totalDocsExamined是不是远大于返回条数这种情况通常是索引字段的选择性太差了比如在只有两个取值的字段上建索引等于没建。第三步看WiredTiger引擎是否在疯狂读盘。如果cacheSizeGB太小数据工作集放不进内存MongoDB会不断从磁盘加载数据页整体性能断崖式下降。排查命令db.serverStatus().wiredTiger.cache看pages read from disk这个指标如果它在持续增长说明内存缓存严重不够要么加内存里的cacheSizeGB要么优化索引减少数据扫描量。5.3 故障三写入超时与锁等待MongoDB的锁机制不像关系型数据库那么显眼但在写并发大时也会出现WriteConflict。这个报错常见于事务和多文档更新原因是两个写操作修改了同一个文档。处理方式一般不是调参数而是改代码短一点的事务范围、避免热点文档的并发更新、批量更新改成小批次重试。连接池打满导致的写入超时也遇到过报错可能是connection pool exhausted。排查时看mongostat里的connections列如果已经到上限要么调高net.maxIncomingConnections要么从应用侧减小连接池大小。后者更常见很多应用框架默认的连接池参数在低并发业务里根本用不满但对写入密集型的缓存场景来说很容易占满。6. 生产环境治理认证、日志、备份、监控的底线配置最后这部分算是我个人的习惯总结。很多团队MongoDB装完能跑就开始写业务了认证没开、备份没配、慢查询没记录结果出问题只能抓瞎。缓存层虽然可以丢数据但也不能丢了之后没有线索去查。6.1 认证与权限的初始化顺序在开启authorization之前必须先创建至少一个管理员用户。官方推荐的做法是// 第一步以无认证模式启动mongod // 第二步进入mongosh切换到admin库 use admin // 第三步创建管理员用户 db.createUser({ user: ops_admin, pwd: S3curePassw0rd, roles: [ { role: root, db: admin } ] }) // 第四步退出在配置里开启security.authorization: enabled重启root角色只在初始化阶段用业务账后应该分配最小权限。比如这个服务只需要读写cache_db库那就建个只带readWrite角色的账号别动不动给root。角色细分这件事很多团队不重视但一旦账号泄露影响面差别很大。6.2 日志、备份与恢复的常规配置日志轮转不配的话一个高流量的缓存服务能把日志文件写到几十GB。系统层的logrotate按天切分比较省心MongoDB自身也有logRotate命令可以通过运维脚本定时触发。备份方面mongodump/mongorestore依然是通用的兜底方案# 全库备份指定认证账号 mongodump --host 10.0.0.11 --port 27017 --username backup_user --password xxx --authenticationDatabase admin --out /backup/mongo-20250101/ # 恢复数据 mongorestore --host 10.0.0.12 --port 27017 --username ops_admin --password yyy --authenticationDatabase admin /backup/mongo-20250101/mongodump是逻辑备份恢复速度和数据量强相关大数据量时慢得让人心慌。副本集环境下更推荐用文件系统快照或云盘快照做物理备份恢复速度快一个数量级。但至少要保证mongodump这条链路是通的因为它是所有环境都适用的通用方案。6.3 mongostat与慢日志的日常巡检最后推荐两个习惯性动作。mongostat是实时性能监控里的主力命令输出里重点看insert/query/update/delete这几列每秒钟的操作数以及faults列在正常情况下应该是0如果持续大于0说明内存不足在换页。慢日志不是出了慢查询才开应该常态化开着。db.setProfilingLevel(1, { slowms: 300 })是会话级的重启后会失效如果是常年跑的服务把operationProfiling.slowOpThresholdMs: 300写进配置文件更可靠。缓存查询理论上应该在几十毫秒内返回超过300ms的查询本身就值得每天看一眼日志这比等用户投诉之后再去翻日志要主动得多。我个人经验是所谓“能跑”和“好用”之间差的其实就是这些运维习惯。命令和配置都写在文档里区别只在于你是否在生产环境主动应用它们。MongoDB在分布式缓存这个位置上命令和配置的熟练度会直接决定你排查故障的速度和系统运行的稳定性。把本文这些命令跑一遍、把这些配置逐项过一遍你的环境才算是真正做好了上生产的准备。