[SERVER-4935] Mark node Recovering when replication lag exceeds a configured threshold Created: 12/Feb/12  Updated: 06/Dec/22  Resolved: 11/Jul/16

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

Type: Improvement Priority: Major - P3
Reporter: Scott Hernandez (Inactive) Assignee: [DO NOT USE] Backlog - Sharding Team
Resolution: Won't Fix Votes: 20
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Documented
is documented by DOCS-9568 Docs for SERVER-4935: Mark node Recov... Closed
Duplicate
is duplicated by SERVER-9319 Allow to disable secondaries when the... Closed
is duplicated by SERVER-11780 Secondary automatically enters Recove... Closed
Related
related to SERVER-12861 Introduce a maxStalenessMS option whe... Closed
related to SERVER-3346 MAX SLAVE LAG - Features to provide a... Closed
is related to SERVER-8476 slaveDelay with Ghostsync Closed
is related to SERVER-4936 Server support for "maxStalenessMS" r... Closed
Assigned Teams:
Sharding
Backwards Compatibility: Minor Change
Participants:

 Description   

Add a replica set member option, or maybe a set-wide option, that when exceeded causes the member to change into Recovering mode. With a threshold like this it will be easier to make sure non-primary client reads never exceed the threshold/stale-ness when using a secondary preferred read preference.

This essentially allows one to set the maximum staleness of any normally used member in replica set. This could also be used after maintenance periods to ensure that a node coming out of maintenance can catch up quickly without taking reads during the recovery period.



 Comments   
Comment by Andy Schwerin [ 11/Jul/16 ]

Closed in favor of SERVER-12861. Missing from that approach is a way to set a cluster-wide default maximum staleness for compliant drivers/applications, but that could be easily emulated by applications storing a configuration in a well-known location, or in the future by the server advertising a standard place for that information.

Comment by Vincent [ 24/Feb/14 ]

This would be great, but I though I could be better on a per query basis: https://jira.mongodb.org/browse/SERVER-12861

Comment by Eliot Horowitz (Inactive) [ 29/Mar/12 ]

@idris - definitely similar, but different in fundamental ways.
this changes the state of the set
the other is just a driver change that can be configured per request

Comment by Idris Mokhtarzada [ 28/Mar/12 ]

This sounds pretty similar to SERVER-3346, though SERVER-3346 seems more like a setting on the driver.

Generated at Thu Feb 08 03:07:23 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.