Резервное копирование базы данных MongoDB с помощью снапшотов

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

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

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

Требования

• Сервер Ubuntu 16.04, настроенный по этому мануалу.
• База данных MongoDB (можно настроить по мануалу Установка MongoDB в Ubuntu 16.04). Предполагается, что вы используете MongoDB 3.2+ с механизмом хранения по умолчанию WiredTiger и включенным журналированием.
• Функция создания снапшотов у вашего хостинг-провайдера.
• Кроме того, чтобы использовать это руководство, важно, чтобы каталог dbpath (каталог, содержащий файлы данных, по умолчанию /var/lib/mongodb) был связан с одним томом блочного хранилища.

1: Проверка установки MongoDB

Для начала нужно убедиться, что MongoDB поддерживает журналирование.

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

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

Откройте файл /etc/mongod.conf в текстовом редакторе:

nano /etc/mongod.conf

Найдите в нем такой блок:

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

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

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

2: Создание тестовых данных

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

Если же у вас уже есть данные в БД, вы можете пропустить этот раздел.

Для начала нужно запустить оболочку MongoDB:

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': 'Mario's Pizzeria'})

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

WriteResult({ "nInserted" : 1 })

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

Теперь запросите список коллекций:

show collections

Вы увидите новую коллекцию:

restaurants

3: Создание снапшота

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

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

Итак, войдите в свой аккаунт на хостинге и выберите функцию снапшотов в меню.

Примечание: Хотя обычно перед созданием снапшотов рекомендуется остановить сервер, в среде производства это не всегда возможно. Журналирование в MongoDB обеспечивает согласованные и достоверные снапшоты, даже если во время их создание БД и сервер не были остановлены.

Дайте вашему снапшоту описательное имя и запустите копирование.

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

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

4: Восстановление снапшота MongoDB

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

Вернитесь в меню снапшотов и найдите там ваш новый снапшот.

В меню можно создать новый сервер на основе данного образа.

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

Вы можете проверить работу MongoDB с помощью systemctl:

sudo systemctl status mongod
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 не запустился, сначала нужно удалить файл lock, а затем запустить сервис:

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

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

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

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

mongo

Вы увидите командную строку оболочки:

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

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

5: Проверка целостности данных

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

Примечание: Команда 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, обратитесь к официальному мануалу.