Дамп и восстановление базы данных mongo без команды mongodump

Мне нужен способ создать моментальный снимок для конкретной базы данных mongo и иметь возможность воссоздать эту точную базу данных на другом сервере. Я знаком с командами mongodump и mongorestore, но мне нужен один удобочитаемый файл (или лучше вывести все на стандартный вывод) для всей базы данных, чего mongodump пока не делает, что известно и ожидаемо, и вот почему. У меня есть два связанных вопроса.

Во-первых, создает ли mongodump какие-либо другие важные данные, кроме имен коллекций и индексов (при дампе конкретной базы данных), и если да, то что это? Если я правильно помню, монго может не понравиться дампы, сделанные в разных версиях, что тоже может быть проблемой, это правда?

Во-вторых, если я вручную извлеку имена коллекций и индексную информацию, сохраню их в json моего собственного формата, а затем восстановлю на другом сервере, будет ли этого достаточно для создания идентичной базы данных или чего-то не хватает?


mongodb mongorestore mongodump
person Ian Bytchek    schedule 25.02.2015    source источник
comment
Проверьте команду mongoexport. Он экспортирует данные в файлы CSV, TSV или JSON.   -  person Abhay PS    schedule 25.02.2015
comment
Вы проверяете команду mongoexport и читаете, что она делает и чем отличается от mongodump…   -  person Ian Bytchek    schedule 25.02.2015

Ответы (1)


arrow_upward
2
arrow_downward

Во-первых, создает ли mongodump какие-либо другие важные данные, кроме имен коллекций и индексов (при дампе конкретной базы данных), и если он делает, то что это?

mongodump создает двоичную резервную копию ваших данных, включая определенные типы BSON, используется для полей. Дополнительные экспортируемые метаданные включают параметры коллекции (если вы изменили какие-либо значения по умолчанию) и определения индексов. Вы можете увидеть эту дополнительную информацию в *.metadata.json файлах, созданных mongodump.

Если я правильно помню, монго может не понравиться дампы, сделанные в разных версиях, что тоже может быть проблемой, это правда?

Как правило, вы должны иметь возможность воспроизводить старые дампы с более новыми версиями mongorestore. Некоторые старые версии mongodump могут не экспортировать все метаданные коллекций, которые вы ожидаете, поэтому общий совет состоит в том, чтобы mongodump использовать как минимум ту версию сервера mongod, на которой вы работаете, если не новее. Одним из таких примеров может быть mongodump до версии 2.2, которая не создавала информацию metadata.json, поэтому вам пришлось бы вручную обеспечивать индексы и параметры сбора.

Во-вторых, если я вручную извлеку имена коллекций и индексную информацию, сохраню их в json моего собственного формата, а затем восстановлю на другом сервере, будет ли этого достаточно для создания идентичной базы данных или чего-то не хватает?

Предполагая, что вы воссоздаете все параметры коллекции и индекса (и правильно примените их при создании новых коллекций), ваша база данных будет похожа на удаленном сервере, но, вероятно, не будет идентичной.

Основное отличие будет заключаться в целостности типов для полей (хотя это может не иметь значения для вашего варианта использования). BSON поддерживает более широкий набор типов данных, чем JavaScript. Например, JavaScript имеет один тип Number, а BSON поддерживает int32, int64 и double.

Если ваш процесс резервного копирования/восстановления учитывает это, используя что-то вроде MongoDB Extended JSON для представления дополнительных типов вы, вероятно, можете сделать две базы данных более согласованными.

person Stennie    schedule 19.03.2015
comment
Это идеально. Я не знал о роли метаданных здесь, я посмотрю на это глубже. Большое спасибо! - person Ian Bytchek; 20.03.2015
comment
Еще одно быстрое замечание, правильно ли я понимаю, что типы относятся к конкретным документам, а не к коллекциям вообще, и то, что хранится в метаданных? - person Ian Bytchek; 20.03.2015
comment
Нет, metadata.json предназначен только для воссоздания коллекции с теми же параметрами и индексами. Параметры сбора — это то, что вы должны передать db.createCollection() или collMod. Типы полей в документах хранятся в каждом документе. - person Stennie; 20.03.2015
comment
@IanBytchek Кроме того, мне любопытно, почему у вас есть требование удобочитаемого формата для дампа. Я бы использовал mongodump для резервного копирования, а не дублировал усилия по разработке собственного решения. Вы можете использовать инструмент bsondump, входящий в состав инструментов командной строки MongoDB. для преобразования BSON в удобочитаемый формат, если это необходимо. - person Stennie; 20.03.2015
comment
Это не требование, это предпочтение. Я играю, собирая проект, который выполняет миграцию базы данных как для sql, так и для mongo. Сравнивая оба, с базами данных sql вы можете сбросить все в один файл, который затем можно сравнить с другими дампами. С монго не все так просто. Я некоторое время хранил базовую схему mongo (коллекции и индексы) в отдельных восстанавливаемых файлах json, она работает довольно хорошо, и их легко сравнивать. Теперь я пытаюсь сделать это систематическим и выяснить, будет ли этот подход охватывать другие, более сложные случаи. - person Ian Bytchek; 20.03.2015
comment
Итак, действительно было бы идеально, если бы дамп монго позволял отправлять весь вывод прямо в стандартный вывод. Я знаю, что в jira есть запрос на это, но это не простая настройка и не высокий приоритет. Я также согласен с тем, что изобретать велосипед - глупая идея, но с mongo он настолько чистый и простой в php, что я не понимаю, почему бы не использовать его в качестве начальной реализации только для схемы. Я буду дальше изучать дамп монго, поскольку это явно правильный способ сделать это. Буду признателен, если у вас есть какие-либо другие советы по этому поводу. - person Ian Bytchek; 20.03.2015
comment
@IanBytchek Вы заинтересованы в отслеживании изменений данных + схемы или только в схеме? Я не думаю, что mongodump отправка вывода на стандартный вывод поможет вашему варианту использования, так как вывод все равно будет BSON (который является двоичным). Я также думаю, что различия в схемах лучше отслеживать вместе с развертыванием вашего приложения, а не выводить их из данных. Если вы хотите иметь согласованную схему (или требуемые данные, такие как таблицы поиска), вы всегда можете использовать подход с дельта-миграциями, но вместо дельта SQL вы должны использовать дельты JS. Дельты миграции можно проверить в системе контроля версий. - person Stennie; 20.03.2015
comment
@IanBytchek Я не пробовал никаких конкретных библиотек миграции для PHP, но их количество зависит от ваших предпочтений и используемых вами фреймворков, например: mongodb-migrations, PHP Mongo Migrator, Yii2 Migrations< /а>. - person Stennie; 20.03.2015