"nearest" Read Preferences,

In “Read Concern and Read Preferences” lab exercise the question is when 2 out of 3 nodes of the replica set are down “Which of these readPreferences will allow you to read data from this [remaining] node?”. The only remaining node will be a secondary even if it were the replica set primary to begin with.

The correct answer is considered to be all except the “primary” itself.

I’m questioning the “nearest” choice. I don’t consider that to be one of the correct answers. That “nearest” node could be one of the 2 down nodes which happened to be the nearest because it had the least network latency WHEN IT WAS UP. The remaining node could have originally had the worst network latency. Wouldn’t the read fail because the OLD “nearest” is unreachable now. Just as if we had “primary” as the read preference and it is no longer a primary.

Hi Behnam, good question, I found this:
https://docs.mongodb.com/manual/core/read-preference-mechanics/

nearest :
1- The driver assembles a list of eligible members (primary and secondaries). maxStalenessSeconds and tag sets can further limit the eligibility of the members.
2 - If the list of eligible members is not empty, the driver determines which eligible member is the “closest” (i.e. the member with the lowest average network round-trip-time) and calculates a latency window by adding the average round-trip-time of this “closest” server and the localThresholdMS [1]. The driver uses this latency window to pare down the list of eligible members to those members that fall within this window.
3 - From this list of eligible members that fall within the latency window, the driver randomly chooses an eligible member.

and also this:

…Every 10 seconds (3.2) driver sends a heartbeat to measure network response time(last_RTT)…

Teo

Thanks for the explanation Teo. The reason I believe “nearest” is not one of the correct answers to that lab question is that if within the 10 seconds within which the driver fails to get the node response from the its heartbeat (because the “nearest” node is down now) it still considers the node to be up and will send read/writes to it which will fail.