Мне нужен совет по передовой практике, касающийся аварийного восстановления MongoDB в среде, размещенной на AWS.
На данный момент наша установка довольно стандартна, набор реплик из 3 серверов (1 первичный, 1 вторичный и 1 арбитр), тома mongo на первичном и вторичном серверах поддерживаются EBS. Все в одном регионе и в нескольких зонах доступности. В конце концов нам нужно будет охватить регионы, но это обсуждение на другой день.
Совет по резервному копированию, который я видел в документации Mongo, говорит о снимках состояния EBS (которые достаточно легко автоматизировать). Однако, если случится катастрофа, они не вернут нас во времена неудач.
Я ищу наиболее надежную стратегию. До второй скорость защиты данных и восстановления системы после сбоя важнее цены. Позже мы сможем оптимизировать цену.
Заранее благодарим за все предложения ...
Во-первых, если вы сделаете снимок, он будет включать журнал операций - журнал операций - это просто ограниченная коллекция, находящаяся в локальной базе данных. Моментальные снимки вернутся к определенному моменту времени, и если у вас включено ведение журнала (оно включено по умолчанию), вам не нужно делать ничего особенного, чтобы моментальный снимок работал в качестве резервной копии.
Единственное абсолютное требование - снимок состояния EBS должен быть достаточно свежим, чтобы соответствовать вашим требованиям. oplog window - то есть последняя (самая последняя) операция, записанная в журнале операций резервного копирования моментального снимка, также должна быть в журнале операций текущего основного, чтобы они могли найти общую точку. Если это так, это будет работать примерно так:
mongod запускает, ищет (и применяет) все соответствующие файлы журналаЕсли моментальный снимок недостаточно свежий, его можно отбросить - без общей точки в журнале операций вторичный снимок должен будет повторная синхронизация с нуля тем не мение.
Чтобы ответить на ваши конкретные вопросы:
Нужно ли мне записывать журналы операций и использовать их вместе для восстановления после сбоя?
Как объяснялось выше, если вы делаете снимок, вы уже создаете резервную копию журнала операций.
Должен ли я запускать другой экземпляр в наборе реплик специально для резервного копирования и снимка, а не делать снимки основного и дополнительного? Если да, то мы вернулись к проблеме oplog, не так ли?
Нет никаких проблем с oplog, кроме той общей точки / окна, о которой я упоминал выше. Некоторые люди предпочитают учиться в средней школе (обычно скрытый) с этой целью, чтобы избежать увеличения нагрузки на обычный узел. Примечание: даже скрытый член получает голос, поэтому, если вы добавили его в целях резервного копирования, вы можете удалить арбитра из своей конфигурации, и у вас все равно останется 3 голосующих члена.
Должен ли я сделать снимок каждого тома реплики и полностью полагаться на набор реплик, чтобы покрыть время между отказом и последним снимком?
Каждый член набора реплик должен быть идентичным - данные одинаковы, любой вторичный может стать первичным и т. Д. - это не ведомые устройства, каждый член набора реплик содержит полный журнал операций и все данные.
Таким образом, создание нескольких моментальных снимков (при условии, что вы доверяете процессу) будет избыточным (конечно, вам может потребоваться эта избыточность). И да, вся цель функциональности набора реплик состоит в том, чтобы гарантировать, что вам не нужно принимать чрезвычайные меры для использования вторичного устройства таким образом (конечно, с учетом приведенных выше предостережений).