![来自 stdin 的 mongorestore](https://linux22.com/image/615492/%E6%9D%A5%E8%87%AA%20stdin%20%E7%9A%84%20mongorestore.png)
在远程服务器上,我有一个名为 mongodump 输出压缩的文件,我假设这个文件名为mongodb.tar.gz
。
里面mongodb.tar.gz
有一个像这样的目录结构:
dump/dbname/
dump/dbname/blogs.bson
dump/dbname/blogs.metadata.json
dump/dbname/editors_choice.bson
dump/dbname/editors_choice.metadata.json
...
有没有办法可以在不下载并在本地解压整个文件的情况下恢复此转储?
我的意思是:
curl http://remoteserver/mongodb.tar.gz | gunzip | mongorestore -d dbname
答案1
您只能通过管道传输包含一个集合的压缩文件。
你可以这样做:
curl http://remoteserver/mongodb.collection.gz | gunzip -c | mongorestore -d dbname -c collectionname -
-c
需要 gunzip 选项以便它将数据写入 stdout,最后一个选项-
是 mongorestore 需要从 stdin 输入的数据。
使用版本 3.0.7 进行测试(不适用于 v2.6.4)。
答案2
答案3
答案4
好吧,我做到了,但效果并不好。我首先做的是提取仅有的来自 tarball 的元数据,因为它们不能直接输入到仅接受 BSON 的 mongorestore 命令中。
提取元数据后,我运行了两次恢复:首先是常规 mongorestore,以文件夹作为参数来恢复元数据。
然后在第二次恢复时,我从之前创建的文件中读取 BSON 文件的文件名,并将每个文件解压到 STDIN,然后将结果通过管道传输到 mongorestore。是的,这很混乱,但嘿,它有效!
要想看到这一令人憎恶的全貌,可以参阅以下代码:https://github.com/datascienceproject2019-codescoop/codescoop-models
以下是脚本https://github.com/datascienceproject2019-codescoop/codescoop-models/blob/master/commands.sh
由于管道传输到 docker exec 太困难,因此恢复脚本位于不同的文件中:https://github.com/datascienceproject2019-codescoop/codescoop-models/blob/master/gh_mongo_scripts/restore.sh
我使用了 Mongo 4.0.6
编辑:但是使用流比直接读取提取的文件要慢得多。所以我这样做可能毫无意义,因为临时提取 26 GB 的额外文件并不是什么大问题。算了。