Все данные, сбрасываемые через mongodump, должны быть прочитаны в память сервером MongoDB. Стоит также отметить, что mongodumpвыполняется резервное копирование определений данных и индексов; время на восстановление также может быть значительно больше по сравнению с другими подходами, поскольку mongorestoreпосле загрузки данных потребуется воссоздать любые вторичные индексы.
Как отмечено в документации MongoDB , mongodumpполезно для резервного копирования и восстановления небольших развертываний, но не идеально для создания полных резервных копий больших систем:
При подключении к экземпляру MongoDB mongodump может отрицательно повлиять на производительность mongod. Если ваши данные больше системной памяти, запросы вытеснят рабочий набор из памяти, что приведет к ошибкам страницы.
Автономный сервер ограничивает параметры резервного копирования, если вы также хотите, чтобы развертывание было доступно во время резервного копирования.
Вот несколько предложенных подходов в порядке от минимального до рекомендуемого:
Подход № 1. Использование службы облачного резервного копирования
Для самого простого краткосрочного решения, я бы рассмотрел использование коммерческого сервиса облачного резервного копирования, такого как MongoDB Cloud Manager . MongoDB Cloud Manager обеспечивает непрерывное резервное копирование с запланированными моментальными снимками и политикой хранения (дополнительную информацию см. В разделе « Подготовка к резервному копированию» ). Облачная служба также избавляет вас от необходимости развертывать какие-либо дополнительные серверы / инфраструктуру, поэтому даже если вы планируете сделать это в будущем, это будет полезным краткосрочным решением.
Общий подход будет следующим:
В качестве дополнительного преимущества Cloud Manager также включает в себя агент мониторинга, который может регистрировать историю метрик из вашего развертывания и позволяет настраивать оповещения.
Подход № 2. Преобразование развертывания в набор реплик и резервное копирование из скрытого дополнительного устройства.
Этот подход требует предоставления некоторой дополнительной инфраструктуры, но снимает влияние резервного копирования с вашего основного сервера. Как правило, наборы реплик предоставляются как минимум с тремя участниками для обеспечения высокой доступности и автоматического переключения при сбое, но если ваша единственная цель - резервное копирование, вы можете использовать менее идеальную конфигурацию с двумя серверами.
Общий подход будет следующим:
- Предоставить второй сервер, который будет использоваться для резервного копирования
- Преобразуйте ваш автономный сервер в набор реплик .
- Добавьте ваш сервер резервного копирования в качестве скрытого дополнительного с приоритетом 0 (он никогда не станет основным) и 0 голосов.
- Используйте один из поддерживаемых методов резервного копирования, чтобы создавать резервные копии на скрытом дополнительном устройстве. Способы резервного копирования перечислены в общем порядке рекомендаций:
mongodпредпочтительнее снимки файловой системы (если это поддерживается вашей конфигурацией) или копирование файла (если вы остановились ) mongodump.
- (в идеале) добавьте еще одну вторичную несущую данные, если вам нужны преимущества высокой доступности и отработки отказа конфигурации набора реплик.
Подход № 3. Использование снимков файловой системы (если доступно и уместно)
Менее эффективной стратегией резервного копирования, чем ваша текущая, mongodumpбыло бы использование моментальных снимков файловой системы , при условии, что у вас есть файловая система, которая поддерживает моментальные снимки (и все ваши файлы данных и журналов находятся на одном томе, чтобы вы могли получить согласованный моментальный снимок запуска mongod). Преимущество моментальных снимков файловой системы заключается в том, что не требуется считывать все данные в память mongod, однако моментальные снимки могут оказывать влияние (особенно при создании исходного моментального снимка в занятой системе). Последовательные моментальные снимки являются более эффективными и менее эффективными, но они по-прежнему не являются полным решением для резервного копирования, поскольку моментальные снимки являются локальными для вашего сервера (и на данный момент у вас есть только автономный вариант).
Предостережения
Подходы № 1 и № 2 предусматривают включение репликации для вспомогательных резервных копий. Репликация добавит некоторые дополнительные локальные операции ввода-вывода на ваш основной сервер, поскольку все операции записи отмечаются в специальной ограниченной коллекции, называемой oplog (журнал операций) .
Вы упомянули вероятную потребность в разделении в будущем, но перед этим я бы изолировал вашу рабочую нагрузку MongoDB от других процессов, совместно использующих тот же сервер. Если вы можете изменить свою стратегию резервного копирования на более эффективную, чем mongodump, устранить конкуренцию за ресурсы и записать некоторую базовую историю метрик для проверки ... вы можете обнаружить, что сегментирование еще не требуется.
