Виды репликации в MongoDB

[devopg]

1) есть ли какая фича балансировки запросов между секондари нодами?
2) если апдейт секондари нод асинхронный. В монго же есть map reduce. Возможно ли такое что запрос возьмет половину данных из секондари1 где всё обновилось, а другую неактульную из секондари2 где апдейт еще не докатился? Или там по принципу на какую ноду попал запрос из той и только той всё будет прочитано
3) можно ли подключать новый секондари ноды на лету?
4) если примари нода стала Арбитром, получается база на запись не работает? Что происходит с запросами на запись?

[kirik]

1. есть, балансировка проиходит на уровне драйвера в приложении (либо на уровне mongos в случае с sharded-cluster). Управляется указанием read preference при запросе, если просто указываем secondaryPreferred, то там юзается раундробин между репликами емнип.
2. на самом деле есть write concern, который определяет минимальное кол-во acknowledgment'ов для успешной записи. Касательно map-reduce — эта операция не распределяется между нодами в реплика-сете (куда пришли, там и сделали)
3. можно подключать/отключать налету. При первом подключении нода перейдёт в режим синхронизации и будет синкаться с мастера, а после завершения досинкается из бинлога (oplog) — тут важно чтобы длины оплога хватило по времени синхронизации.
4. так нельзя) Арбитром не становятся — им рождаются (ну или ручками можно сконвертить).

[Aeugene]

1. У вас есть writecocnern — сколько нод должно записать и то же самое прочитать данные. если стоит majority — данные консистентны
2. в mapreduce так же уже есть writeConcern. Без него конечно это возможно
3. Конечно %)

Предлагаю просто посмотреть видео

[tmaxx]

Почему конфигурация с Арбитром рекомендуемая, она же не fault-tolerant, в отличие от конфигурации А?

Если упадёт Primary или Secondary, то новый Primary конечно выбран будет. Но он будет недоступен для majority-записи по причине отсутствия этой самой majority. Арбитр в неё не входит. Останется только чтение и неконсистентная запись с “w:1”

[Aeugene]

Полностью с вами согласен, не озвучил данный момент для writeConcern «majority»

[devopg]

Так я не понял, кирик ответил что приматри не может стать арбитром, а тмакс наоборот. В общем момент с арбитром не очень ясен.

По остальным вопросам всё понятно.

[kirik]

Не вижу чтобы тмакс говорил что праймари может стать арбитром. Арбитр в схеме с primary+secondary+arbiter нужен только лишь для создания кворума. Такую схему обычно запускают когда в распоряжении имеется ограниченное кол-во ресурсов: 2 «большие» машины под мастер и слейв и одна мелкая под арбитр. В идеальном мире нужно всё-таки стремиться запускать схему master-secondary-secondary, причём не обязательно что третий secondary должен участвовать в выборах, главное чтобы он мог голосовать. Его так же можно сделать отстающей репликой на случай факапа в основной связке мастер-слейв — с него можно будет восстановить данные. Такой а-ля бэкап получается.

[Hett]

Какая-то мало-актуальная статья. Ни слова про write concern и cache pressure. Зато про 20 лет опыта не поленились написать. В целом уровень "немного разобрался как работал реплика-сет до верии 3.0".