-
Type: Improvement
-
Resolution: Won't Do
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Storage
-
None
-
Storage Execution
-
0
This is related to a recent test failure (linked). We have multiversion coverage that caught an oplogTruncateAfterPoint bug across v4.4 binary shutdown and restart with v4.2 mongod binary. This task is just to make an explicit, so it's easier to diagnose. The test would be inherently racy, though, whether it catches new bugs.
Test:
v4.4
single node replica set with v4.4 binary – so that shutdown will eventually run while still primary
do some
writes against the primary – so that the oplogTruncateAfterPoint gets set
take a checkpoint that now includes the oplogTruncateAfterPoint – so startup recovery will have a checkpoint to use and run the truncate logic on finding the oplogTruncateAfterPoint
shut down the v4.4 mongod primary
v4.2
restart the node with a v4.2 binary
wait for the node to step up to primary – so that we know it is up and running, alive still.
Done
- related to
-
SERVER-46984 Stop async updates to the oplogTruncateAfterPoint during primary server shutdown prior to clearing the oplogTruncateAfterPoint
- Closed