Каков рекомендуемый способ резервного копирования больших наборов данных в MongoDB? Допустим, у нас есть размер данных порядка 10 ТБ - как бы вы это подтвердили?
Мы рассматриваем скрытый, возможно, отложенный узел набора реплик. Задержка защитит нас от случайных падений всей базы данных. Это жизнеспособное решение, и какие другие варианты вы бы порекомендовали изучить?
Благодарность!
Ответы:
При необходимости резервного копирования в 10 ТБ это немного усложняется.
Хотя члены набора отложенных реплик могут обеспечить относительно простой способ помочь вам при случайных операциях, замена подходящих резервных копий не заменяется, так же как RAID не заменяет резервные копии на основе файловой системы.
Это сильно зависит от того, как выглядит ваша установка.
С 10TB, я полагаю, у вас есть какой-то SAN. Самый простой способ резервного копирования MongoDB в этих средах - убедиться, что у вас активирована запись в журнал как в файловой системе, так и в MongoDB, и просто сделать снимок тома SAN одного из вторичных серверов, вероятно скрытого, чтобы убедиться, что ваши операции не работают. не прерывайся Обычно это занимает всего несколько секунд, но, пожалуйста, убедитесь, что у вас достаточно окна журнала репликации. В противном случае может потребоваться повторная синхронизация вторичного устройства.
Я должен не согласиться с RolandoMySQLDBA об использовании mongodump. Прежде всего, это накладывает блокировки на сервер. Хотя они снимаются относительно быстро, просто число блокировок может сложиться и помешать вашим операциям, если только они не выполняются на скрытом узле или если нет предпочтения чтения, попадающего во вторичные. Плюс, это не совсем быстро. Я ожидаю, что он будет работать часами, по крайней мере, скорее всего, он займет больше времени, чем ваше окно резервного копирования. Примечание: всегда запускайте mongodump с --oplogопцией, Также имейте в виду, что mongodump не создает резервные копии индексов, а выполняет операции по созданию индексов. Эти индексы должны быть воссозданы во время восстановления, что может значительно увеличить время, необходимое для этого. По моему опыту, если вам нужно восстановить базу данных, вы хотите иметь ее как можно быстрее. Еще один момент, почему mongodump не подходит для резервного копирования 10 ТБ.
Вы можете сделать снимок LVM на работающем экземпляре mongod при условии, что у вас включено ведение журнала в mongod (и, насколько я знаю, его включение также не повредит и на уровне FS). Тем не менее, снимки LVM имеют некоторые последствия. Во-первых, вам, очевидно, нужно иметь достаточно дискового пространства, чтобы можно было внести изменения во время операций резервного копирования. Позвольте мне уточнить это.
Предположим, у вас есть почасовая скорость изменения 500 ГБ. И что вы хотите сделать резервную копию, прежде чем она будет загружена в какое-то хранилище. Даже при использовании параллельного bzip2 сжатию в 10 ТБ потребовалось бы несколько часов для завершения, просто потому, что вероятным ограничивающим фактором стал бы тот факт, что вы, скорее всего, используете пропускную способность запоминающего устройства. Предположим, что сжатие данных до 2 ТБ займет 2 часа. Таким образом, к настоящему моменту нам потребуется около 2 ТБ + 2 * 500 ГБ свободного дискового пространства, 1 ТБ - для снимка LVM. Это создаст необходимость чрезмерной подготовки вашей файловой системы по крайней мере30%. Если вы хотите иметь надлежащий запас прочности, он может легко увеличиться до 60-70% (20% при коэффициенте использования 0,8 для исходной файловой системы, то же самое для размера снимка плюс пространство, необходимое для самой резервной копии bzip). ). В большинстве производственных сред это было бы неприемлемо, поскольку избыточное выделение ресурсов было бы статическим (вы бы не хотели, чтобы скрипт резервного копирования манипулировал вашим LVM динамически, не так ли?).
Несмотря на то, что резервное копирование MMS имеет ряд замечательных функций (непрерывное резервное копирование, простое восстановление на определенный момент времени), у него есть серьезный недостаток: его цена для крупных развертываний может составлять тысячи. При предполагаемой скорости почасового изменения 500 ГБ для этих 10 ТБ это будет средняя шестизначная сумма для облачных резервных копий . Ежемесячно.
Я бы посоветовал ему воспользоваться корпоративной подпиской на ваши серверы, чтобы иметь право иметь локальный экземпляр MMS, включая резервное копирование.
Вот варианты, которые я бы взял в порядке убывания предпочтений.
Есть два варианта
Если вы не возражаете против простоя, самое простое
service mongod stopСделайте снимок LVM или грубую силу cpпапки данных Mongo на другой диск
service mongod startКонечно, вы не хотите простоев, если 10 ТБ данных находятся на отдельной машине.
Если у вас есть реплика с тремя узлами, используйте один из узлов для резервного копирования
{
"_id" : "myreplica",
"version" : 1,
"members" : [
{
"_id" : 1,
"host" : "10.20.30.40:27017",
"priority" : 2
},
{
"_id" : 2,
"host" : "10.20.30.41:27017"
},
{
"_id" : 3,
"host" : "10.20.30.42:27017",
"priority" : 0,
"slaveDelay" : 3600
}
]
}Используйте узел со "_id' : 3всеми вашими физическими резервными копиями. Поэтому простоев нет. Чтобы получить полночный снимок, вы можете запустить резервное копирование в 1:00, поскольку скрытый узел отстает на 1 час.
Конечно, недостатком является наличие еще двух серверов по 10 ТБ каждый и риску для системного администратора.
Вы можете использовать mongodump для автономной машины, но вы должны ожидать снижения производительности, так как mongodump является клиентской программой, использующей соединение, как и любое другое соединение.
Если вы хотите резервное копирование на определенный момент времени, вы должны использовать
mongodump --oplog Логическая резервная копия BSON будет меньше (особенно сжатой или сжатой), чем физическая резервная копия.
Использование mongodump --oplogлучше всего было бы сделано против скрытого узла. Таким образом, на Мастере не будет никакого снижения производительности.
Я относительно новичок в MongoDB (случайный / случайный MongoDBA). Я надеюсь, что мой ответ поможет.