[SERVER-22045] MongoDB should crash if a data file is deleted Created: 04/Jan/16  Updated: 05/Oct/18  Resolved: 05/Oct/18

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

Type: Bug Priority: Critical - P2
Reporter: Ricardo Lorenzo Assignee: Asya Kamsky
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
related to SERVER-13961 Move LockState under OperationContext Closed
is related to SERVER-14243 Fix the extent manager file allocatio... Closed
Operating System: ALL
Participants:
Case:

 Description   

During the MongoDB 2.7.x development cycle an invariant check was added to ExtentManager::_getOpenFile to abort the mongod process if a _getOpenFile() call fails.

This invariant check mitigates some avoidable query integrity and failover issues if required MMAP data files are unable to be opened, and should be backported to the 2.6 branch.

The expectation is that a mongod attempting to open missing data files should abort and trigger any normal HA/failover logic; this is particularly important if that node is a config server or replica set primary.

Original Description:

When a file is deleted / or lost, the single process is corrupted but this doesn't cause a process termination. The process continues running providing incomplete information to the queries.

I believe the specific file checks should trigger a fatal assertion instead of letting the process run in a corrupted state.

  • 2.6
  • 3.2 (invariant(false) is triggering the process abortion? if so, this method was not invoked when some tests were performed causing a similar issue)

This is causing issues avoiding the high availability mechanisms to be triggered for config servers and replica sets.



 Comments   
Comment by Asya Kamsky [ 05/Oct/18 ]

Most of the driving use cases for this request were based on MMAPV1 behavior. We believe that Wired Tiger already behaves correctly.

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