MongoDB- could not find member to sync from

Node logs under Recovery mode, even after restarting:

2018-04-24T12:37:52.915+0530 I REPL [replication-0] We are too stale to use J-DB-02:27017 as a sync source. Blacklisting this sync source because our last fetched timestamp: 5ade01e0:66 is before their earliest timestamp: 5aded094:198 for 1min until: 2018-04-24T12:38:52.915+0530 2018-04-24T12:37:52.916+0530 I REPL [replication-0] could not find member to sync from 2018-04-24T12:37:52.916+0530 E REPL [rsBackgroundSync] too stale to catch up -- entering maintenance mode 2018-04-24T12:37:52.916+0530 I REPL [rsBackgroundSync] Our newest OpTime : { ts: Timestamp 1524498912000|102, t: 68 } 2018-04-24T12:37:52.916+0530 I REPL [rsBackgroundSync] Earliest OpTime available is { ts: Timestamp 1524551828000|408, t: 68 } 2018-04-24T12:37:52.916+0530 I REPL [rsBackgroundSync] See http://dochub.mongodb.org/core/resyncingaverystalereplicasetmember 2018-04-24T12:37:52.916+0530 I REPL [rsBackgroundSync] going into maintenance mode with 0 other maintenance mode tasks in progress 2018-04-24T12:37:52.916+0530 I REPL [rsBackgroundSync] transition to RECOVERING

Here is the status of replica set from primary server

```
WAPRS01:PRIMARY> db.oplog.rs.stats().maxSize
WAPRS01:PRIMARY> rs.status();
{
"set" : "WAPRS01",
"date" : ISODate("2018-04-24T07:17:15.276Z"),
"myState" : 1,
"term" : NumberLong(68),
"heartbeatIntervalMillis" : NumberLong(2000),
"optimes" : {
"lastCommittedOpTime" : {
"ts" : Timestamp(1524498912, 102),
"t" : NumberLong(68)
},
"appliedOpTime" : {
"ts" : Timestamp(1524554235, 160),
"t" : NumberLong(68)
},
"durableOpTime" : {
"ts" : Timestamp(1524554235, 92),
"t" : NumberLo

As I am able to see from your rs.status() , there is secondary replica is showing in RECOVERING state. And as MongoDB jira blog After node goes into RECOVERING due to being too stale to sync from its source, it will never recover even if there is a valid sync source it could use.

As per MongoDB documentation here A replica set member becomes “stale” when its replication process falls so far behind that the primary overwrites oplog entries the member has not yet replicated. The member cannot catch up and becomes “stale.” When this occurs, you must completely resynchronize the member by removing its data and performing an initial sync.

For further your ref here , here , here, here and here

StackExchange Database Administrators Q#204770, answer score: 5