[DOCS-13981] Documentation for "nearest" read preference is incorrect Created: 11/Nov/20  Updated: 30/Oct/23  Resolved: 13/Jan/21

Status: Closed
Project: Documentation
Component/s: manual, Server
Affects Version/s: None
Fix Version/s: Server_Docs_20231030

Type: Bug Priority: Major - P3
Reporter: Shane Harvey Assignee: Andrew Feierabend (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Participants:
Days since reply: 3 years, 2 weeks, 2 days ago
Epic Link: DOCSP-11701
Story Points: 3

 Description   

Description

The documentation for "nearest" read preference is incorrect, specifically on this line:

Operations read from the member of the replica set with the least network latency, irrespective of whether that member is a primary or secondary.

This is misleading because it makes it seems like "nearest" will always select the server with the lowest network latency but this is not the case. "Nearest" actually selects a server (primary or secondary) in the localThresholdMS latency window at random. So it's even possible that "nearest" will select the server with the highest network latency.

The driver server selection spec explains this behavior and the unfortunate naming pretty clearly:

The term 'nearest' is unfortunate, as it implies a choice based on geographic locality or absolute lowest latency, neither of which are true.

Instead, and unlike the other read preference modes, 'nearest' does not favor either primaries or secondaries; instead all servers are candidates and are filtered by tag_sets and maxStalenessSeconds.

To always select the server with the lowest RTT, users should use mode 'nearest' without tag_sets or maxStalenessSeconds and set localThresholdMS to zero.

To distribute reads across all members evenly regardless of RTT, users should use mode 'nearest' without tag_sets or maxStalenessSeconds and set localThresholdMS very high so that all servers fall within the latency window.

In both cases, tag_sets and maxStalenessSeconds could be used to further restrict the set of eligible servers, if desired.

Scope of changes

Impact to Other Docs

MVP (Work and Date)

Resources (Scope or Design Docs, Invision, etc.)



 Comments   
Comment by Githook User [ 25/Jan/21 ]

Author:

{'name': 'Andrew Feierabend', 'email': 'andrew.feierabend@mongodb.com', 'username': 'andf-mongodb'}

Message: DOCS-13981 clarify read preference nearest
Branch: v4.2.12
https://github.com/mongodb/docs/commit/1f9e5d6446d560bc4fee7def812f35e1284009ba

Comment by Githook User [ 13/Jan/21 ]

Author:

{'name': 'Andrew Feierabend', 'email': 'andrew.feierabend@mongodb.com', 'username': 'andf-mongodb'}

Message: DOCS-13981 clarify read preference nearest
Branch: v3.6
https://github.com/mongodb/docs/commit/72116cd020c0f42b411e1bea1dc1ac9c891e3054

Comment by Githook User [ 13/Jan/21 ]

Author:

{'name': 'Andrew Feierabend', 'email': 'andrew.feierabend@mongodb.com', 'username': 'andf-mongodb'}

Message: DOCS-13981 clarify read preference nearest
Branch: v4.0
https://github.com/mongodb/docs/commit/52225f9db18b5c8f3642efea53ebaf230d6e0a11

Comment by Githook User [ 13/Jan/21 ]

Author:

{'name': 'Andrew Feierabend', 'email': 'andrew.feierabend@mongodb.com', 'username': 'andf-mongodb'}

Message: DOCS-13981 clarify read preference nearest
Branch: v4.2
https://github.com/mongodb/docs/commit/1f9e5d6446d560bc4fee7def812f35e1284009ba

Comment by Githook User [ 13/Jan/21 ]

Author:

{'name': 'Andrew Feierabend', 'email': 'andrew.feierabend@mongodb.com', 'username': 'andf-mongodb'}

Message: DOCS-13981 clarify read preference nearest
Branch: master
https://github.com/mongodb/docs/commit/75f8b5a8dd5a327e883cbd60dd28a34148b5bc70

Comment by Githook User [ 13/Jan/21 ]

Author:

{'name': 'Andrew Feierabend', 'email': 'andrew.feierabend@mongodb.com', 'username': 'andf-mongodb'}

Message: DOCS-13981 clarify read preference nearest
Branch: v5.0
https://github.com/mongodb/docs/commit/a172d094ea58760b66b916bced55b880bd9ae634

Generated at Thu Feb 08 08:09:12 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.