1. 安装前的准备工作与版本选型思路1.1 为什么单机安装也需要认真规划很多朋友觉得MongoDB单机安装这事太简单了apt install mongodb敲完就算完事。但我在实际部署和后续运维中踩过不少坑才意识到安装这个环节的决策直接影响后面几个月的稳定性。比如版本选错导致驱动不兼容日志目录没规划好导致磁盘写满WiredTiger缓存配置给太多导致同机其他服务被挤爆。这些问题表面上跟“安装”没关系但根源都在安装那一刻的决策上。先明确一下这篇博文适用的场景开发环境快速搭建、小规模生产环境的单节点部署、学习研究用的本地实例。如果你要搭副本集或分片集群建议先读完这篇文章把单机部分吃透原理是共通的。我会以LinuxUbuntu 20.04/CentOS 7.x为主讲Windows环境单独开一节说明因为两者的坑完全不一样。1.2 MongoDB的版本选择到底在选什么打开MongoDB官网你会发现版本号一堆社区版、企业版还有6.0、7.0这样的主版本号。很多新手直接装最新版其实这个选择背后是有讲究的。版本选型主要看三个维度稳定性周期MongoDB奇数版本如5.1、6.1属于快速迭代版偶数版本如5.0、6.0、7.0是稳定版。生产环境务必选偶数稳定版开发环境如果你愿意尝鲜用奇数版也能学到新特性但遇到bug的概率会高一些。驱动兼容性这一点最容易被忽略。比如你在用C#的MongoDB.Driver 2.19以下的版本连接MongoDB 7.0会报认证协议不兼容或者游标超时的奇怪错误。我建议先确认你项目里驱动版本再去倒推MongoDB服务器版本。热门搜索词里那个“c# mongodb 集合 最大值”其实很多情况下就是驱动和服务器版本不匹配导致的文档大小限制或游标行为异常后面我会展开讲。操作系统的官方支持范围Ubuntu 22.04、Debian 11、RHEL 9这些都有对用的MongoDB版本仓库。如果你的系统太老比如CentOS 6官方早就不维护了只能用第三方编译包或者升级系统。这里我推荐一个保守而实用的组合生产环境用MongoDB 6.0.x目前维护期较长、生态兼容好、文档最全开发环境可以用7.0.x体验新特性比如可查询加密、更快的聚合管道。1.3 系统环境准备清单安装前先把环境检查做完省得装到一半发现缺依赖。需要确认的项目主要有这些操作系统版本cat /etc/os-release看一眼确认是64位系统x86_64或ARM64都行MongoDB对ARM支持也不错32位系统早就不支持了。磁盘空间MongoDB本体加依赖至少预留5GB以上空间但这是指安装空间。数据目录才是大头建议数据目录单独划分磁盘至少是预估数据量的2~3倍给未来的索引、oplog、日志留出余地。内存大小WiredTiger存储引擎默认会使用“物理内存的50%减去1GB”作为缓存上限。比如机器有16GB内存MongoDB默认吃7GB。如果你的机器总共只有2GB内存那默认配置很容易触发OOM。这个一定要在安装前想清楚。文件描述符限制ulimit -n查看建议至少设为64000。连接数一多文件描述符不够会直接导致连接失败或者查询卡住这在生产环境是一个经典排查点。关闭THP透明大页MongoDB官方强烈建议关闭Linux的透明大页否则可能引发性能问题。这个可以安装前做也可以装完后做后面我会给具体命令。防火墙端口MongoDB默认端口27017。如果是本地开发不涉及跨机器访问那随意。如果后续有远程访问需求防火墙要开这个端口同时要配置mongod.conf里的bindIp默认只绑127.0.0.1想远程访问必须显式配置这块后面细说。把上面这些逐项过一遍大概几分钟时间但能省掉你后面排查问题的很多精力。2. 安装方式对比与离线部署方案2.1 三种安装方式怎么选MongoDB单机安装主要有三种方式包管理器直接安装、下载二进制包手动部署、Docker容器化运行。我三种都用过说说各自的优缺点。包管理器安装apt/yum是最省事的官方维护了APT和YUM仓库装完还会自动配好systemd服务systemctl start mongod就能启动。缺点是版本更新你需要手动改仓库源而且安装路径是散装的配置在/etc/mongod.conf数据在/var/lib/mongodb日志在/var/log/mongodb后续想迁移数据目录会麻烦一点。二进制包手动部署是我个人最推荐的方式也是这篇博文的重点。它把一个完整目录下的mongodb-binaries解压到你指定的路径所有内容集中在一起数据目录、日志目录、配置文件全部由你自定义升级和迁移时特别灵活。当年我从包管理器方式切到二进制方式后再也没回去过。Docker方式在小规模测试环境非常舒服docker run -d -p 27017:27017 mongo:6.0一行搞定。但生产单机我一般不建议因为数据卷管理、容器重启策略、日志收集都要额外处理复杂度并没有减少多少反而让故障排查多了一层。如果你用Docker至少要把数据目录挂载到宿主机别把数据留在容器可写层里容器一删就全没了。2.2 二进制包部署完整实操这里给出我实测过的完整操作过程以MongoDB 6.0.14、Ubuntu 20.04为例CentOS系统的差异我会在括号里标注。先去MongoDB官网下载页找到对应版本。官网的下载页默认给的是当前最新版历史版本要到版本归档页面去翻。需要注意官网下载时要求填一下基本信息实际直接拿直链下载就行用wget命令最方便。# 创建专门的部署用户非root运行MongoDB是安全底线 sudo useradd --system --no-create-home --shell /bin/false mongodb # 创建软件目录和数据目录 sudo mkdir -p /opt/mongodb sudo mkdir -p /data/mongodb/db sudo mkdir -p /data/mongodb/logs sudo chown -R mongodb:mongodb /opt/mongodb /data/mongodb # 下载二进制包以6.0.14为例Ubuntu 20.04 x86_64 wget https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-ubuntu2004-6.0.14.tgz # 解压并移动到目标目录 tar -zxvf mongodb-linux-x86_64-ubuntu2004-6.0.14.tgz sudo mv mongodb-linux-x86_64-ubuntu2004-6.0.14/* /opt/mongodb/解压后检查一下目录结构确保/opt/mongodb/bin下有mongod、mongos、mongo7.0之后的版本把mongo shell独立成了mongosh需要注意这些可执行文件。2.3 配置文件mongod.conf的编写要点二进制部署的核心是写好mongod.conf。MongoDB启动时可以用--config参数指定配置文件我强烈建议用配置文件而不是命令行参数因为可读性和后续维护性好太多。下面是我常用的一个单机配置模板# mongod.conf storage: dbPath: /data/mongodb/db wiredTiger: engineConfig: cacheSizeGB: 4 collectionConfig: blockCompressor: snappy systemLog: destination: file path: /data/mongodb/logs/mongod.log logAppend: true net: port: 27017 bindIp: 127.0.0.1 processManagement: fork: true pidFilePath: /data/mongodb/logs/mongod.pid security: authorization: enabled逐个解释关键参数的意思dbPath是数据存储目录这里指向了/data/mongodb/db。注意这个目录必须存在且有权限MongoDB不会自动创建某些版本会自动创建但依赖父目录存在。cacheSizeGB是WiredTiger存储引擎的缓存上限。我之前强调过这个值的重要性这里再细化一下建议设置为物理内存的40%~50%。比如16GB内存设置4~6GB。如果机器上还跑着其他服务则要减少如果MongoDB独占机器可以给到物理内存的50%。设置太小比如2GB以下大数据量查询的性能会明显下降。blockCompressor: snappy是集合数据的压缩算法。snappy压缩率适中、CPU消耗低是默认值。还有一个zstd选项压缩率更高但CPU开销也大低写入高存储压力的场景可以考虑。logAppend: true表示日志写入是追加模式不会重启覆盖这样重启前崩溃的日志还能追到。bindIp: 127.0.0.1只允许本机连接。这是安全的默认配置开发环境不需要改。如果要远程连接改成0.0.0.0或者具体IP但要同时启动认证否则裸奔在网络上非常危险。authorization: enabled启动认证这个建议从一开始就打开。很多人装完单机图省事不开认证结果数据库被勒索或者数据被清空网上搜一下案例太多了。把配置文件放在/opt/mongodb/mongod.conf然后就能用下面的命令启动了sudo -u mongodb /opt/mongodb/bin/mongod --config /opt/mongodb/mongod.conf启动后用ps aux | grep mongod查看进程是否在跑或者看日志文件tail -f /data/mongodb/logs/mongod.log的输出。日志里如果出现waiting for connections on port 27017就代表启动成功了。2.4 systemd服务配置二进制部署不会自动创建systemd服务需要手工写一个service文件这样才能用systemctl start mongod统一管理并且开机自启。在/etc/systemd/system/mongod.service里写入如下内容[Unit] DescriptionMongoDB Database Server Afternetwork.target [Service] Usermongodb Groupmongodb ExecStart/opt/mongodb/bin/mongod --config /opt/mongodb/mongod.conf PIDFile/data/mongodb/logs/mongod.pid LimitNOFILE64000 LimitNPROC64000 [Install] WantedBymulti-user.target几个关键点LimitNOFILE64000提升了进程能打开的文件数上限。虽然mongod.conf里也能配但systemd层面限制如果不够进程内怎么配置都没用。这个坑我确实踩过数据量上来后突然出现“too many open files”报错排查半天才发现是systemd的默认限制。Usermongodb和Groupmongodb指定以mongodb用户运行避免了root权限漏洞风险。如果MongoDB启动时用的是非daemon模式没有配置fork: trueExecStart前不需要加Typeforking默认simple类型就行。但如果配置了forksystemd可能判断服务启动失败这时需要在[Service]段加一行Typeforking并指定PIDFile。写完配置文件后执行sudo systemctl daemon-reload sudo systemctl enable mongod sudo systemctl start mongod sudo systemctl status mongod看到active (running)就是成功了。2.5 Windows环境安装差异点Linux讲完了Windows上的安装确实简单一些但坑的位置完全不一样。Windows有两种安装方式第一种是MSI安装包从官网下载.msi文件双击安装。安装向导里会让你选“Complete”还是“Custom”建议选Custom手动指定数据目录和日志目录别全装在C盘系统盘。安装向导还可以选择把MongoDB安装成Windows服务勾选后就能通过服务管理器启动/停止。第二种是ZIP绿色版下载zip解压后手动创建配置文件然后用命令启动。这个方式更适合想做精细控制的开发者。无论哪种方式Windows上最容易踩的坑有两个防火墙弹出提示时如果选了“取消”MongoDB能启动但其他机器访问不了需要在“允许应用通过防火墙”里手动添加27017端口。Windows路径的转义问题。mongod.conf里的路径如果包含空格或反斜杠必须用引号包裹或者使用正斜杠。比如dbPath: D:/data/mongodb/db比D:\\data\\mongodb\\db更不容易出错。Windows下启动单次运行的命令是cd C:\mongodb\bin mongod --config C:\mongodb\mongod.conf如果出现“服务无法启动”的提示99%的原因是dbPath不存在或者权限不足Windows上还可能是杀毒软件把mongod.exe拦截了这个我遇到过一次白名单加一下就解决了。3. 安装后的初始化与安全加固3.1 创建管理员账号的正确姿势安装完成后不能急着用首先要做的事是创建管理员账号。第一次启动时因为配置文件里已经启用了authorization所以此时数据库里还没有任何用户需要先通过localhost异常访问通道创建第一个管理员账号。MongoDB有个特殊的机制在没有创建任何用户之前即使开启了authorization本地回环地址也能无认证连接。这就是所谓的“localhost exception”只在第一用户创建前有效一旦创建完用户这个通道立刻关闭。所以顺序是先启动mongod - 用mongo shell连接 - 创建管理员用户 - 后续连接都走认证。# 使用mongosh或者mongo6.0之前叫mongo shell mongosh --port 27017 # 在shell中执行 use admin db.createUser( { user: admin, pwd: 这是一个足够长的强密码, roles: [ { role: root, db: admin } ] } ) # 退出后重新用认证连接 mongosh --port 27017 -u admin -p --authenticationDatabase admin这个管理员账号建议命名为admin角色用root表示有最高权限。日常业务不应该用这个账号连接应该再为具体业务库创建最小权限的用户。我给一个实际生产中常用的业务用户创建示例use myapp db.createUser( { user: appUser, pwd: 业务专用密码, roles: [ { role: readWrite, db: myapp }, { role: read, db: analytics } ] } )这样appUser只能读写myapp库对analytics库只能读权限边界很清晰。3.2 关闭THP和调整系统参数前面提到过THPTransparent Huge Pages这里给具体的操作。MongoDB官方文档明确说了THP会导致内存碎片化和性能不稳定建议在生产环境禁用。原因是MongoDB的存储引擎和内存管理对页大小敏感THP会突然分配大块内存给操作系统和MongoDB都带来不可预测的停顿。检查当前THP状态cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag如果输出是[always] madvise never说明THP处于开启状态。用下面的命令实时关闭重启后失效需要配合systemd或rc.local持久化echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag持久化方式可以用一个systemd服务或者直接在/etc/rc.local里加这两行。如果你用的是包管理器安装的MongoDB官方其实已经内置了一个关闭THP的脚本在/lib/systemd/system/mongod.service里能看到相关配置。二进制方式就需要自己处理了。除此之外还要优化虚拟内存的交换策略。修改/etc/sysctl.confvm.swappiness 1swappiness默认是60表示内存紧张时系统积极使用swap。MongoDB这种对响应时间敏感的程序应该尽量让数据留在物理内存中建议设置1~10之间。设置后执行sysctl -p生效。注意修改sysctl和THP属于系统级调整影响的是整个操作系统的行为。如果你在这台机器上还跑着其他数据库需要评估统一降低swappiness对它们的影响。3.3 验证安装效果的几个命令安装完成、创建好账号后做一轮基础验证确保一切正常。我习惯按顺序执行这几步登录shell查看实例状态db.runCommand({ serverStatus: 1 })重点关注uptime启动时长、connections当前连接数、mem内存使用、storageEngine确认是wiredTiger。如果storageEngine显示的是mmapv1说明你用的老版本或者配置有误。查看库和集合show dbs use myapp show collections创建一条测试文档并读取db.test.insertOne({ name: hello, value: 123 }) db.test.find().pretty()查看分片状态相关的命令处理一下。很多人在单机版上执行sh.status()会发现报错或者一直不返回这是正常的因为单机没有配置分片集群。单机环境下想看数据在各个“块”的分布可以用db.printShardingStatus()或者直接查看数据库的chunk相关信息use config db.chunks.find().pretty()不过我要提醒一下单机部署压根没有分片概念这些命令意义不大。真正要关注的是热门搜索词里那个“mongodb查看表分片”的需求场景——只有配置了集群才需要在mongos节点上执行sh.status()来查看哪个表分片、分片键是什么、各个分片上的数据块数量是否均衡。单机阶段想理解分片原理可以通过db.collection.stats()查看集合的sharded字段如果显示false说明没有启用分片。验证mongodump备份功能也值得做一次防患于未然mkdir -p /data/backup mongodump --host 127.0.0.1 --port 27017 --username admin --password --authenticationDatabase admin --db myapp --out /data/backup能看到“successfully”字样就证明备份通道没问题。顺便把mysql时代就养成的习惯带过来备份一定要验证能否恢复。mongorestore和mongodump是对应的用起来也是镜像操作。4. 日常运维与常见问题速查4.1 日志、监控和Systemd管理三件套MongoDB的日志是排查一切问题的第一入口。日志默认输出到mongod.conf里配置的systemLog.path设置logAppend: true后日志不会因为重启而丢失。我用日志排查问题时最常做的是# 查看最后50行关注conn、error、-1000等关键词 tail -n 50 /data/mongodb/logs/mongod.log # 实时跟踪连接和错误 tail -f /data/mongodb/logs/mongod.log | grep -E (error|exception|fatal) # 查看启动过程的完整日志重启后前500行 journalctl -u mongod --since 1 hour agoMongoDB的日志本身就有比较清晰的结构比如{t:{$date:...},s:I,c:NETWORK,id:22943,ctx:listener,msg:connection accepted...}。里面的s字段代表日志级别I是InfoW是WarningE是ErrorF是Fatal。排查问题时先按级别过滤效率会高很多。systemd管理上我常用的不只是start/stop/status还有这两个# 查看最近一次启动失败时的详细状态 systemctl status mongod -l # 查看服务完整启动输出 journalctl -u mongod -n 200如果服务启动失败systemctl status mongod -l会输出最后几行日志加上journalctl -u mongod -n 200查看更早的启动过程日志绝大多数启动失败都能在这里找到原因无非就是权限、路径、配置三个方向。关于监控单机场景最简单实用的是定时执行mongostat/opt/mongodb/bin/mongostat --host 127.0.0.1 --port 27017 --username admin --password --authenticationDatabase admin 5这个命令每5秒输出一次能看到insert/query/update/delete的每秒次数、连接数、锁等待、网络流量、vsize/rss内存等关键指标。我经常在压测时开着一个终端跑mongostat另一终端跑业务就能很直观地看到数据库的瓶颈在哪里。4.2 MongoDB安装失败的高频原因排查根据热门搜索词很多人在“mongodb安装失败”上卡住。我整理了一个速查表按出现频率从高到低排列常见报错原因解决方法error: not authorized on admin to execute command认证没通过账号密码或认证库不对检查--authenticationDatabase参数是否正确Failed to unlink socket file /tmp/mongodb-27017.sock上一次进程未完全退出socket文件残留rm -f /tmp/mongodb-27017.sock或systemctl restart mongoddbpath (/data/db) does not existdbPath目录不存在mkdir -p /data/db并赋予mongodb用户权限Permission denied目录属主不对或SELinux拦截chown -R mongodb:mongodb /data/mongodb或关SELinuxUnsupported option: storage.wiredTiger版本太低3.x不支持WiredTiger选项正常低版本用--storageEngine wiredTiger替代address already in use27017端口被占用netstat -tlnp | grep 27017找到进程处理冲突Failed to connect to 127.0.0.1:27017服务没起来或者bindIp配置变了看日志systemctl status mongod这里面最隐蔽的是SELinux问题CentOS/RHEL系统尤其常见。MongoDB的数据目录被SELinux的policy限制即使目录权限改成777还是报Permission denied。我当时排查了很久最后是执行ausearch -m avc -ts recent看到SELinux的拒绝了MongoDB的写操作才确定的。临时方案是setenforce 0长期方案是调整SELinux策略或使用官方的mongodb-selinux包。如果不想折腾直接把MongoDB的路径加白名单也行但要意识到这是安全权衡。另一个容易忽略的坑是磁盘空间不足。MongoDB启动时会检查dbPath所在分区的剩余空间如果低于某个阈值机房环境通常我们看df -h启动会不成功或者进入只读模式。日志里会出现no space left on device或者run a repair的字样。4.3 关于“c# mongodb 集合 最大值”问题的延伸思考这个热搜词很有意思。“c# mongodb 集合 最大值”我理解涉及两层问题一是C#操作MongoDB时如何查询某个集合中字段的最大值二是MongoDB集合本身的大小上限是多少文档大小上限16MB。这两个问题在单机安装后的第一天就可能遇到所以我在运维章节安排一节专门说。MongoDB单文档大小上限是16MBBSON文档的硬限制。这个限制是从MongoDB 1.8就定下来的原因是一个文档如果过大网络传输和内存操作的效率会变得很低而且BSON文档的嵌套深度和大小需要有一个可控的边界。如果你确实需要存超过16MB的大对象官方建议用GridFS它会自动把大文件拆分成多个chunk默认每个chunk约255KB存储。C#那边对应的是GridFSBucket这个类用起来很直接上传流式文件时自动搞定分块。C#查询集合字段最大值的标准做法var client new MongoClient(mongodb://127.0.0.1:27017); var database client.GetDatabase(myapp); var collection database.GetCollectionBsonDocument(orders); // 方法一聚合管道适合大集合 var pipeline new[] { new BsonDocument($group, new BsonDocument { { _id, BsonNull.Value }, { maxValue, new BsonDocument($max, $amount) } }) }; var maxResult await collection.AggregateBsonDocument(pipeline).FirstOrDefaultAsync(); // 方法二sort limit需要字段有索引 var cursor collection.Find(FilterDefinitionBsonDocument.Empty) .Sort(BuildersBsonDocument.Sort.Descending(amount)) .Limit(1); var doc await cursor.FirstOrDefaultAsync(); var max doc?[amount];需要注意的点方法二的sort操作如果没有在amount字段上建索引当集合数据量超过内存排序限制32MB时会报错“Sort exceeded memory limit, but was not able to add an index”。这个错误出现的频率不低解法就是建索引或者改用聚合管道中的$group方式聚合阶段的内存限制是100MB且可以用allowDiskUse。在单机安装的这个阶段把这些讲清楚是因为很多C#项目是在单机MongoDB上起步的这些细节直接影响业务代码的写法。4.4 集合和存储状态查看的补充运维技能除了常规的db.collection.stats()再补充几个我日常必用的状态查看命令数据/索引占用的磁盘空间db.collection.stats().size // 集合实际数据大小未压缩 db.collection.stats().storageSize // 占用磁盘大小压缩后 db.collection.stats().totalIndexSize // 索引占用的磁盘大小 db.collection.stats().indexSizes // 每个索引分别占用的磁盘大小单机版看索引占用特别重要。有时候数据没多少索引却把磁盘塞满了一个表上挂了7、8个索引的场景并不少见。安装后的初始规划就要想好哪些字段值得建索引。数据库级空间统计use myapp db.runCommand({ dbStats: 1, scale: 1024 })scale: 1024表示以KB为单位输出看起来更直观。当前连接列表db.currentOp()如果发现某个连接长时间运行大查询可以记录opid之后用db.killOp(opid)终止它。单机场景下这个命令经常用于处理误操作的慢查询。4.5 日志轮转MongoDB默认不会自动清理日志日志文件会无限增长最终把磁盘塞满。这个问题在长时间运行的服务器上很容易爆发。处理方案有两种。第一种是MongoDB内置的日志轮转命令。登录mongo shell执行use admin db.runCommand({ logRotate: 1 })这个命令会让MongoDB关闭当前日志文件换一个新的。注意它只是“轮转”并不会自动删除旧日志所以还需要配合系统logrotate定期清理。第二种是用Linux的logrotate工具统一管理。在/etc/logrotate.d/mongodb里写上/data/mongodb/logs/*.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }copytruncate参数很关键它先复制当前日志文件再清空原文件这样MongoDB进程不需要重启也不会丢失日志。配合daily每天轮转一次、rotate 7保留7天单机日志就基本不用管了。5. 性能基线配置与后续扩展思考5.1 针对单机的核心性能参数单机安装完成后有几个性能参数值得在安装阶段就思考清楚避免后面再来回折腾。WiredTiger缓存大小是影响最大的参数。前面说了默认是50%物理内存减1GB但这个默认值其实很粗暴生产环境建议按实际业务类型微调。判断依据是看缓存命中率在serverStatus输出里找wiredTiger.cachebytes currently in the cache和pages read into cache这些字段。如果命中率长期低于90%说明缓存设置偏小可以适度调大如果长期空闲但内存占用居高不下说明缓存给多了。缓存参数的设置逻辑是单机MongoDB加上操作系统的page cache总的有效缓存是WiredTiger缓存加上系统页面缓存。所以不需要把所有内存都给WiredTiger留一部分给OS page cache反而更好。这就是为什么官方默认只给50%而不是90%的原因。另外两个在单机上有感的核心参数是storage.wiredTiger.collectionConfig.blockCompressor数据压缩算法。如果CPU有富余改成zstd可以获得更好的压缩率。实测在小文档、高写入场景下zstd的CPU开销增加不明显但存储节省可观。operationProfiling.mode慢查询日志。建议在开发环境直接开slowOpThresholdMs: 100记录所有超过100毫秒的操作。日志输出到systemLog开发阶段就能发现那些隐藏的慢查询。第三个参数配置方式operationProfiling: mode: slowOp slowOpThresholdMs: 100生产环境如果开启建议阈值设200~300毫秒避免日志噪音过大。5.2 从单机到副本集/分片的自然演进路径单机装好只是第一步。绝大多数应用最终会走向副本集或分片集群。这个演进路径值得在单机阶段就规划好。从单机升级到副本集的路径相对平滑只要启动时指定replSet名称把多个节点的mongod配置里加上相同的replSet然后初始化副本集单机就变成了一个完整副本集节点。rs.initiate()之后,这一台机器就成为副本集里的Primary节点,后续添加Secondary时只需要在副本集里rs.add()。数据库驱动连接串也会从单点变成副本集模式多了一个replicaSetxxx参数还会自动处理主节点切换。C#驱动那边对应的是MongoClientSettings里的ConnectionMode ConnectionMode.ReplicaSet。分片集群的演进则复杂很多核心思路是先搭好配置服务器副本集CSRS再添加一个或多个分片shard最后通过mongos路由节点连接应用。分片键的选择是关键中的关键选得好数据分布均匀选得差会导致某个shard变成热点。单机阶段能做的准备是在具体集合上根据业务查询模式提前想清楚候选分片键以及使用hashed还是ranged分片方式。哈希分片能让数据分布更随机均匀适合单调递增的字段比如时间戳范围分片适合范围查询多的场景。单机阶段另一个可以提前做的准备是目录规划。比如dbPath挂在独立磁盘上副本集多节点时每台机器独立磁盘分片集群各个shard分散到多台机器。如果一开始数据目录就在系统盘里后面做数据迁移和扩容时会多不少操作成本。5.3 备份恢复与数据迁移的初始化验证数据库的备份恢复机制建议在安装后就做一轮完整的演练。因为单机MongoDB没有任何高可用保障磁盘故障、误删数据、版本升级失败任何意外都会让数据面临风险。等数据积累到几十GB再开始考虑备份往往已经晚了。MongoDB官方推荐的备份工具是mongodump/mongorestore。对于单机小规模数据GB级别简单够用。遇到更大的数据库更推荐用文件系统快照或者云厂商的磁盘快照因为mongodump在恢复数据量较大时耗时很长而且备份过程中可能有性能抖动。完整的备份命令前面提过一次这里展开讲一下细节# 全库备份 mongodump --host 127.0.0.1 --port 27017 \ --username admin --password 密码 \ --authenticationDatabase admin \ --out /data/backup/backup_$(date %Y%m%d_%H%M%S) # 恢复指定库 mongorestore --host 127.0.0.1 --port 27017 \ --username admin --password 密码 \ --authenticationDatabase admin \ --nsInclude myapp.* \ /data/backup/backup_20250301/dump这里有个经验--nsInclude参数可以只恢复需要的库或集合别一上来就全量恢复。而且恢复前建议先检查目标库里是不是有同名集合避免覆盖掉还在用的数据。mongorestore默认行为是upsert不删除目标库的已有数据可能造成脏数据所以恢复业务前最好先drop掉目标集合。单机阶段也可以考虑定时任务crontab -e # 每天凌晨2点执行一次全备 0 2 * * * /opt/mongodb/bin/mongodump --host 127.0.0.1 --port 27017 --username admin --password 密码 --authenticationDatabase admin --out /data/backup/backup_$(date \%Y\%m\%d_\%H\%M\%S) /var/log/mongobackup.log 21注意crontab里的%要转义成\%否则时间戳会生成不出来。这个坑我最早部署时踩过日志里只看到backup_没时间。最后再分享一个我个人的体会单机MongoDB虽然不需要面对集群那么多的复杂问题但“一个人把服务跑起来”这件事本身涵盖了版本选型、配置调优、安全加固、日常运维、备份恢复几乎所有数据库生命周期里的关键环节。如果你能把单机部署做到配置合理、权限清晰、备份完备那么面对副本集和分片集群时你已经有了一根很扎实的定海神针。踩过几次坑之后我最深的感受是MongoDB安装这事本身很简单难的是安装前把需求想清楚、安装后把底层机制弄明白。希望这篇内容能让你少走一些我走过的弯路。 MongoDB单机部署全攻略：从版本选型到安全加固与运维实践
1. 安装前的准备工作与版本选型思路1.1 为什么单机安装也需要认真规划很多朋友觉得MongoDB单机安装这事太简单了apt install mongodb敲完就算完事。但我在实际部署和后续运维中踩过不少坑才意识到安装这个环节的决策直接影响后面几个月的稳定性。比如版本选错导致驱动不兼容日志目录没规划好导致磁盘写满WiredTiger缓存配置给太多导致同机其他服务被挤爆。这些问题表面上跟“安装”没关系但根源都在安装那一刻的决策上。先明确一下这篇博文适用的场景开发环境快速搭建、小规模生产环境的单节点部署、学习研究用的本地实例。如果你要搭副本集或分片集群建议先读完这篇文章把单机部分吃透原理是共通的。我会以LinuxUbuntu 20.04/CentOS 7.x为主讲Windows环境单独开一节说明因为两者的坑完全不一样。1.2 MongoDB的版本选择到底在选什么打开MongoDB官网你会发现版本号一堆社区版、企业版还有6.0、7.0这样的主版本号。很多新手直接装最新版其实这个选择背后是有讲究的。版本选型主要看三个维度稳定性周期MongoDB奇数版本如5.1、6.1属于快速迭代版偶数版本如5.0、6.0、7.0是稳定版。生产环境务必选偶数稳定版开发环境如果你愿意尝鲜用奇数版也能学到新特性但遇到bug的概率会高一些。驱动兼容性这一点最容易被忽略。比如你在用C#的MongoDB.Driver 2.19以下的版本连接MongoDB 7.0会报认证协议不兼容或者游标超时的奇怪错误。我建议先确认你项目里驱动版本再去倒推MongoDB服务器版本。热门搜索词里那个“c# mongodb 集合 最大值”其实很多情况下就是驱动和服务器版本不匹配导致的文档大小限制或游标行为异常后面我会展开讲。操作系统的官方支持范围Ubuntu 22.04、Debian 11、RHEL 9这些都有对用的MongoDB版本仓库。如果你的系统太老比如CentOS 6官方早就不维护了只能用第三方编译包或者升级系统。这里我推荐一个保守而实用的组合生产环境用MongoDB 6.0.x目前维护期较长、生态兼容好、文档最全开发环境可以用7.0.x体验新特性比如可查询加密、更快的聚合管道。1.3 系统环境准备清单安装前先把环境检查做完省得装到一半发现缺依赖。需要确认的项目主要有这些操作系统版本cat /etc/os-release看一眼确认是64位系统x86_64或ARM64都行MongoDB对ARM支持也不错32位系统早就不支持了。磁盘空间MongoDB本体加依赖至少预留5GB以上空间但这是指安装空间。数据目录才是大头建议数据目录单独划分磁盘至少是预估数据量的2~3倍给未来的索引、oplog、日志留出余地。内存大小WiredTiger存储引擎默认会使用“物理内存的50%减去1GB”作为缓存上限。比如机器有16GB内存MongoDB默认吃7GB。如果你的机器总共只有2GB内存那默认配置很容易触发OOM。这个一定要在安装前想清楚。文件描述符限制ulimit -n查看建议至少设为64000。连接数一多文件描述符不够会直接导致连接失败或者查询卡住这在生产环境是一个经典排查点。关闭THP透明大页MongoDB官方强烈建议关闭Linux的透明大页否则可能引发性能问题。这个可以安装前做也可以装完后做后面我会给具体命令。防火墙端口MongoDB默认端口27017。如果是本地开发不涉及跨机器访问那随意。如果后续有远程访问需求防火墙要开这个端口同时要配置mongod.conf里的bindIp默认只绑127.0.0.1想远程访问必须显式配置这块后面细说。把上面这些逐项过一遍大概几分钟时间但能省掉你后面排查问题的很多精力。2. 安装方式对比与离线部署方案2.1 三种安装方式怎么选MongoDB单机安装主要有三种方式包管理器直接安装、下载二进制包手动部署、Docker容器化运行。我三种都用过说说各自的优缺点。包管理器安装apt/yum是最省事的官方维护了APT和YUM仓库装完还会自动配好systemd服务systemctl start mongod就能启动。缺点是版本更新你需要手动改仓库源而且安装路径是散装的配置在/etc/mongod.conf数据在/var/lib/mongodb日志在/var/log/mongodb后续想迁移数据目录会麻烦一点。二进制包手动部署是我个人最推荐的方式也是这篇博文的重点。它把一个完整目录下的mongodb-binaries解压到你指定的路径所有内容集中在一起数据目录、日志目录、配置文件全部由你自定义升级和迁移时特别灵活。当年我从包管理器方式切到二进制方式后再也没回去过。Docker方式在小规模测试环境非常舒服docker run -d -p 27017:27017 mongo:6.0一行搞定。但生产单机我一般不建议因为数据卷管理、容器重启策略、日志收集都要额外处理复杂度并没有减少多少反而让故障排查多了一层。如果你用Docker至少要把数据目录挂载到宿主机别把数据留在容器可写层里容器一删就全没了。2.2 二进制包部署完整实操这里给出我实测过的完整操作过程以MongoDB 6.0.14、Ubuntu 20.04为例CentOS系统的差异我会在括号里标注。先去MongoDB官网下载页找到对应版本。官网的下载页默认给的是当前最新版历史版本要到版本归档页面去翻。需要注意官网下载时要求填一下基本信息实际直接拿直链下载就行用wget命令最方便。# 创建专门的部署用户非root运行MongoDB是安全底线 sudo useradd --system --no-create-home --shell /bin/false mongodb # 创建软件目录和数据目录 sudo mkdir -p /opt/mongodb sudo mkdir -p /data/mongodb/db sudo mkdir -p /data/mongodb/logs sudo chown -R mongodb:mongodb /opt/mongodb /data/mongodb # 下载二进制包以6.0.14为例Ubuntu 20.04 x86_64 wget https://fastdl.mongodb.org/linux/mongodb-linux-x86_64-ubuntu2004-6.0.14.tgz # 解压并移动到目标目录 tar -zxvf mongodb-linux-x86_64-ubuntu2004-6.0.14.tgz sudo mv mongodb-linux-x86_64-ubuntu2004-6.0.14/* /opt/mongodb/解压后检查一下目录结构确保/opt/mongodb/bin下有mongod、mongos、mongo7.0之后的版本把mongo shell独立成了mongosh需要注意这些可执行文件。2.3 配置文件mongod.conf的编写要点二进制部署的核心是写好mongod.conf。MongoDB启动时可以用--config参数指定配置文件我强烈建议用配置文件而不是命令行参数因为可读性和后续维护性好太多。下面是我常用的一个单机配置模板# mongod.conf storage: dbPath: /data/mongodb/db wiredTiger: engineConfig: cacheSizeGB: 4 collectionConfig: blockCompressor: snappy systemLog: destination: file path: /data/mongodb/logs/mongod.log logAppend: true net: port: 27017 bindIp: 127.0.0.1 processManagement: fork: true pidFilePath: /data/mongodb/logs/mongod.pid security: authorization: enabled逐个解释关键参数的意思dbPath是数据存储目录这里指向了/data/mongodb/db。注意这个目录必须存在且有权限MongoDB不会自动创建某些版本会自动创建但依赖父目录存在。cacheSizeGB是WiredTiger存储引擎的缓存上限。我之前强调过这个值的重要性这里再细化一下建议设置为物理内存的40%~50%。比如16GB内存设置4~6GB。如果机器上还跑着其他服务则要减少如果MongoDB独占机器可以给到物理内存的50%。设置太小比如2GB以下大数据量查询的性能会明显下降。blockCompressor: snappy是集合数据的压缩算法。snappy压缩率适中、CPU消耗低是默认值。还有一个zstd选项压缩率更高但CPU开销也大低写入高存储压力的场景可以考虑。logAppend: true表示日志写入是追加模式不会重启覆盖这样重启前崩溃的日志还能追到。bindIp: 127.0.0.1只允许本机连接。这是安全的默认配置开发环境不需要改。如果要远程连接改成0.0.0.0或者具体IP但要同时启动认证否则裸奔在网络上非常危险。authorization: enabled启动认证这个建议从一开始就打开。很多人装完单机图省事不开认证结果数据库被勒索或者数据被清空网上搜一下案例太多了。把配置文件放在/opt/mongodb/mongod.conf然后就能用下面的命令启动了sudo -u mongodb /opt/mongodb/bin/mongod --config /opt/mongodb/mongod.conf启动后用ps aux | grep mongod查看进程是否在跑或者看日志文件tail -f /data/mongodb/logs/mongod.log的输出。日志里如果出现waiting for connections on port 27017就代表启动成功了。2.4 systemd服务配置二进制部署不会自动创建systemd服务需要手工写一个service文件这样才能用systemctl start mongod统一管理并且开机自启。在/etc/systemd/system/mongod.service里写入如下内容[Unit] DescriptionMongoDB Database Server Afternetwork.target [Service] Usermongodb Groupmongodb ExecStart/opt/mongodb/bin/mongod --config /opt/mongodb/mongod.conf PIDFile/data/mongodb/logs/mongod.pid LimitNOFILE64000 LimitNPROC64000 [Install] WantedBymulti-user.target几个关键点LimitNOFILE64000提升了进程能打开的文件数上限。虽然mongod.conf里也能配但systemd层面限制如果不够进程内怎么配置都没用。这个坑我确实踩过数据量上来后突然出现“too many open files”报错排查半天才发现是systemd的默认限制。Usermongodb和Groupmongodb指定以mongodb用户运行避免了root权限漏洞风险。如果MongoDB启动时用的是非daemon模式没有配置fork: trueExecStart前不需要加Typeforking默认simple类型就行。但如果配置了forksystemd可能判断服务启动失败这时需要在[Service]段加一行Typeforking并指定PIDFile。写完配置文件后执行sudo systemctl daemon-reload sudo systemctl enable mongod sudo systemctl start mongod sudo systemctl status mongod看到active (running)就是成功了。2.5 Windows环境安装差异点Linux讲完了Windows上的安装确实简单一些但坑的位置完全不一样。Windows有两种安装方式第一种是MSI安装包从官网下载.msi文件双击安装。安装向导里会让你选“Complete”还是“Custom”建议选Custom手动指定数据目录和日志目录别全装在C盘系统盘。安装向导还可以选择把MongoDB安装成Windows服务勾选后就能通过服务管理器启动/停止。第二种是ZIP绿色版下载zip解压后手动创建配置文件然后用命令启动。这个方式更适合想做精细控制的开发者。无论哪种方式Windows上最容易踩的坑有两个防火墙弹出提示时如果选了“取消”MongoDB能启动但其他机器访问不了需要在“允许应用通过防火墙”里手动添加27017端口。Windows路径的转义问题。mongod.conf里的路径如果包含空格或反斜杠必须用引号包裹或者使用正斜杠。比如dbPath: D:/data/mongodb/db比D:\\data\\mongodb\\db更不容易出错。Windows下启动单次运行的命令是cd C:\mongodb\bin mongod --config C:\mongodb\mongod.conf如果出现“服务无法启动”的提示99%的原因是dbPath不存在或者权限不足Windows上还可能是杀毒软件把mongod.exe拦截了这个我遇到过一次白名单加一下就解决了。3. 安装后的初始化与安全加固3.1 创建管理员账号的正确姿势安装完成后不能急着用首先要做的事是创建管理员账号。第一次启动时因为配置文件里已经启用了authorization所以此时数据库里还没有任何用户需要先通过localhost异常访问通道创建第一个管理员账号。MongoDB有个特殊的机制在没有创建任何用户之前即使开启了authorization本地回环地址也能无认证连接。这就是所谓的“localhost exception”只在第一用户创建前有效一旦创建完用户这个通道立刻关闭。所以顺序是先启动mongod - 用mongo shell连接 - 创建管理员用户 - 后续连接都走认证。# 使用mongosh或者mongo6.0之前叫mongo shell mongosh --port 27017 # 在shell中执行 use admin db.createUser( { user: admin, pwd: 这是一个足够长的强密码, roles: [ { role: root, db: admin } ] } ) # 退出后重新用认证连接 mongosh --port 27017 -u admin -p --authenticationDatabase admin这个管理员账号建议命名为admin角色用root表示有最高权限。日常业务不应该用这个账号连接应该再为具体业务库创建最小权限的用户。我给一个实际生产中常用的业务用户创建示例use myapp db.createUser( { user: appUser, pwd: 业务专用密码, roles: [ { role: readWrite, db: myapp }, { role: read, db: analytics } ] } )这样appUser只能读写myapp库对analytics库只能读权限边界很清晰。3.2 关闭THP和调整系统参数前面提到过THPTransparent Huge Pages这里给具体的操作。MongoDB官方文档明确说了THP会导致内存碎片化和性能不稳定建议在生产环境禁用。原因是MongoDB的存储引擎和内存管理对页大小敏感THP会突然分配大块内存给操作系统和MongoDB都带来不可预测的停顿。检查当前THP状态cat /sys/kernel/mm/transparent_hugepage/enabled cat /sys/kernel/mm/transparent_hugepage/defrag如果输出是[always] madvise never说明THP处于开启状态。用下面的命令实时关闭重启后失效需要配合systemd或rc.local持久化echo never /sys/kernel/mm/transparent_hugepage/enabled echo never /sys/kernel/mm/transparent_hugepage/defrag持久化方式可以用一个systemd服务或者直接在/etc/rc.local里加这两行。如果你用的是包管理器安装的MongoDB官方其实已经内置了一个关闭THP的脚本在/lib/systemd/system/mongod.service里能看到相关配置。二进制方式就需要自己处理了。除此之外还要优化虚拟内存的交换策略。修改/etc/sysctl.confvm.swappiness 1swappiness默认是60表示内存紧张时系统积极使用swap。MongoDB这种对响应时间敏感的程序应该尽量让数据留在物理内存中建议设置1~10之间。设置后执行sysctl -p生效。注意修改sysctl和THP属于系统级调整影响的是整个操作系统的行为。如果你在这台机器上还跑着其他数据库需要评估统一降低swappiness对它们的影响。3.3 验证安装效果的几个命令安装完成、创建好账号后做一轮基础验证确保一切正常。我习惯按顺序执行这几步登录shell查看实例状态db.runCommand({ serverStatus: 1 })重点关注uptime启动时长、connections当前连接数、mem内存使用、storageEngine确认是wiredTiger。如果storageEngine显示的是mmapv1说明你用的老版本或者配置有误。查看库和集合show dbs use myapp show collections创建一条测试文档并读取db.test.insertOne({ name: hello, value: 123 }) db.test.find().pretty()查看分片状态相关的命令处理一下。很多人在单机版上执行sh.status()会发现报错或者一直不返回这是正常的因为单机没有配置分片集群。单机环境下想看数据在各个“块”的分布可以用db.printShardingStatus()或者直接查看数据库的chunk相关信息use config db.chunks.find().pretty()不过我要提醒一下单机部署压根没有分片概念这些命令意义不大。真正要关注的是热门搜索词里那个“mongodb查看表分片”的需求场景——只有配置了集群才需要在mongos节点上执行sh.status()来查看哪个表分片、分片键是什么、各个分片上的数据块数量是否均衡。单机阶段想理解分片原理可以通过db.collection.stats()查看集合的sharded字段如果显示false说明没有启用分片。验证mongodump备份功能也值得做一次防患于未然mkdir -p /data/backup mongodump --host 127.0.0.1 --port 27017 --username admin --password --authenticationDatabase admin --db myapp --out /data/backup能看到“successfully”字样就证明备份通道没问题。顺便把mysql时代就养成的习惯带过来备份一定要验证能否恢复。mongorestore和mongodump是对应的用起来也是镜像操作。4. 日常运维与常见问题速查4.1 日志、监控和Systemd管理三件套MongoDB的日志是排查一切问题的第一入口。日志默认输出到mongod.conf里配置的systemLog.path设置logAppend: true后日志不会因为重启而丢失。我用日志排查问题时最常做的是# 查看最后50行关注conn、error、-1000等关键词 tail -n 50 /data/mongodb/logs/mongod.log # 实时跟踪连接和错误 tail -f /data/mongodb/logs/mongod.log | grep -E (error|exception|fatal) # 查看启动过程的完整日志重启后前500行 journalctl -u mongod --since 1 hour agoMongoDB的日志本身就有比较清晰的结构比如{t:{$date:...},s:I,c:NETWORK,id:22943,ctx:listener,msg:connection accepted...}。里面的s字段代表日志级别I是InfoW是WarningE是ErrorF是Fatal。排查问题时先按级别过滤效率会高很多。systemd管理上我常用的不只是start/stop/status还有这两个# 查看最近一次启动失败时的详细状态 systemctl status mongod -l # 查看服务完整启动输出 journalctl -u mongod -n 200如果服务启动失败systemctl status mongod -l会输出最后几行日志加上journalctl -u mongod -n 200查看更早的启动过程日志绝大多数启动失败都能在这里找到原因无非就是权限、路径、配置三个方向。关于监控单机场景最简单实用的是定时执行mongostat/opt/mongodb/bin/mongostat --host 127.0.0.1 --port 27017 --username admin --password --authenticationDatabase admin 5这个命令每5秒输出一次能看到insert/query/update/delete的每秒次数、连接数、锁等待、网络流量、vsize/rss内存等关键指标。我经常在压测时开着一个终端跑mongostat另一终端跑业务就能很直观地看到数据库的瓶颈在哪里。4.2 MongoDB安装失败的高频原因排查根据热门搜索词很多人在“mongodb安装失败”上卡住。我整理了一个速查表按出现频率从高到低排列常见报错原因解决方法error: not authorized on admin to execute command认证没通过账号密码或认证库不对检查--authenticationDatabase参数是否正确Failed to unlink socket file /tmp/mongodb-27017.sock上一次进程未完全退出socket文件残留rm -f /tmp/mongodb-27017.sock或systemctl restart mongoddbpath (/data/db) does not existdbPath目录不存在mkdir -p /data/db并赋予mongodb用户权限Permission denied目录属主不对或SELinux拦截chown -R mongodb:mongodb /data/mongodb或关SELinuxUnsupported option: storage.wiredTiger版本太低3.x不支持WiredTiger选项正常低版本用--storageEngine wiredTiger替代address already in use27017端口被占用netstat -tlnp | grep 27017找到进程处理冲突Failed to connect to 127.0.0.1:27017服务没起来或者bindIp配置变了看日志systemctl status mongod这里面最隐蔽的是SELinux问题CentOS/RHEL系统尤其常见。MongoDB的数据目录被SELinux的policy限制即使目录权限改成777还是报Permission denied。我当时排查了很久最后是执行ausearch -m avc -ts recent看到SELinux的拒绝了MongoDB的写操作才确定的。临时方案是setenforce 0长期方案是调整SELinux策略或使用官方的mongodb-selinux包。如果不想折腾直接把MongoDB的路径加白名单也行但要意识到这是安全权衡。另一个容易忽略的坑是磁盘空间不足。MongoDB启动时会检查dbPath所在分区的剩余空间如果低于某个阈值机房环境通常我们看df -h启动会不成功或者进入只读模式。日志里会出现no space left on device或者run a repair的字样。4.3 关于“c# mongodb 集合 最大值”问题的延伸思考这个热搜词很有意思。“c# mongodb 集合 最大值”我理解涉及两层问题一是C#操作MongoDB时如何查询某个集合中字段的最大值二是MongoDB集合本身的大小上限是多少文档大小上限16MB。这两个问题在单机安装后的第一天就可能遇到所以我在运维章节安排一节专门说。MongoDB单文档大小上限是16MBBSON文档的硬限制。这个限制是从MongoDB 1.8就定下来的原因是一个文档如果过大网络传输和内存操作的效率会变得很低而且BSON文档的嵌套深度和大小需要有一个可控的边界。如果你确实需要存超过16MB的大对象官方建议用GridFS它会自动把大文件拆分成多个chunk默认每个chunk约255KB存储。C#那边对应的是GridFSBucket这个类用起来很直接上传流式文件时自动搞定分块。C#查询集合字段最大值的标准做法var client new MongoClient(mongodb://127.0.0.1:27017); var database client.GetDatabase(myapp); var collection database.GetCollectionBsonDocument(orders); // 方法一聚合管道适合大集合 var pipeline new[] { new BsonDocument($group, new BsonDocument { { _id, BsonNull.Value }, { maxValue, new BsonDocument($max, $amount) } }) }; var maxResult await collection.AggregateBsonDocument(pipeline).FirstOrDefaultAsync(); // 方法二sort limit需要字段有索引 var cursor collection.Find(FilterDefinitionBsonDocument.Empty) .Sort(BuildersBsonDocument.Sort.Descending(amount)) .Limit(1); var doc await cursor.FirstOrDefaultAsync(); var max doc?[amount];需要注意的点方法二的sort操作如果没有在amount字段上建索引当集合数据量超过内存排序限制32MB时会报错“Sort exceeded memory limit, but was not able to add an index”。这个错误出现的频率不低解法就是建索引或者改用聚合管道中的$group方式聚合阶段的内存限制是100MB且可以用allowDiskUse。在单机安装的这个阶段把这些讲清楚是因为很多C#项目是在单机MongoDB上起步的这些细节直接影响业务代码的写法。4.4 集合和存储状态查看的补充运维技能除了常规的db.collection.stats()再补充几个我日常必用的状态查看命令数据/索引占用的磁盘空间db.collection.stats().size // 集合实际数据大小未压缩 db.collection.stats().storageSize // 占用磁盘大小压缩后 db.collection.stats().totalIndexSize // 索引占用的磁盘大小 db.collection.stats().indexSizes // 每个索引分别占用的磁盘大小单机版看索引占用特别重要。有时候数据没多少索引却把磁盘塞满了一个表上挂了7、8个索引的场景并不少见。安装后的初始规划就要想好哪些字段值得建索引。数据库级空间统计use myapp db.runCommand({ dbStats: 1, scale: 1024 })scale: 1024表示以KB为单位输出看起来更直观。当前连接列表db.currentOp()如果发现某个连接长时间运行大查询可以记录opid之后用db.killOp(opid)终止它。单机场景下这个命令经常用于处理误操作的慢查询。4.5 日志轮转MongoDB默认不会自动清理日志日志文件会无限增长最终把磁盘塞满。这个问题在长时间运行的服务器上很容易爆发。处理方案有两种。第一种是MongoDB内置的日志轮转命令。登录mongo shell执行use admin db.runCommand({ logRotate: 1 })这个命令会让MongoDB关闭当前日志文件换一个新的。注意它只是“轮转”并不会自动删除旧日志所以还需要配合系统logrotate定期清理。第二种是用Linux的logrotate工具统一管理。在/etc/logrotate.d/mongodb里写上/data/mongodb/logs/*.log { daily rotate 7 compress delaycompress missingok notifempty copytruncate }copytruncate参数很关键它先复制当前日志文件再清空原文件这样MongoDB进程不需要重启也不会丢失日志。配合daily每天轮转一次、rotate 7保留7天单机日志就基本不用管了。5. 性能基线配置与后续扩展思考5.1 针对单机的核心性能参数单机安装完成后有几个性能参数值得在安装阶段就思考清楚避免后面再来回折腾。WiredTiger缓存大小是影响最大的参数。前面说了默认是50%物理内存减1GB但这个默认值其实很粗暴生产环境建议按实际业务类型微调。判断依据是看缓存命中率在serverStatus输出里找wiredTiger.cachebytes currently in the cache和pages read into cache这些字段。如果命中率长期低于90%说明缓存设置偏小可以适度调大如果长期空闲但内存占用居高不下说明缓存给多了。缓存参数的设置逻辑是单机MongoDB加上操作系统的page cache总的有效缓存是WiredTiger缓存加上系统页面缓存。所以不需要把所有内存都给WiredTiger留一部分给OS page cache反而更好。这就是为什么官方默认只给50%而不是90%的原因。另外两个在单机上有感的核心参数是storage.wiredTiger.collectionConfig.blockCompressor数据压缩算法。如果CPU有富余改成zstd可以获得更好的压缩率。实测在小文档、高写入场景下zstd的CPU开销增加不明显但存储节省可观。operationProfiling.mode慢查询日志。建议在开发环境直接开slowOpThresholdMs: 100记录所有超过100毫秒的操作。日志输出到systemLog开发阶段就能发现那些隐藏的慢查询。第三个参数配置方式operationProfiling: mode: slowOp slowOpThresholdMs: 100生产环境如果开启建议阈值设200~300毫秒避免日志噪音过大。5.2 从单机到副本集/分片的自然演进路径单机装好只是第一步。绝大多数应用最终会走向副本集或分片集群。这个演进路径值得在单机阶段就规划好。从单机升级到副本集的路径相对平滑只要启动时指定replSet名称把多个节点的mongod配置里加上相同的replSet然后初始化副本集单机就变成了一个完整副本集节点。rs.initiate()之后,这一台机器就成为副本集里的Primary节点,后续添加Secondary时只需要在副本集里rs.add()。数据库驱动连接串也会从单点变成副本集模式多了一个replicaSetxxx参数还会自动处理主节点切换。C#驱动那边对应的是MongoClientSettings里的ConnectionMode ConnectionMode.ReplicaSet。分片集群的演进则复杂很多核心思路是先搭好配置服务器副本集CSRS再添加一个或多个分片shard最后通过mongos路由节点连接应用。分片键的选择是关键中的关键选得好数据分布均匀选得差会导致某个shard变成热点。单机阶段能做的准备是在具体集合上根据业务查询模式提前想清楚候选分片键以及使用hashed还是ranged分片方式。哈希分片能让数据分布更随机均匀适合单调递增的字段比如时间戳范围分片适合范围查询多的场景。单机阶段另一个可以提前做的准备是目录规划。比如dbPath挂在独立磁盘上副本集多节点时每台机器独立磁盘分片集群各个shard分散到多台机器。如果一开始数据目录就在系统盘里后面做数据迁移和扩容时会多不少操作成本。5.3 备份恢复与数据迁移的初始化验证数据库的备份恢复机制建议在安装后就做一轮完整的演练。因为单机MongoDB没有任何高可用保障磁盘故障、误删数据、版本升级失败任何意外都会让数据面临风险。等数据积累到几十GB再开始考虑备份往往已经晚了。MongoDB官方推荐的备份工具是mongodump/mongorestore。对于单机小规模数据GB级别简单够用。遇到更大的数据库更推荐用文件系统快照或者云厂商的磁盘快照因为mongodump在恢复数据量较大时耗时很长而且备份过程中可能有性能抖动。完整的备份命令前面提过一次这里展开讲一下细节# 全库备份 mongodump --host 127.0.0.1 --port 27017 \ --username admin --password 密码 \ --authenticationDatabase admin \ --out /data/backup/backup_$(date %Y%m%d_%H%M%S) # 恢复指定库 mongorestore --host 127.0.0.1 --port 27017 \ --username admin --password 密码 \ --authenticationDatabase admin \ --nsInclude myapp.* \ /data/backup/backup_20250301/dump这里有个经验--nsInclude参数可以只恢复需要的库或集合别一上来就全量恢复。而且恢复前建议先检查目标库里是不是有同名集合避免覆盖掉还在用的数据。mongorestore默认行为是upsert不删除目标库的已有数据可能造成脏数据所以恢复业务前最好先drop掉目标集合。单机阶段也可以考虑定时任务crontab -e # 每天凌晨2点执行一次全备 0 2 * * * /opt/mongodb/bin/mongodump --host 127.0.0.1 --port 27017 --username admin --password 密码 --authenticationDatabase admin --out /data/backup/backup_$(date \%Y\%m\%d_\%H\%M\%S) /var/log/mongobackup.log 21注意crontab里的%要转义成\%否则时间戳会生成不出来。这个坑我最早部署时踩过日志里只看到backup_没时间。最后再分享一个我个人的体会单机MongoDB虽然不需要面对集群那么多的复杂问题但“一个人把服务跑起来”这件事本身涵盖了版本选型、配置调优、安全加固、日常运维、备份恢复几乎所有数据库生命周期里的关键环节。如果你能把单机部署做到配置合理、权限清晰、备份完备那么面对副本集和分片集群时你已经有了一根很扎实的定海神针。踩过几次坑之后我最深的感受是MongoDB安装这事本身很简单难的是安装前把需求想清楚、安装后把底层机制弄明白。希望这篇内容能让你少走一些我走过的弯路。