-
Type: Task
-
Resolution: Fixed
-
Priority: Major - P3
-
Affects Version/s: None
-
Component/s: None
-
Replication
-
Minor Change
-
v7.0, v6.3, v6.2, v6.0, v5.0
-
Repl 2023-03-06, Repl 2023-03-20, Repl 2023-04-03, Repl 2023-05-01
-
135
Currently, we ignore certain errors when applying oplog in Mode::kRecovering for idempotency (e.g. this). This makes sense for initial sync, eMRC=false and rollback via refetch. But if we are recovering from a stable checkpoint, oplog application should be able to finish without any errors. And we should fassert on oplog application errors like we do in secondary oplog application.
Skip fassert on oplog application failures in selective restore process:
As the first step of selective restore is to start the shard node as a replica set to do oplog application of the snapshot taken for restore, so for selective restore we might still have some oplogs referencing the unrestored collections which will fail with collection see this test.Selective restore process done with --restore flag is enabled, so we need to skip fassert on oplog application failures. (See this PR for implementation)
- is depended on by
-
SERVER-75865 check constraints for prepared transactions for unclean shutdown
- Closed
- is related to
-
SERVER-71490 Move steady state replication constraint relaxation opCounters to logs
- Closed
-
SERVER-75865 check constraints for prepared transactions for unclean shutdown
- Closed
-
SERVER-46221 Remove oplogApplicationEnforcesSteadyStateConstraints parameter and opCounters
- Open
- related to
-
SERVER-21700 Do not relax constraints during steady state replication
- Closed