☰

MongoDB на AWS (EBS): 3 реплики против 2 реплик + арбитр

tag-icon • tag-icon replication mongodb
MongoDB на AWS (EBS): 3 реплики против 2 реплик + арбитр

У нас есть довольно большая база данных Mongo, работающая в AWS. В настоящее время мы работаем с набором реплик с 3 экземплярами. Каждый экземпляр имеет 5 ТБ подключенного хранилища EBS. Это составляет более 1000 долларов в месяц за экземпляр. Помимо этого, у нас есть как рабочая, так и промежуточная среда (скоро появится третья среда «dev»). Кроме того, эти расходы могут резко возрасти в будущем, когда/если мы перейдем на шардированную среду.

Вопрос в том, насколько необходимы 3 реплики в среде AWS?

Ладно, ладно, ладно, я уже знаю ответ: "зависит от обстоятельств". Я ищу совет о том, как лучше всего взвесить компромиссы. Например...

  1. Учитывая, что каждый том EBS уже имеет встроенную тройную избыточность и что восстановление из резервной копии довольно просто, как мне измерить дополнительную отказоустойчивость 2 по сравнению с 3 репликами?

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

  3. Есть ли у кого-нибудь опыт (положительный или отрицательный) работы только с 2 репликами + арбитром?

решение1

  1. Учитывая, что каждый том EBS уже имеет встроенную тройную избыточность и что восстановление из резервной копии довольно просто, как мне измерить дополнительную отказоустойчивость 2 по сравнению с 3 репликами?

Что касается MongoDB, то при наличии только двух элементов, несущих данные, в наборе реплик из трех узлов следует учитывать, что если один из этих элементов, несущих данные, по какой-либо причине недоступен (плановое обслуживание или незапланированный сбой):

  • у вас больше нет активной репликации (остался только один член, несущий данные)
  • ваше развертывание больше не может распознавать проблемы записи выше, чем w:1(например: w:majorityили w:2)

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

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

Если ваш код использует MongoDBнаписать опасениявыше, чем значение по умолчанию ( w:1), вам нужно будет добавитьwtimeoutзначение. Если вы не укажете wtimeoutопцию и уровень беспокойства о записи будет недостижимым, операции записи будут блокироваться на неопределенный срок.

Гарантии AWS по избыточной инфраструктуре обычно распространяются только на сбои в нескольких зонах доступности, поэтому для обеспечения максимальной доступности вам следует также развернуть элементы набора реплик в разных зонах доступности.

  1. Есть ли у кого-нибудь опыт (хороший или плохой) работы только с 2 репликами + арбитр?

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

Помимо этого, у нас есть как производственная, так и промежуточная среда (скоро появится третья среда «dev»).

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

Связанный контент