Кто-нибудь знает, почему набор реплик mongodb будет иметь первичный и вторичный обмен в довольно быстрой последовательности?

У нас есть 3 сервера mongo, настроенные как реплики, один из которых никогда не может стать основным (резервным). Допустим, mongo1 является первичным, а mongo[2..3] — вторичным. Случайным образом mongo1 не будет доступен для mongo2 и mongo3, в результате чего mongo2 будет выбран в качестве основного. Затем Mongo1 видит это и становится основным. Затем mongo2 и 3 снова видят mongo1 через несколько секунд или около того, и он переизбирается.

Есть ли причина, по которой он так быстро переизбрал mongo1? Оба mongo 1 и 2 имеют одинаковый приоритет.

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

Кроме того, должны ли маршрутизаторы mongodb находиться на сервере приложений или отдельном сервере? В руководстве по mongodb предлагается разместить его на каждом сервере приложений, но каковы преимущества этого способа? Каковы были бы преимущества и проблемы с наличием серверов маршрутизатора между серверами приложений и серверами mongo?

Я должен упомянуть, что это в AWS (ec2), если это имеет значение.

редактировать:

запуск mongo 2.4.6 как набора реплик. Извините за это, я забыл упомянуть эту часть. У них довольно высокая нагрузка. Все экземпляры mongo находятся в одном регионе и в одной зоне доступности в EC2.


person user3874849    schedule 24.07.2014    source источник
comment
Под маршрутизатором mongodb вы подразумеваете процесс mongos? Можете ли вы запустить rs.status() и rs.conf() и добавить вывод к своему вопросу?   -  person John Petrone    schedule 25.07.2014
comment
вот pastebin rs.status и rs.conf pastebin.com/0Gij2Nkv и да, процесс mongos   -  person user3874849    schedule 25.07.2014
comment
Точную проблему можно узнать, проанализировав журналы. Это среда с высокой нагрузкой? Вы пытались повторно синхронизировать вторичные файлы?   -  person Abhay PS    schedule 25.07.2014
comment
Вы используете набор реплик или сегментированный кластер? В конфигурации набора реплик нет отдельного компонента маршрутизатора (шардированный кластер имеет mongos процессов). Не могли бы вы уточнить, что вы имеете в виду под маршрутизаторами? Можете ли вы также предоставить более подробную информацию о развертывании вашего набора реплик: Распределены ли ваши серверы MongoDB географически? Что это за экземпляры AWS? Кроме того, какая версия MongoDB?   -  person Stennie    schedule 25.07.2014
comment
добавил больше информации в исходный пост   -  person user3874849    schedule 25.07.2014


Ответы (1)


  1. Почему вы должны размещать mongos в том же экземпляре, что и ваш сервер приложений?
    Сетевые переходы/задержка. Запрашивать локальный mongos для авторитетного сегмента быстрее, чем делать удаленный запрос — оба подхода затем должны будут получить данные из правильного сегмента.
    Примечание: другие базы данных, такие как Couchbase, избегают компонента mongos/router, чтобы избежать этого. вообще накладные расходы.

  2. Я предполагаю, что вы разделили свои первичные и вторичные серверы на несколько зон доступности? Может сеть немного шатается, хотя так быть не должно? К сожалению, вы мало что можете сделать против отработки отказа, если у вас есть разделение сети — если отработка отказа не произойдет быстро, это приведет к большим окнам отката, которых вы хотели бы избежать. Если только вы не хотите полностью отключить автоматический переход на другой ресурс.
    И узел должен быть переизбран только в том случае, если новый первичный узел потеряет свое большинство. Итак, в вашем случае похоже, что 2 и 3 не могут подключиться к 2. Таким образом, 2 становится новым основным. Но вскоре после этого 1 и 3 не могут соединиться с 2, и, поскольку они имеют большинство, они снова избирают 1 хозяином.

person xeraa    schedule 25.07.2014