Это действительная стратегия резервного копирования для MongoDB?

11

У меня есть один выделенный сервер с базой данных MongoDB около 10 ГБ. Мне нужно делать ежедневные резервные копии, но у меня не может быть простоев с базой данных. Можно ли использовать набор реплик на одном диске (с 2 экземплярами mongod, работающими на разных портах), и просто перевести дополнительный в автономный режим и выполнить резервное копирование файлов данных во внешнее хранилище, такое как S3 (ведение журнала включено)? Или использование master / slave будет лучше, чем набор реплик?

Это жизнеспособно, и если да, то какие потенциальные проблемы у меня могут быть? Если нет, то как мне понять, как это работает?

backup database-backup mongodb

— Джеймс Симпсон
источник

6

ReplicaSet будет работать в этом сценарии. Однако я не могу сказать, является ли хорошей идеей наличие двух экземпляров MongoDB на одном сервере - это зависит от аппаратного / программного обеспечения сервера и нагрузки.

Чтобы убедиться, что ваш backupузел MongoDB не стал главным, установите для его priorityпараметра значение 0, например

rs.add({_id: 1, host: "localhost:<port>", priority: 0})

ПРИМЕЧАНИЕ : если у вас не может быть простоев, вы ДОЛЖНЫ иметь как минимум 2 основных узла MongoDB в ReplicaSet, см. Статью

— Александр Азаров
источник

2

Одной из стратегий, которые следует рассмотреть, является использование «скрытого» параметра на резервном узле вашего репликационного набора. Из блога MongoDB:

Скрытые серверы не будут отображаться в результатах поиска isMaster (). Это также означает, что они не будут использоваться, если драйвер автоматически распределяет чтения по ведомым. Скрытый сервер должен иметь приоритет 0 (у вас не может быть скрытого первичного сервера). Чтобы добавить скрытого члена, запустите:

rs.add ({"_ id": num, "host": имя хоста, "priority": 0, "hidden": true})

— Трэвис Данн
источник

1

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

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

Хорошей новостью является то, что это должно быть довольно тривиальным

Запросите источник резервной копии, чтобы узнать, какой экземпляр является первичным, а какой - вторичным ( db.isMaster())
Убедить резервный экземпляр к шагу вниз , используя rs.freeze()и rs.stepDown()команду или повторное подключение к вторичному

— Чарльз Хупер
источник

Разве это не вариант установить приоритет 0, как предлагает Александр, чтобы вторичное устройство никогда не становилось первичным?

— Джеймс Симпсон,

Вам нужно будет провести некоторое тестирование, но я не уверен, что вторичный сервер просто перейдет в режим ожидания, если по какой-то причине первичный процесс выйдет из строя. Я всегда хотел, чтобы мои второстепенные лица вступили во владение;)

— Чарльз Хупер

1

>> Ваш вторичный сервер может быть повышен до основного - Как уже упоминалось, установка вторичного устройства на приоритет 0 предотвратит его переключение на главный.

— Jonesome Восстановить Монику

Вы можете подключиться к любому из одноранговых узлов из вашего списка одноранговых узлов (это может быть любой первичный, вторичный, арбитражный или скрытый узел), спросить этого однорангового узла, кто является вторичным ( rs.status()и пройти через него result["members"]), и подключиться к одному из Вторичные, чтобы выполнить резервное копирование.

— yfeldblum