Автор выбрал COVID-19 Relief Fund для получения пожертвования в рамках программы Write for DOnations.
MongoDB — одна из самых популярных систем управления базами данных NoSQL. Она отличается масштабируемостью, отказоустойчивостью, надежностью и удобством в использовании. В этом учебном модуле вы создадите резервную копию, восстановите и перенесете образец базы данных MongoDB.
Импортирование и экспорт базы данных подразумевают работу с данными в формате, приемлемом для чтения, который также совместим с другими программными продуктами. Операции резервного копирования и восстановления MongoDB создают или используют специальные двоичные данные MongoDB, в результате чего не только обеспечиваются согласованность и целостность данных, но и сохраняются специальные атрибуты MongoDB. Таким образом, для переноса данных предпочтительнее использовать процесс резервного копирования и восстановления, если исходные и целевые системы совместимы друг с другом.
Перед выполнением этого учебного модуля необходимо следующее:
Если не указано иное, все команды в этом учебном модуле, для которых требуются привилегии root, должны выполняться пользователем без привилегий root с привилегиями sudo.
Прежде чем продолжить прохождение этого учебного модуля, важно понять некоторые базовые моменты. Если у вас есть опыт работы с другими системами баз данных NoSQL, такими как Redis, вы можете найти некоторое сходство с ними при работе с MongoDB.
MongoDB использует для хранения информации форматы JSON и BSON (двоичный JSON). JSON - это удобный для прочтения человеком формат, идеально подходящий для экспорта и импорта данных. Вы сможете управлять экспортированными данными в этом формате с помощью любого инструмента, поддерживающего JSON, включая простой текстовый редактор.
Пример документа JSON:
{"address":[
{"building":"1007", "street":"Park Ave"},
{"building":"1008", "street":"New Ave"},
]}
С JSON удобно работать, но этот формат поддерживает не все типы данных, доступные в BSON. Это означает, что при использовании JSON возможна так называемая потеря корректности информации. Для создания резервных копий и восстановления, лучше использовать двоичный формат BSON.
Во-вторых, вам не нужно беспокоиться о явном создании базы данных MongoDB. Если база данных, которую вы указываете для импорта, еще не существует, она создается автоматически. Еще лучше обстоят дела со структурой коллекций (таблицы базы данных). В отличие от других СУБД, в MongoDB структура создается автоматически при вставке первого документа (строка базы данных).
В-третьих, в MongoDB операции чтения или вставки больших объемов данных, таких как в задачах этого учебного модуля, могут потреблять много ресурсов процессора, памяти и дискового пространства. Это крайне важно, поскольку MongoDB часто используется для крупных баз данных и больших данных. Самое простое решение этой проблемы — выполнять экспорт и создавать резервные копии в ночное время или в периоды низкой нагрузки.
В-четвертых, согласованность информации может представлять проблему, если у вас загруженный сервер MongoDB, где информация может изменяться при экспорте или резервном копировании базы данных. Одно из возможных решений этой проблемы — репликация, и вы можете использовать его, когда лучше освоитесь с MongoDB.
Хотя вы можете использовать функции импорта и экспорта для резервного копирования и восстановления данных, существуют и лучшие способы обеспечения полной целостности данных в базах данных MongoDB. Чтобы создать резервную копию данных, вам следует использовать команду mongodump
. Для восстановления используйте команду mongorestore
. Давайте посмотрим, как они работают.
mongodump
для резервного копирования базы данных MongoDBВначале поговорим о резервном копировании базы данных MongoDB.
Одним из самых важных аргументов команды mongodump
является аргумент --db
, указывающий имя базы данных, резервную копию которой вы хотите создать. Если вы не укажете имя базы данных, mongodump
создаст резервные копии всех ваших баз данных. Второй важный аргумент — это аргумент --out
, определяющий каталог, в котором будут сохранены данные. Давайте создадим резервную копию базы данных newdb
и сохраним ее в каталоге /var/backups/mongobackups
. В идеальной ситуации все наши резервные копии будут содержаться в каталоге с текущей датой /var/backups/mongobackups/10-29-20
.
Вначале создайте каталог /var/backups/mongobackups
:
- sudo mkdir /var/backups/mongobackups
Затем запустите команду mongodump
:
- sudo mongodump --db newdb --out /var/backups/mongobackups/`date +"%m-%d-%y"`
Результат должен будет выглядеть следующим образом:
Output2020-10-29T19:22:36.886+0000 writing newdb.restaurants to
2020-10-29T19:22:36.969+0000 done dumping newdb.restaurants (25359 documents)
Обратите внимание, что в вышеуказанном пути каталога мы использовали формат date +"%m-%d-%y"
, который автоматически получает текущую дату. Это позволяет нам размещать резервные копии в каталогах вида /var/backups/10-29-20/
. Это особенно удобно для автоматизации резервного копирования.
Теперь у вас имеется полная резервная копия базы данных newdb
в каталоге /var/backups/mongobackups/10-29-20/newdb/
. В этой резервной копии есть все необходимое для правильного восстановления newdb
и сохранения так называемой «корректности».
Как правило, резервное копирование выполняется регулярно, и обычно это делается в периоды наименьшей нагрузки на сервер. Вы можете задать команду mongodump
как задачу планировщика (cron), чтобы она выполнялась регулярно, например, каждый день в 03:03.
Для этого откройте редактор crontab:
- sudo crontab -e
Обратите внимание, что при запуске sudo crontab
вы будете редактировать кроны пользователя root. Рекомендуется сделать именно это, потому что если вы настроите кроны для своего пользователя, они могут выполняться неправильно, особенно если для вашего профиля sudo требуется проверка пароля.
Вставьте в командную строку crontab следующую команду mongodump
:
3 3 * * * mongodump --out /var/backups/mongobackups/`date +"%m-%d-%y"`
В приведенной выше команде мы целенаправленно опускаем аргумент --db
, потому что обычно мы хотим создать резервные копии всех наших баз данных.
Если резервных копий будет слишком много, а базы данных MongoDB будут слишком большими, у вас быстро закончится место на диске. В связи с этим, также рекомендуется регулярно удалять старые резервные копии или сжимать их.
Например, вы можете использовать следующую команду bash для удаления всех резервных копий старше семи дней:
- find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} \;
Аналогично предыдущей команде mongodump
, вы можете добавить эту команду как задание cron. Его следует запускать непосредственно перед началом следующего резервного копирования, например, в 03:01. Для этого снова откройте crontab:
- sudo crontab -e
Вставьте следующую строку:
1 3 * * * find /var/backups/mongobackups/ -mtime +7 -exec rm -rf {} \;
Сохраните и закройте файл.
Выполнение всех задач, описанных на этом шаге, обеспечит надлежащее решение резервного копирования для ваших баз данных MongoDB.
mongorestore
для восстановления и переноса базы данных MongoDBПри восстановлении базы данных MongoDB из предыдущей резервной копии вы получите точную копию информации MongoDB на определенный момент времени, включая все индексы и типы данных. Это особенно полезно, если вы хотите выполнить миграцию ваших баз данных MongoDB. Для восстановления MongoDB мы будем использовать команду mongorestore
, которая работает с двоичными резервными копиями, которые производятся mongodump
.
Давайте продолжим наши примеры с базой данных newdb
и посмотрим, как мы можем восстановить ее с предыдущей резервной копии. Вначале мы укажем имя базы данных с аргументом --nsInclude
. Если использовать newdb.*
, мы восстановим все коллекции. Для восстановления отдельной коллекции, например restaurants
, следует использовать newdb.restaurants
.
Используя аргумент --drop
мы обеспечим предварительное отбрасывание целевой базы данных так, чтобы резервная копия была восстановлена в чистой базе данных. Как последний аргумент мы зададим каталог последней резервной копии, который будет выглядеть примерно так: /var/backups/mongobackups/10-29-20/newdb/
.
Когда вы создадите резервную копию с временной меткой, вы можете восстановить ее с помощью следующей команды:
- sudo mongorestore --db newdb --drop /var/backups/mongobackups/10-29-20/newdb/
Результат должен будет выглядеть следующим образом:
Output2020-10-29T19:25:45.825+0000 the --db and --collection args should only be used when restoring from a BSON file. Other uses are deprecated and will not exist in the future; use --nsInclude instead
2020-10-29T19:25:45.826+0000 building a list of collections to restore from /var/backups/mongobackups/10-29-20/newdb dir
2020-10-29T19:25:45.829+0000 reading metadata for newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.metadata.json
2020-10-29T19:25:45.834+0000 restoring newdb.restaurants from /var/backups/mongobackups/10-29-20/newdb/restaurants.bson
2020-10-29T19:25:46.130+0000 no indexes to restore
2020-10-29T19:25:46.130+0000 finished restoring newdb.restaurants (25359 documents)
2020-10-29T19:25:46.130+0000 done
В примере выше мы восстанавливаем данные на том же сервере, на котором создали резервную копию. Если вы хотите перенести данные на другой сервер, используя эту же методику, вам следует скопировать на другой сервер каталог резервной копии, в нашем случае это /var/backups/mongobackups/10-29-20/newdb/
.
Вы выполнили ряд важных задач по резервному копированию, восстановлению и миграции баз данных MongoDB. Производственный сервер MongoDB нельзя использовать без надежной стратегии резервного копирования, такой как описана здесь.
Thanks for learning with the DigitalOcean Community. Check out our offerings for compute, storage, networking, and managed databases.
This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!