-
Type: Bug
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: 4.0.10
-
Component/s: Replication
-
None
-
Fully Compatible
-
ALL
-
Repl 2019-08-12, Repl 2019-08-26, Repl 2019-09-09, Repl 2019-09-23, Repl 2019-10-07
This work came out of SERVER-38356. On 4.0, we replay entries from oplog on standalone nodes during startup only if the below conditions are satisfied.
- Cond#1 : recoverFromOplogAsStandalone paramset to true.
- Cond#2 : supportsRecoverToStableTimestamp() returns true.
- Cond#3 : getRecoveryTimestamp() returns a non-empty timestamp.
When enableMajorityReadConcern(EMRC) is false, supportsRecoverToStableTimestamp() returns false. If it's true, then supportsRecoverToStableTimestamp returns true. So, incase if the node was originally started with EMRC true and restarted as standalone with EMRC false + recoverFromOplogAsStandalone set to true, then the wiredTiger storage engine starts from the stable checkpoint(/recovery timestamp). This means, we should replay the oplog entries from stable checkpoint to top of the oplog. But, because cond#2 returns false for EMRC false, we don't replay oplog entries.
On 4.2, its not a problem, as cond#2 is replaced by supportsRecoveryTimestamp() which always return true for wiredTiger regardless of EMRC value. Basically cond#3 is the one which determines what checkpoint we started from. If we started from a stable checkpoint, then getRecoveryTimestamp() returns a non-empty timestamp value. Else, for unstable checkpoint, the recovery timestamp is empty. So, we should implement the similar thing on 4.0 (i.e, cond#2 should be replaced by supportsRecoveryTimestamp()).
- related to
-
SERVER-38356 Forbid dropping oplog in standalone mode on storage engines that support replSetResizeOplog
- Closed