Предположим, что существует набор реплик из трех узлов: 1 основной P и 2 вторичных S1 и S2. Предположим также, что P и S1 расположены в одном центре обработки данных DC1, а S2 в другом центре обработки данных DC2.
Предположим, что клиент находится в DC1 (то есть в том же центре обработки данных, что и P и S1), а S1 не работает. Куда пойдут запросы клиентов? P или S2 ?
secondaryPreferred выберет вторичный, даже если он дальше (я предполагаю, что S2 имеет более низкий приоритет, потому что он, вероятно, не должен быть основным, поэтому в вашем сценарии S2 является вторичным и что он дальше в смысле задержки).
Вместо этого вы можете использовать наборы тегов для осведомленность о центре обработки данных / географически распределенные участники или < href="http://docs.mongodb.org/manual/reference/read-preference/#nearest" rel="nofollow">nearest read-preference, который выберет ближайший сервер, независимо от независимо от того, первичный он или вторичный.
В большинстве случаев операции считываются из вторичных элементов, но в ситуациях, когда набор состоит из одного первичного элемента (и никаких других элементов), операция чтения будет использовать первичный элемент набора.
Когда предпочтение чтения включает набор тегов, клиент пытается найти вторичного члена, соответствующего указанному набору тегов, и направляет чтение случайному вторичному элементу из ближайшей группы. Если у вторичных серверов нет совпадающих тегов, клиент игнорирует теги и читает данные из основного.
Операции чтения с использованием режимаsecondaryPreferred могут возвращать устаревшие данные.
Я предполагаю, что вы получите данные от S2, так как это то, что вы запросили с суффиксом preferred. Вариант secondary полностью исключает первичный, но в то время как secondaryPreferred позволяет использовать первичный в случае отсутствия вторичных.
Хотя, используя теги для ваших серверов в том же центре обработки данных, вы можете заставить драйвер читать из основного, даже если вторичный присутствует в остальной части набора реплик.
