В прошлом году я создал производственный кластер mongoDB. У него есть маршрутизатор, 3 сервера конфигурации и 3 шарда (с большой базой данных и распределенными данными между ними). Мы хотели добавить другие сегменты для формирования наборов реплик, но по разным причинам (например, место для хранения) у нас все еще нет. В этой ситуации резервное копирование является головной болью. Я думаю, что mongodump - мой единственный вариант (иначе мне придется все закрыть). но mongorestore вынуждает меня восстанавливать все на одном сервере и только потом заново все шардировать.
Я хотел знать, возможно ли развернуть новый сервер отдельно от остальной части кластера, который получит полные базы данных из кластера, представленного ранее? Это должно быть синхронизировано (асинхронно или синхронно).
Это временное решение, но я не нашел никакой информации в документации или в Интернете ... Это позволит нам иметь готовый сервер на случай, если с нашим кластером что-то случится.
Спасибо.
Я думаю, что mongodump - мой единственный вариант (иначе мне придется все выключить)
Резервное копирование сегментированного кластера с помощью mongodump как правило, это не лучший вариант с точки зрения производственного воздействия, простоты использования или эффективности. При таком подходе вы эффективно экспортируете данные коллекции и определения индексов с помощью mongodump а затем перестроить базы данных в другой среде с помощью mongorestore. Сброс данных может существенно повлиять на производительность / рабочий набор, поскольку все данные были прочитаны через сервер MongoDB; восстановление также может занять больше времени, так как индексы придется перестраивать.
Альтернативные (и менее эффективные) подходы подкрепляются снимки файловой системы или коммерческий сервис, такой как Облачный менеджер MongoDB. Решение для полного резервного копирования должно обеспечивать непрерывное резервное копирование с регулярными снимками состояния и политиками хранения. Например, см. Cloud Manager's Подготовка к резервному копированию руководство.
mongorestore вынуждает меня восстанавливать все на одном сервере и только потом заново все шардировать.
В руководстве MongoDB есть учебные пособия по Резервное копирование сегментированного кластера с помощью дампа базы данных и Восстановление сегментированного кластера с помощью дампа базы данных. Следуя документированному подходу, вам не нужно повторно сегментировать при восстановлении из резервной копии, однако существует несколько шагов для координации согласованного резервного копирования и восстановления каждого из ваших сегментов и метаданных кластера.
Если вы используете mongodump для экспорта всех данных для резервного копирования (вместо выполнения процедуры резервного копирования сегментированного кластера), mongorestore не будет воссоздавать коллекции с параметрами сегментирования. Однако вы можете сначала настроить шардинг и mongorestore в существующие сегментированные коллекции. Например, если вы хотите восстановить одну сегментированную коллекцию, вы можете создать пустую коллекцию с желаемым ключом сегмента, а затем предварительно разделенные куски перед импортом ваших данных.
Я хотел знать, возможно ли развернуть новый сервер отдельно от остальной части кластера, который получит полные базы данных из кластера, представленного ранее? Это должно быть синхронизировано (асинхронно или синхронно).
Вы можете использовать такое решение, как Соединитель Mongo для репликации данных из сегментированного кластера в резервную копию MongoDB. Это гарантирует, что у вас будет еще одно развертывание в режиме ожидания, но не обеспечит обычные требования к резервному копированию, такие как возможность восстановления до предыдущего моментального снимка или на определенный момент времени.
Это временное решение, но я не нашел никакой информации в документации или в Интернете ... Это позволило бы нам иметь готовый сервер на случай, если с нашим кластером что-то случится.
Если вам нужно временное решение, я настоятельно рекомендую использовать коммерческую службу резервного копирования для ваших производственных данных, пока у вас не будет больше времени для оценки альтернатив.
При планировании аварийных ситуаций следует учитывать отказоустойчивость и время резервного копирования / восстановления как данных, так и инфраструктуры:
Для нормальных рабочих проблем (например, сбоев оборудования / сервера) вы должны запланировать соответствующую избыточность и аварийное переключение с использованием наборов реплик для поддержки каждого из ваших сегментов. Члены набора реплик могут быть распределены между несколькими центрами обработки данных и / или географическими регионами в зависимости от ваших требований к аварийному восстановлению и отработке отказа.
Эффективная стратегия резервного копирования подготовит вас к неожиданным ситуациям, когда вам нужно восстановить некоторые или все данные, поскольку эти данные недоступны в вашей производственной среде. В самом крайнем случае потребуется перестроить сегментированный кластер из резервной копии, но более частыми случаями являются случайное удаление или изменение данных из-за ошибки пользователя или программного обеспечения.
Вы должны учитывать такие аспекты, как автоматизация резервного копирования, изоляция резервных копий, цели восстановления (например, моментальные снимки по сравнению с моментом времени), целевые сроки восстановления и влияние на производство, чтобы создать наиболее подходящий план аварийного восстановления для вашего развертывания.
Для получения дополнительной информации я предлагаю прочитать официальный документ MongoDB по Резервное копирование и его роль в аварийном восстановлении.