You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Revert code to parse "idleWritePeriodMillis" from ismaster, and revert
changes that allowed maxStalenessSeconds to be a float. Sync JSON tests
from specs repo.
<p>Clients estimate the staleness of each secondary, and select for reads only those secondaries whose estimated staleness is less than or equal to maxStalenessSeconds. The default is -1, meaning no maximum staleness.</p>
29
+
<p>Clients estimate the staleness of each secondary, and select for reads only those secondaries whose estimated staleness is less than or equal to maxStalenessSeconds. The default is <code>MONGOC_NO_MAX_STALENESS</code>.</p>
Copy file name to clipboardExpand all lines: doc/mongoc_read_prefs_t.page
+7Lines changed: 7 additions & 0 deletions
Original file line number
Diff line number
Diff line change
@@ -61,6 +61,13 @@
61
61
<p>All interfaces use the same member selection logic to choose the member to which to direct read operations, basing the choice on read preference mode and tag sets.</p>
62
62
</section>
63
63
64
+
<sectionid="max-staleness-seconds">
65
+
<title>Max Staleness</title>
66
+
<p>When connected to replica set running MongoDB 3.4 or later, the driver estimates the staleness of each secondary based on lastWriteDate values provided in server isMaster responses.</p>
67
+
<p>Max Staleness is the maximum replication lag in seconds (wall clock time) that a secondary can suffer and still be eligible for reads. The default is <code>MONGOC_NO_MAX_STALENESS</code>, which disables staleness checks. Otherwise, it must be a positive integer at least <code>MONGOC_SMALLEST_MAX_STALENESS_SECONDS</code> (90 seconds).</p>
68
+
<p>Max Staleness is also supported by sharded clusters of replica sets if all servers run MongoDB 3.4 or later.</p>
0 commit comments