Подготовка к бедствию MongoDB на AWS

Я ищу советы по передовой практике, касающиеся аварийного восстановления MongoDB в среде AWS.

На данный момент наша установка довольно стандартна, набор реплик из 3 серверов (1 первичный, 1 вторичный и 1 арбитр), тома mongo на первичном и вторичном серверах поддерживаются EBS. Все в одном регионе, распределены по нескольким зонам доступности. В конце концов нам нужно будет охватить регионы, но это обсуждение другого дня.

Совет по резервному копированию, который я видел в документации Mongo, рассказывает о снимках EBS (которые достаточно легко автоматизировать). Однако, если случится катастрофа, они не вернут нас к моменту неудачи.

  • Нужно ли записывать оплоги и использовать их для восстановления после сбоя?
  • Должен ли я раскрутить другой экземпляр в пределах набора реплик, специально предназначенного для резервного копирования и моментального снимка, по сравнению с созданием моментальных снимков основного и дополнительного? Если так, мы вернулись к проблеме оплога, не так ли?
  • Должен ли я делать снимок каждого тома реплики и полностью полагаться на набор реплик, чтобы покрыть время между отказом и последним снимком?

Я ищу самую надежную из доступных стратегий. До второй защиты данных и скорость восстановления системы после сбоя имеют более высокий приоритет, чем цена. Мы можем оптимизировать цену позже.

Заранее спасибо за все предложения...

Источник

1 ответ

Решение

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

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

  1. Вы восстанавливаете вторичный сервер из резервной копии моментального снимка EBS
  2. mongod запускает, ищет (и применяет) любые соответствующие файлы журнала
  3. Затем вторичный соединяется с первичным и находит общую точку в двух оплогах
  4. Любые последующие операции от первичного применяются к вторичному вторичному восстановлению
  5. Как только вторичное устройство достаточно нагоняет, оно переходит в ВТОРИЧНОЕ состояние и резервное копирование завершено

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

Чтобы ответить на ваши конкретные вопросы:

Нужно ли записывать оплоги и использовать их для восстановления после сбоя?

Как объяснялось выше, если вы делаете снимок, вы уже создаете резервную копию оплога.

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

За общей точкой / окном, о которой я упоминал выше, нет проблем с оплогами. Некоторые люди предпочитают иметь дополнительный (обычно скрытый) для этой цели, чтобы избежать добавления нагрузки к обычному узлу. Примечание: даже скрытый участник получает голос, поэтому, если вы добавите его для резервного копирования, вы можете удалить арбитра из вашей конфигурации, у вас все равно будет 3 участника с правом голоса.

Должен ли я делать снимок каждого тома реплики и полностью полагаться на набор реплик, чтобы покрыть время между отказом и последним снимком?

Предполагается, что каждый член набора реплик идентичен - данные одинаковы, любой вторичный сервер может стать основным и т. Д. - это не ведомые устройства, каждый член набора реплик содержит полный журнал операций и все данные.

Таким образом, создание нескольких снимков (при условии, что вы доверяете процессу) будет избыточным (конечно, вы можете захотеть эту избыточность). И да, основная цель функциональности набора реплик состоит в том, чтобы вам не нужно было предпринимать экстраординарные меры для использования вторичного устройства таким образом (с учетом вышеизложенных предостережений, конечно).

Источник
Другие вопросы по тегам