Как выполнить резервное копирование, восстановление и миграцию базы данных MongoDB в Ubuntu 14.04

Прежде чем следовать этому руководству, убедитесь, что вы выполнили следующие предварительные условия:

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

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

Первое, что вы должны знать, это то, что MongoDB использует форматы json и bson (двоичный json) для хранения своей информации. Json - это читаемый человеком формат, который идеально подходит для экспорта и, в конечном итоге, импорта ваших данных. В дальнейшем вы можете управлять экспортированными данными с помощью любого инструмента, поддерживающего json, включая простой текстовый редактор.

Пример документа json выглядит следующим образом:

Пример формата json

С Json очень удобно работать, но он не поддерживает все типы данных, доступные в bson. Это означает, что при использовании json произойдет так называемая «потеря точности» информации. Для резервного копирования и восстановления лучше использовать двоичный файл bson.

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

В-третьих, в MongoDB чтение или вставка больших объемов данных, например, для задач данной статьи, могут быть ресурсоемкими и занимать значительную часть ЦП, памяти и дискового пространства. Это очень важно, учитывая, что MongoDB часто используется для больших баз данных и больших данных. Самым простым решением этой проблемы является запуск экспорта и резервного копирования в ночное время или в непиковые часы.

В-четвертых, согласованность информации может быть проблематичной, если у вас есть занятый сервер MongoDB, где информация изменяется в процессе экспорта или резервного копирования базы данных. Простого решения этой проблемы не существует, но в конце этой статьи вы увидите рекомендации для дальнейшего чтения о репликации.

Хотя вы можете использовать import и export функции для резервного копирования и восстановить ваши данные, есть лучшие способы обеспечить полную целостность ваших баз данных MongoDB. Для резервного копирования ваших данных вы должны использовать команду + mongodump +. Для восстановления используйте + mongorestore +. Давайте посмотрим, как они работают.

Давайте сначала рассмотрим резервное копирование базы данных MongoDB.

Важным аргументом для + mongodump + является + - db +, который указывает имя базы данных, для которой вы хотите создать резервную копию. Если вы не указали имя базы данных, + mongodump + создаст резервную копию всех ваших баз данных. Вторым важным аргументом является + - out +, который указывает каталог, в который будут выгружаться данные. Давайте рассмотрим пример с резервным копированием базы данных + newdb + и сохранением ее в каталоге + / var / backups / mongobackups +. В идеале каждая из наших резервных копий должна храниться в каталоге с текущей датой, например + / var / backups / mongobackups / 01-20-16 + (20 января 2016 г.). Во-первых, давайте создадим этот каталог + / var / backups / mongobackups + с помощью команды:

Тогда наша команда резервного копирования должна выглядеть так:

Успешно выполненное резервное копирование будет иметь следующий результат:

Выход mongodump

Обратите внимание, что в указанном выше пути к каталогу мы использовали + date +"% m-% d-% y "+, который автоматически получает текущую дату. Это позволит нам создавать резервные копии внутри каталога + / var / backups // +. Это особенно удобно, когда мы автоматизируем резервное копирование.

На данный момент у вас есть полная резервная копия базы данных + newdb + в каталоге + / var / backups / mongobackups // newdb / +. В этой резервной копии есть все, чтобы правильно восстановить + newdb + и сохранить его так называемую «точность».

Как правило, вы должны делать регулярные резервные копии, например, ежедневно, и желательно в то время, когда сервер загружен меньше всего. Таким образом, вы можете установить команду + mongodump + как задание cron, чтобы оно выполнялось регулярно, например, каждый день в 03:03. Чтобы выполнить этот открытый crontab, редактор cron выглядит так:

Обратите внимание, что при запуске + sudo crontab + вы будете редактировать задания cron для пользователя root. Это рекомендуется, потому что если вы установите cron для вашего пользователя, они могут не работать должным образом, особенно если ваш профиль sudo требует проверки пароля.

В приглашении crontab вставьте следующую команду + mongodump +:

Окно Crontab

В вышеприведенной команде мы намеренно пропускаем аргумент + - db +, потому что обычно вам нужно создать резервную копию всех ваших баз данных.

В зависимости от размера базы данных MongoDB у вас может скоро закончиться нехватка дискового пространства с большим количеством резервных копий. Вот почему также рекомендуется регулярно чистить старые резервные копии или сжимать их. Например, чтобы удалить все резервные копии старше 7 дней, вы можете использовать следующую команду bash:

Аналогично предыдущей команде + mongodump +, эту команду также можно добавить как задание cron. Он должен запуститься непосредственно перед началом следующего резервного копирования, например в 03:01 Для этого снова откройте crontab:

После этого вставьте следующую строку:

Окно Crontab

Выполнение всех задач на этом шаге обеспечит хорошее решение для резервного копирования ваших баз данных MongoDB.

Восстановив базу данных MongoDB из предыдущей резервной копии (например, из предыдущего шага), вы сможете получить точную копию информации MongoDB, взятой в определенное время, включая все индексы и типы данных. Это особенно полезно, когда вы хотите перенести базы данных MongoDB. Для восстановления MongoDB мы будем использовать команду + mongorestore +, которая работает с бинарной резервной копией, создаваемой + mongodump +.

Давайте продолжим наши примеры с базой данных + newdb + и посмотрим, как мы можем восстановить ее из ранее сделанной резервной копии. В качестве аргументов мы сначала укажем имя базы данных с аргументом + - db +. Затем с помощью + - drop + мы удостоверимся, что целевая база данных сначала удалена, чтобы резервная копия была восстановлена ​​в чистой базе данных. В качестве последнего аргумента мы укажем каталог последней резервной копии + / var / backups / mongobackups // newdb / +. Таким образом, вся команда будет выглядеть следующим образом (замените дату резервной копии, которую вы хотите восстановить):

Успешное выполнение покажет следующий результат:

Выход в монгорестор

В приведенном выше случае мы восстанавливаем данные на том же сервере, где была создана резервная копия. Если вы хотите перенести данные на другой сервер и использовать ту же технику, вам просто нужно скопировать каталог резервного копирования, который в нашем случае + / var / backups / mongobackups // newdb / +, на другой сервер.

Эта статья познакомила вас с основами управления данными MongoDB с точки зрения резервного копирования, восстановления и миграции баз данных. Вы можете продолжить дальнейшее чтение по адресу How для настройки масштабируемой базы данных MongoDB, в которой репликация MongoDB объяснил.

Репликация полезна не только для масштабируемости, но и для текущих тем. Репликация позволяет вам продолжать работу службы MongoDB непрерывно с подчиненного сервера MongoDB, пока вы восстанавливаете главный сервер после сбоя. Частью репликации является также operations log (oplog), в котором записываются все операции, которые изменяют ваши данные. Вы можете использовать этот журнал так же, как вы используете двоичный журнал в MySQL, чтобы восстановить ваши данные после последнего резервного копирования. Напомним, что резервное копирование обычно выполняется ночью, и если вы решите восстановить резервную копию вечером, вам не хватит всех обновлений с момента последнего резервного копирования.