На удаленном сервере у меня есть файл, который представляет собой сжатый вывод 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
Вы можете передавать по конвейеру только сжатые файлы, содержащие одну коллекцию.
Вы могли сделать:
curl http://remoteserver/mongodb.collection.gz | gunzip -c | mongorestore -d dbname -c collectionname -
В -c необходим параметр gunzip, поэтому он пишет в стандартный вывод, а последний -поэтому mongorestore ожидает ввода от stdin.
Протестировано с версией 3.0.7 (не работает с v2.6.4).
На данный момент это невозможно, по крайней мере, без написания чего-либо самостоятельно. Функция была запрошена как СЕРВЕР-4345 и СЕРВЕР-5190 но есть несколько проблем с немедленной реализацией в зависимости от того, как работают текущие инструменты (т.е. это непросто).
Хотя это только частичный ответ, вы могли бы использовать предохранитель чтобы смонтировать файл .tar.gz после его загрузки.
В поисках прямого ответа на другую часть я спросил вопрос 730494.
Что ж, я сделал это, и это было некрасиво. Я сначала извлек только метаданные из архива, так как их нельзя напрямую передать в команду mongorestore, которая принимает только BSON.
После извлечения метаданных я выполнил два восстановления: сначала обычное хранилище 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 ГБ дополнительных файлов - не такая уж большая проблема. Ну что ж.