[SERVER-26570] MongoDB Slave Crashed During Replication Created: 11/Oct/16  Updated: 12/Oct/16  Resolved: 12/Oct/16

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

Type: Bug Priority: Critical - P2
Reporter: Oren Bissick Assignee: Kelsey Schubert
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: Text File mongod.log    
Issue Links:
Duplicate
duplicates SERVER-7200 use oplog as op buffer on secondaries Closed
Related
related to SERVER-26415 Make sure to catch up to minValid bef... Closed
related to SERVER-25848 Enforce single sync source during rol... Closed
Operating System: ALL
Participants:

 Description   

Node in replica set crashed during replication with the following error:

2016-10-11T09:33:29.057-0400 I REPL [rsBackgroundSync] Starting rollback due to OplogStartMissing: our last op time fetched: (term: 215, timestamp: Oct 11 00:07:01:1). source's GTE: (term: 216, timestamp: Oct 11 00:07:51:1) hashes: (-3078676073172300872/7746078569620926355)
2016-10-11T09:33:29.057-0400 I - [rsBackgroundSync] Fatal assertion 18750 UnrecoverableRollbackError: need to rollback, but in inconsistent state. minvalid: (term: 216, timestamp: Oct 11 00:07:51:1) > our last optime: (term: 215, timestamp: Oct 11 00:07:01:1)
2016-10-11T09:33:29.057-0400 I - [rsBackgroundSync]

***aborting after fassert() failure



 Comments   
Comment by Kelsey Schubert [ 12/Oct/16 ]

Hi orenbissick,

Thank you for reporting this issue. This behavior will be corrected in MongoDB 3.4 by SERVER-7200. And we are planning backports to MongoDB 3.2 to resolve this issue. Please feel free to watch and vote on SERVER-25848 and SERVER-26415.

As a workaround, I would recommend disabling chained replication as we have observed that this mitigates the issue. To resolve the fatal assertion, please execute an clean resync on the affected secondary.

Kind regards,
Thomas

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