У меня кластер MongoDB работает в 3 DC.
DC1 - 3 узла DC2 - 3 узла DC3 - 3 узла
Кроме того, мои приложения запускаются на каждом узле.
Я просматривал документацию MongoDB и перепутал ч / б ближайшие и набор тегов.
https://docs.mongodb.com/manual/reference/read-preference/
Запрос от географически распределенных элементов Если элементы набора реплик являютсягеографически распределенные, вы можете создавать теги реплик на основе местоположения экземпляра, а затем настраивать приложение для запроса ближайших участников.
Например, если тегируются элементы в «восточных» и «западных» центрах обработки данных{'dc': 'east'} и {'dc': 'west'}, ваши серверы приложений в восточном центре обработки данных могут читать от ближайших участников со следующими предпочтениями чтения:
db.collection.find() .readPref ('near', [{'dc': 'east'}]) Несмотря на то, что Ближайший уже предпочитает участников с низкой задержкой в сети, включая тег делает выбор более предсказуемым.
BaСед в моем понимании.Если мы используем ближайший, Driver будет отслеживать задержки (maxStalenessSeconds также), чтобы решить, куда отправлять трафик.Если DC1 перегружен или задержка плохая с DC1, драйвер направит трафик на другой DC.Но если мы используем набор тегов, то мы вынуждены работать с локальным DC, и локальные приложения будут рассматриваться как неработающие, если локальные узлы не работают.Почему мы все еще рекомендуем установить теги, чем ближайшие?
Итак, как драйвер находит время ожидания и maxStalenessSecods?Как рассчитывается задержка?Будет ли он пинговать каждый узел в кластере?Можем ли мы настроить интервал проверки и количество повторных попыток, прежде чем выбирать узлы на основе задержки?