mongorestore是MongoDB官方数据库工具包中专门用来恢复备份的命令行工具，它读取mongodump生成的BSON文件或归档文件，把集合、索引、视图等对象写回目标实例。很多人以为恢复只是简单执行一条命令，实际在带认证环境、跨库恢复、oplog重放以及大数据量场景下，参数使用不当很容易导致恢复失败或覆盖线上数据。本文围绕实战展开，把常用参数、典型命令和排错方法梳理清楚。
一、mongorestore命令基础与关键参数
mongorestore的基本格式并不复杂，通常是指定备份目录或归档文件，再通过连接参数访问目标MongoDB实例。比如最常见的形式是mongorestore /data/backup/mydb，这个命令会读取备份目录中的内容，恢复到默认地址 mongodb://localhost:27017。如果目标实例不在本机，可以用--uri参数指定连接串，或者用--host、--port、--username、--password分别指定。
恢复时最需要关注的参数之一就是--drop。它的作用是恢复某个集合前先删除目标库中同名的集合，使最终结果与备份完全一致。不加这个参数时，mongorestore只做插入操作，如果文档的_id已经存在，会报重复键错误并中断该集合的恢复。因此，如果希望用备份覆盖现有数据，应该加上--drop；但如果是想增量合并数据，就不要加这个参数，以免目标库里新增的数据被清掉。另一个常用的过滤参数是--nsInclude，它支持按命名空间匹配，例如只恢复某个数据库或某个集合。
对于压缩备份，mongodump在较新版本中可以使用--gzip生成压缩文件，对应的恢复命令也需要加上--gzip，否则工具会试图按未压缩格式解析文件而报错。如果备份时使用了--archive参数生成了单个归档文件，那么恢复时就不能直接给目录，而应使用--archive=backup.archive加--gzip或直接指向归档文件。下面是一个带认证和压缩参数的完整示例。
mongorestore --uri="mongodb://admin:secret@192.168.10.25:27017/admin" \ --gzip --drop /data/backup/mydb
这段命令会连接到远程实例，使用管理员账号认证，恢复时先删除同名集合，并解压gzip格式的备份文件。反斜杠表示命令换行，在Windows命令行中需要改为^符号或者写在同一行。实际使用时建议先在小范围数据上验证参数组合，确认行为符合预期再对生产库执行。
二、常见恢复场景与命令拆解
实际工作中恢复数据的场景差别很大。有时只需要恢复一个误删的集合，有时需要把备份恢复到另一个名字的数据库，还有时候要从归档文件里挑出部分数据。掌握几种典型命令，能明显提高处理效率。
第一种是只恢复单个集合。假设备份目录为/data/backup/mydb，里面包含orders这个集合的BSON文件，只想恢复它，可以这样执行：mongorestore --db=mydb --collection=orders /data/backup/mydb/orders.bson。这里需要指定目标数据库和集合名称，否则工具可能会根据路径猜出命名空间。如果只想恢复到不同名称的集合，可以配合--nsFrom和--nsTo参数完成命名空间映射。
跨库恢复也是常见需求。例如把生产库app_prod的备份恢复到测试库app_test，可以在命令中指定--nsFrom="app_prod.*" --nsTo="app_test.*"。新版mongorestore支持这种命名空间重映射，命令如下。
mongorestore --uri="mongodb://testuser:testpass@localhost:27017/test" \ --nsFrom="app_prod.*" --nsTo="app_test.*" \ --gzip --drop /data/backup/app_prod
这样恢复时，所有app_prod开头的集合都会被映射到app_test下，不会覆盖生产库。需要注意的是，--nsFrom和--nsTo要成对出现，并且模式里的*表示通配。如果只想映射某个集合，可以把*换成集合名，例如app_prod.orders到app_test.orders_bak。
归档文件的处理稍有不同。如果备份生成的是单个文件backup.archive，恢复命令需要写成mongorestore --archive=backup.archive --gzip。如果归档文件里包含多个数据库，可以配合--nsInclude过滤，例如只恢复app_prod库：mongorestore --archive=backup.archive --gzip --nsInclude="app_prod.*"。这种方式在迁移大库时比处理散落的BSON文件更省事，因为只需要传输一个文件。
三、oplog重放与索引构建的细节
对于需要恢复到某个时间点的场景，oplog重放非常关键。mongodump在备份时可以使用--oplog参数把备份期间的变更记录下来，而mongorestore可以通过--oplogReplay把这些操作应用到目标库，使得恢复后的数据接近备份结束时刻的状态。这个能力常用于搭建从库或搭建延迟备份节点。
oplog重放时有一个容易忽略的问题：它会把oplog里记录的所有操作在目标实例上重新执行一遍，因此目标实例必须具备写入权限，并且最好不要在业务峰值执行，否则会造成额外负载。如果备份目录下有oplog.bson文件，恢复时加上--oplogReplay即可。示例：mongorestore --oplogReplay --drop /data/backup/mydb。需要注意的是，oplog重放只对mongodump生成的oplog文件有效，如果只是普通BSON备份没有oplog，加了该参数反而可能报找不到oplog文件。
索引构建对恢复速度影响很大。mongorestore默认会在所有数据导入完成后开始重建索引，对于包含大量索引的集合，这个过程可能比数据导入本身还要长。可以通过--numInsertionWorkersPerCollection参数调整每个集合的并发插入线程数，提高写入吞吐，但调太高会占用更多内存和CPU。另一个思路是先不带索引恢复数据，再手动执行createIndexes，这样可以在业务低峰期分批创建索引，减少对线上实例的压力。
四、常见报错与恢复优化建议
恢复过程中最常遇到的错误包括认证失败、重复键冲突、命名空间不匹配和文件格式不兼容。认证失败通常是连接串里的认证数据库写错，比如账号在admin库中创建，但连接串却写成了test库，这时把--uri中的认证数据库改成admin即可。重复键冲突前面已经提到，加--drop可以解决，但在生产库执行前务必确认备份可用，否则会删除现有数据。
有时候恢复命令执行到一半中断，比如网络抖动或磁盘写满，重新执行时已经恢复的集合会出现数据重复或冲突。建议先查目标库中已恢复的集合状态，必要时手动清理后再恢复，或者继续使用--drop让工具自动处理。对于超大数据量，推荐先在一个临时库中完成恢复和校验，再通过同步或切换的方式发布到生产环境，避免恢复过程直接影响线上读写。
日常使用中还应把备份和恢复流程做成脚本并定期演练。脚本里可以把命令写成这样，统一管理参数。
#!/bin/bash # MongoDB restore script URI="mongodb://restoreuser:restorepass@localhost:27017/admin" BACKUP_DIR="/data/backup/mydb" LOG_FILE="/var/log/mongo_restore.log" mongorestore --uri="$URI" \ --gzip --drop --oplogReplay \ --numInsertionWorkersPerCollection=4 \ "$BACKUP_DIR" >> "$LOG_FILE" 2>&1
脚本中>>表示追加输出到日志，2>&1表示把错误输出也写入同一文件。Windows下的bat脚本可以写成类似形式，注意反斜杠路径和换行符的区别。把恢复命令固化下来，既能减少手工输入错误，也方便在紧急情况下快速执行。
