TOC

Как сделать резервную копию MongoDB с помощью снимков дроплетов

Вступление

Регулярное резервное копирование базы данных является важным шагом в защите от непреднамеренных событий потери данных. В целом, существует две широкие категории резервных копий: резервные копии на уровне файловой системы («физические») и логические резервные копии. Резервные копии на уровне файловой системы включают моментальный снимок базовых файлов данных в определенный момент времени и позволяют базе данных полностью восстанавливать себя, используя состояние, записанное в моментальных снимках файлов. Логические резервные копии включают использование инструмента (например, mongodump илиpg_dump) для экспорта данных из базы данных в файлы резервных копий, которые затем восстанавливаются с помощью соответствующего инструмента восстановления (например, mongorestore илиpsql <).

В этом руководстве мы продемонстрируем, как выполнить резервное копирование работающей установки MongoDB на уровне файловой системы с помощьюDroplet Snapshots. Кроме того, мы расскажем, как выполнить восстановление из снимка.

Note: Как подробно описано в резервных копиях DigitalOceanguide, при использовании моментальных снимков Droplet наблюдается некоторое влияние на производительность, особенно в сильно загруженных базах данных. Вы должны сначала протестировать эту процедуру, используя непроизводственную базу данных с имитацией нагрузки, чтобы убедиться, что этот метод будет работать в вашем производственном развертывании.

Предпосылки

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

В этом руководстве предполагается, что у вас установлен MongoDB 3.2+ с использованием стандартного механизма хранения WiredTiger с включенным ведением журналов. Кроме того, для использования этого руководства важно, чтобы каталогdbpath (каталог, содержащий файлы данных, по умолчанию/var/lib/mongodb) был сопоставлен с одним томом. Если вы не подключили дополнительные тома блочных хранилищ к своей капле, вы можете следовать этому руководству.

После того, как вы вошли в Droplet и запустили MongoDB, вы готовы к работе.

[[step-1 -—- verify-your-mongodb-setup]] == Шаг 1. Проверьте настройки MongoDB

Сначала мы проверим, включено ли ведение журнала.

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

Если вы следовали приведенному выше руководству, ведение журнала будет включено по умолчанию. Чтобы подтвердить, что это так, мы можем проверить файл конфигурации MongoDB.

Откройте/etc/mongod.conf с помощью вашего любимого текстового редактора, например, nano: 

nano /etc/mongod.conf

Вы должны увидеть следующий блок:

/etc/mongod.conf

# Where and how to store data.
storage:
  dbPath: /var/lib/mongodb
  journal:
    enabled: true
#  engine:
#  mmapv1:
#  wiredTiger:

Это указывает на то, что ведение журнала было включено. Если вы используете MongoDB 3.2+, механизм хранения по умолчанию - WiredTiger (MMAPv1 был исходным механизмом хранения MongoDB).

Теперь мы вставим несколько фиктивных данных, чтобы протестировать процедуру резервного копирования и восстановления.

[[step-2 -—- insert-test-data]] == Шаг 2 - Вставьте тестовые данные

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

Сначала подключитесь к работающей базе данных с помощью оболочки MongoDB: 

mongo

Вы должны увидеть следующую подсказку оболочки Mongo: 

MongoDB shell version: 3.2.19
connecting to: test
Server has startup warnings:
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten]
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten]
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2018-02-16T02:40:13.071+0000 I CONTROL  [initandlisten]
>

По умолчанию оболочка использует базу данныхtest.

Перечислим коллекции, присутствующие в базе данныхtest: 

show collections

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

Давайте вставим документ в фиктивную коллекциюrestaurants, которую мы создадим одновременно: 

