mongorestore

定义

mongorestore是MongoDB官方工具集中负责数据恢复的命令行实用程序，其作用对象是由配套工具mongodump生成的二进制转储文件^[1]。它通过直接连接正在运行的mongod实例来写入数据，默认在dump目录下寻找备份内容^[4]。

从MongoDB 4.4开始，MongoDB Database Tools与MongoDB Server分开发布并使用独立版本号，初始版本为100.0.0，mongorestore由此从服务器发行包中独立出来^[2]。较早的版本则随服务器一同发布，版本号与服务器保持一致^[5]。

原理

mongodump把集合数据写成BSON文件，把集合选项与索引定义写成同名的.metadata.json文件，两者通常放在以数据库名命名的目录中^[6]。mongorestore按目录结构逐层读取这些文件，先建库建集合，再插入文档，最后依据元数据重建索引^[1][6]。

恢复过程的插入方式可以用下面的流程表示：

$\text{BSON/metadata} \rightarrow \text{mongorestore} \rightarrow \text{mongod 插入文档} \rightarrow \text{重建索引}$

flowchart LR

A["dump 目录（BSON + metadata.json）"] --> B["mongorestore 读取"]

B --> C["连接到 mongod"]

C --> D["创建数据库与集合"]

D --> E["插入文档"]

E --> F["依据元数据重建索引"]

恢复时只执行插入操作，不执行更新或替换；若目标集合中已存在相同_id的文档，mongorestore不会覆盖它^[3]。文档默认可能以随机顺序插入，如需保持顺序可使用--maintainInsertionOrder选项^[3]。

除目录形式外，mongodump与mongorestore还支持存档文件，把多个BSON文件合并为单个文件，也允许从标准输入读取或向标准输出写入，从而支持通过管道在网络间迁移数据^[4]。

发展历程

早期mongorestore随MongoDB Server一同发布，版本号与服务器对应，MongoDB 2.2及之后版本生成的转储格式与更早版本不兼容^[7]。在2.4版本中，mongorestore增加了对SSL连接的支持^[7]。

从MongoDB 4.4起，包括mongorestore在内的MongoDB Database Tools改为独立发布，使用从100.0.0开始的独立版本号，并针对不同操作系统提供分平台的安装包^[2]。

MongoDB 4.2引入了在使用分片事务的分片集群备份中不建议使用mongorestore的限制^[8]。从MongoDB 5.0开始，mongorestore可用于恢复时间序列集合^[3]。

应用

mongorestore最常见的用途是把mongodump产生的逻辑备份恢复到自建MongoDB部署，也可用于将自建部署的数据迁移到托管的MongoDB Atlas集群^[4]。云厂商在提供MongoDB备份下载能力时，同样以mongorestore作为把逻辑备份导入自建数据库的标准方式^[9]。

恢复粒度可以灵活选择：指定备份目录可恢复整份转储，用--db与--collection参数可恢复指定库或集合，用--nsInclude还可以按命名空间筛选，并支持星号通配符^[10]。连接到远程实例时可使用连接字符串，或分别指定主机、端口、用户名与认证数据库^[10]。

在副本集环境中，如果备份时用mongodump的--oplog选项捕获了操作日志，恢复时配合--oplogReplay可以把数据还原到备份结束时刻的状态，实现接近时间点的恢复^[4]。此外，--drop选项会在恢复前删除目标中的同名集合，用于避免与已有数据冲突^[11]。

大库恢复时可通过--numParallelCollections调整并行度以提升速度，也可配合--gzip处理压缩备份^[12]。Amazon DocumentDB等服务也支持用mongorestore把转储数据导入其集群^[13]。

局限

恢复要求源部署与目标部署的MongoDB版本处于同一主要版本，或把特性兼容版本设为相同的值；把转储恢复到更新的部署版本虽然通常可行，但并不被视为升级部署的推荐做法^[3]。工具版本同样需要匹配，若转储格式在版本间发生变化，使用不同版本的mongorestore可能失败或错误恢复数据^[3]。

由于只做插入而不做更新，恢复过程中遇到相同_id的既有文档会产生重复键错误，需要借助--drop等方式处理^[8]。mongorestore不会恢复system.profile集合的数据，但在备份包含该集合时仍可能尝试创建它，因此对权限有额外要求^[3]。

该工具会与运行中的mongod交互并产生额外流量，读取数据时可能把热数据逐出内存，从而影响数据库常规负载的性能，因此官方建议在性能影响不可接受时改用文件系统快照或云端备份方案^[4]。

从备份恢复只能得到备份时刻的快照，备份完成之后发生的写入无法通过恢复找回，因此单靠mongorestore并不能覆盖全部容灾需求^[4]。在存在分片事务的分片集群场景中，它也不适合作为备份策略，官方建议改用能够保证跨分片事务原子性的备份方案^[8]。

参见

• mongodump —— 与mongorestore配套使用的转储工具，负责生成待恢复的二进制备份。

• MongoDB —— mongorestore所服务的文档型数据库系统。

• BSON —— mongodump与mongorestore之间传输数据所用的二进制序列化格式。

• oplog —— 记录副本集写入操作的日志，配合--oplogReplay可用于时间点恢复。

• MongoDB Atlas —— 可用mongorestore向其填充既有数据的托管数据库服务。