-
Type:
Bug
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Labels:None
-
Storage Execution
-
Fully Compatible
-
ALL
-
v7.0, v6.0, v5.0
-
Execution Team 2023-06-12, Execution EMEA Team 2023-06-26
We currently terminate the process in multiple locations when we detect index inconsitencies:
- Out-of-order keys
- Duplicate keys on non-_id unique index
- Duplicate _id values
- Duplicate keys on unindex
Crashing the process is quite dangerous for many reasons, and should only be done as a last resort. In all of these locations, we should evaluate if we can safely throw an exception and write to the health log. For our testing we can still crash. Additionally, if we were to encounter any of these a key out-of-order issue in validate or dbCheck when scanning an index, this would terminate the process, and would not be particularly useful for understanding the extent of any data corruption.
Instead, we should do what we did in SERVER-71950 and log a warning, write to the health log, and throw an exception. Like what we're doing in SERVER-74793 and SERVER-76231, we should also ensure dbCheck and validate do not fail when they encounter this inconsistency.
- is depended on by
-
SERVER-76978 Ensure dbCheck does not fail immediately when detecting an index inconsistency
-
- Open
-
-
-
- Backlog
-
- related to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-