[SERVER-26569] Change frequency of periodic replicated writes while idle from 10 sec to 500ms Created: 11/Oct/16  Updated: 06/Dec/22  Resolved: 29/Oct/16

Status: Closed
Project: Core Server
Component/s: Replication
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major - P3
Reporter: A. Jesse Jiryu Davis Assignee: Backlog - Replication Team
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
Assigned Teams:
Replication
Participants:

 Description   

If a replica set is idle for several seconds or longer, clients' staleness estimate of secondaries can be very inaccurate. Clients must make an honest staleness estimate to enforce the maxStalenessMS read preference.

achille.brighton's analysis shows the current idle write frequency of 10 seconds (SERVER-23892) allows inaccuracies large enough that a client can think a secondary is too stale to read from, even though the secondary is fresh enough. To ensure we always read from a fresh-enough secondary in an idle replica set, the idle write period should equal the client's minHeartbeatFrequencyMS, defined in the Server Discovery and Monitoring Spec as 500ms.



 Comments   
Comment by A. Jesse Jiryu Davis [ 29/Oct/16 ]

We've resolved instead to require maxStaleness >= heartbeat + idleWriteFrequency, which is large enough that clients won't accidentally exclude secondaries in an idle replica set.

https://github.com/mongodb/specifications/commit/70b554d2e88ee6a76d9595f8174af06d3406dfbf

Comment by Andy Schwerin [ 11/Oct/16 ]

This proposal has the negative effect of more quickly filling the oplog of idle clusters up with "noop" entries, which force out entries containing actual data that a stale node could use to catch up. I believe it would be wiser to raise the minimum "maxStaleMs" value to accommodate the accuracy available with 10s write frequency.

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