db.restaurants.insert({'name': 'Sammy's Pizzeria'})

Вы должны увидеть следующий вывод: 

WriteResult({ "nInserted" : 1 })

Это указывает на то, что операция вставки прошла успешно. Поскольку коллекцииrestaurants ранее не существовало, она была создана одновременно.

Давайте еще раз перечислим коллекции: 

show collections

Теперь мы видим нашу недавно созданную коллекциюrestaurants: 

restaurants

Теперь, когда мы сохранили некоторые образцы данных в базе данных, мы готовы их сохранить.

[[step-3 -—- snapshot-the-mongodb-droplet]] == Шаг 3 - Снимок капли MongoDB

Чтобы выполнить резервное копирование, мы воспользуемся DigitalOceanDroplet Snapshots. Снимки капли позволяют нам создавать изображение капли в момент времени, когда был снят снимок. Этот образ затем может быть восстановлен в новую каплю, где могут выполняться дальнейшие операции восстановления.

Учитывая, что мы используем MongoDB 3.2+ (с WiredTiger и включенным ведением журналов), нам не нужно приостанавливать запись в файловую систему, пока происходит моментальный снимок. Как только мы восстановим образ и запустим базу данных, MongoDB восстановит себя с контрольной точки, а затем воспроизведет операции из файлов журнала, пока не достигнет момента времени, когда произошел моментальный снимок. Если вы хотите продолжить ведение журнала, обратитесь кMongoDB Manual),

Чтобы начать процесс создания моментального снимка,log in to your DigitalOcean account, перейдите в свою каплю MongoDB и щелкните ссылкуSnapshots на боковой панели.

Вы должны увидеть следующее приглашение:

Take Snapshot

Note: Хотя рекомендуется отключить дроплет перед созданием моментального снимка, в производственных развертываниях это не всегда возможно. Функция ведения журнала MongoDB обеспечивает согласованные и достоверные снимки состояния, даже когда база данных и дроплет работают.

Дайте снимку описательное имя и нажмите кнопкуTake Live Snapshot, чтобы начать процесс создания снимка.

Вы должны увидеть следующий индикатор выполнения снимка:

Snapshot Progress

Когда снимок завершится, вы сможете создать новую каплю из изображения или восстановить работающую каплю в состояние, захваченное в снимке.

Теперь мы готовы выполнить восстановление и проверку процедуры резервного копирования.

[[step-4 -—- restore-the-mongodb-droplet]] == Шаг 4. Восстановление капли MongoDB

Теперь мы создадим новую каплю, которая будет восстановлена ​​из изображения, которое мы только что создали. Данные, доступные в нашей базе данных MongoDB, будут такими же, что и на момент создания снимка.

Вернитесь кSnapshots с помощью боковой панели и найдите готовый снимок капли.

Completed Snapshot

ЩелкнитеMore и выберитеCreate Droplet.

Вы попадете в менюCreate Droplet, где сможете создать новую каплю из своего снимка.

Выберите изображение, соответствующее снимку, который вы сделали ранее. В этом случае мы будем использовать изображениеmongo-backup-test.

Choose Image

Завершите настройку капли восстановления и щелкнитеCreate. Как только ваша капля восстановления будет запущена, войдите в нее.

Если вы настроили MongoDB для запуска при загрузке Droplet, он должен теперь работать. Вы можете проверить это с помощьюsystemctl: 

sudo systemctl status mongod

Вы должны увидеть следующий вывод: 

Output● mongod.service - High-performance, schema-free document-oriented database
   Loaded: loaded (/lib/systemd/system/mongod.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2018-02-14 21:14:40 UTC; 4min 53s ago
     Docs: https://docs.mongodb.org/manual
 Main PID: 1302 (mongod)
    Tasks: 19
   Memory: 87.2M
      CPU: 1.802s
   CGroup: /system.slice/mongod.service
           └─1302 /usr/bin/mongod --quiet --config /etc/mongod.conf

Указывает, что все хорошо и MongoDB запущен правильно.

Если MongoDB не запущен, сначала нужно удалить файл блокировки, а затем запустить службу: 

rm /var/lib/mongodb/mongod.lock
sudo systemctl start mongod

Убедитесь, что MongoDB запустился правильно, используяsystemctl status.

Как только MongoDB будет запущен и запущен, он начнет очищаться и восстанавливать свое состояние до того момента, когда произошел моментальный снимок. Это может занять несколько минут, и оболочкаmongo может быть недоступна, пока это не завершится.

Как только сервер станет доступен, мы можем войти в систему с помощью командыmongo: 

mongo

Теперь вы получите приглашение оболочки mongo: 

OutputMongoDB shell version: 3.2.19
connecting to: test
Server has startup warnings:
2018-02-14T21:14:41.923+0000 I CONTROL  [initandlisten]
2018-02-14T21:14:41.923+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.
2018-02-14T21:14:41.923+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2018-02-14T21:14:41.923+0000 I CONTROL  [initandlisten]
2018-02-14T21:14:41.923+0000 I CONTROL  [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.
2018-02-14T21:14:41.923+0000 I CONTROL  [initandlisten] **        We suggest setting it to 'never'
2018-02-14T21:14:41.923+0000 I CONTROL  [initandlisten]
>

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

В качестве дополнительной меры предосторожности мы можем проверить целостность наших коллекций.

[[step-5 -—- check-data-целостность]] == Шаг 5. Проверьте целостность данных

Перед производственным использованием этих данных резервного копирования полезно проверить восстановленные коллекции на наличие недопустимых объектов BSON.

Note: Командаvalidate может работать медленно на очень больших коллекциях. Кроме того, все операции чтения и записи в коллекции будут заблокированы до тех пор, пока командаvalidate не вернется.

В этом примере у нас есть коллекция с именемrestaurants, для которой мы хотим запустить командуvalidate.

В оболочке mongo выполните команду validate: 

db.restaurants.validate({full:true})

Вы должны увидеть аналогичный вывод: 

{
    "ns" : "test.restaurants",
    "nrecords" : 1,
    "nIndexes" : 1,
    "keysPerIndex" : {
        "test.restaurants.$_id_" : 1
    },
    "indexDetails" : {
        "test.restaurants.$_id_" : {
            "valid" : true
        }
    },
    "valid" : true,
    "errors" : [ ],
    "ok" : 1
}

Если вы видитеvalid: true, все аспекты вашей коллекции действительны, и вы можете безопасно использовать данные из этой коллекции в производственной среде.

Заключение

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

Чтобы узнать больше о различных методах резервного копирования базы данных MongoDB, обратитесь кMongoDB manual.

Эта особая техника резервного копирования стала возможной благодаря удобной функции моментальных снимков Droplet. Чтобы узнать больше о снимках капель, обратитесь кSnapshot docs.

Кроме того, вы можете запланировать автоматическое создание этих снимков с помощью функции «Резервное копирование». Чтобы узнать больше о резервном копировании капель, обратитесь кBackups Introduction.

Related