Резервное копирование и восстановление MongoDB

Development, Ubuntu | Amber | Комментировать запись

MongoDB – одна из самых популярных систем управления баз данных NoSQL. MongoDB известна своей масштабируемостью, ошибкоустойчивостью, надежностью и простотой использования. В этом мануале вы узнаете, как создать резервную копию БД, восстановить и переместить образец данных MongoDB.

Импорт и экспорт БД подразумевает работу с данными в удобочитаемом формате, совместимом с другими программами. Операции резервного копирования и восстановления, напротив, создают или используют двоичные данные, специфичные для MongoDB – это позволяет сохранить не только согласованность и целостность данных, но и их атрибуты. Таким образом, для перемещения данных обычно рекомендуется использовать резервное копирование и восстановление (если исходная и целевая системы совместимы).

Требования

• Виртуальный сервер (мы используем сервер Ubuntu 20.04, настроенный в соответствии с этим руководством, включая пользователя sudo и брандмауэр).
• Подготовленная к работе установка MongoDB (читайте мануал Установка MongoDB в Ubuntu 20.04)
• Тестовая база данных MongoDB, импортированная согласно мануалу Импорт и экспорт баз данных MongoDB.

В этом руководстве все команды, требующие привилегий root, должны запускаться от имени пользователя с привилегиями sudo (не указано иное).

1: Использование JSON и BSON

Прежде чем продолжить работу с этим мануалом, необходимо разобраться с базовыми понятиями. Если у вас есть опыт работы с другими системами баз данных 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. Для резервного копирования следует использовать команду mongodump. Для восстановления – команду mongorestore. Давайте посмотрим, как они работают.

2: Резервное копирование MongoDB с помощью mongodump

Сначала мы рассмотрим резервное копирование базы данных 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"`

Вы увидите такой вывод:

2020-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, редактор cron:

sudo crontab -e

Обратите внимание, что при запуске sudo crontab вы будете редактировать задания cron для пользователя root. Рекомендуется делать именно так, потому что если вы установите crons для другого пользователя, задачи могут работать некорректно (особенно если ваш профиль 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.

3: Восстановление и миграция MongoDB с помощью mongorestore

После восстановления БД 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/

Вы получите примерно такой вывод:

2020-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.