-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: Replication, Storage
-
None
-
Fully Compatible
-
Execution Team 2020-06-29
-
91
Our internal testing of MongoDB 4.4 using the Jepsen testing methodology is reporting that different members of a replica set have different data at the end of a test.
The issue appeared to start with this drop of WiredTiger - though the failure is sporadic, so that's not a strong indicator that a bug was introduced in that set of changes.
The Jepsen test simulates different failure modes in a distributed system - so it's possible that this failure is related to recovery, rollback to stable or replication rollback via refetch.
We should dig into the failure, and try to find a way to isolate the root cause.
- is depended on by
-
SERVER-49017 Add a test to ensure on startup that the oplog is truncated correctly when the oplogTruncateAfterPoint equals the stable timestamp
- Backlog
- related to
-
SERVER-34091 Oplog visibility rules can cause cappedTruncateAfter to erroneously skip record deletion in WiredTiger
- Closed
-
SERVER-41388 Truncate the oplog after the stable timestamp on startup if the oplogTruncateAfterPoint is earlier in time than the stable timestamp
- Closed