Как выбирается mon go db primary при перезапуске среды?

Question

Я установил кластер mon go с 3 серверами, например A, B, C. Мое приложение записывает много данных в БД, поэтому размер журнала операций всегда очень велик.

При перезапуске среды сервер A является основным (мы всегда запускаем rs.add (a), rs.add (B), rs.add (C) на A), тогда Сервер C становится основным по причине xyz - может быть из-за перезагрузки сервера или временной потери соединения. Затем приложение записало данные на сервер C, а сервер A все еще пытается синхронизироваться c с сервером C.

Теперь среда перезапущена, я понимаю, что сервер C должен быть выбранным в качестве основного. Однако сервер A выбран в качестве основного.

Не могли бы вы объяснить причину, по которой сервер A выбран в качестве основного.

Answer 1

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

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

Answer 2

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

Набор реплик с 3 узлами должен иметь по крайней мере 2 узла в сети, чтобы выбрать основной, и процесс выбора будет отдавать предпочтение узлам с самой последней меткой времени.

Если узлы A и B подключились к сети немного быстрее, чем C, они могли бы завершить выбор до того, как C станет доступным.

В этой ситуации, если вы использовали большинство операций записи, не было бы потери данных поскольку либо A, либо B также будут содержать все, что было записано и подтверждено C.

Однако, если вы использовали озабоченность записи с w:1 или w:0, могут быть записи, которые C признал, что ни A, ни B не содержат. Когда A и B подключены к сети, они все равно выберут первичный, потому что никто ничего не знает о дополнительных данных на C. Когда C становится доступным, если были какие-либо записи, C должен будет выполнить откат, чтобы участвовать в наборе реплик.

Что касается того, почему сервер A стал основным в вашем кластере, проверьте журналы mongod. В современной версии MongoDB информация о выборах регистрируется, поэтому вы сможете определить, какие узлы участвовали в выборах и какие узлы проголосовали за сервер A.