-
Type: Task
-
Resolution: Unresolved
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Replication
In Server we have too many knobs for enabling constraints. And it’s unclear which constraints each knob is responsible for. Additionally, if the knobs have overlapping constraint list, it’s unclear which knobs will override others.
For example, say I would like to enable the index constraints. As per this method comment, setting OperationContext::_enforceConstraints true will enable the index key constraints. And, it's unclear if we need to enable the server parameter oplogApplicationEnforcesSteadyStateConstraints as well. Moreover, in In the oplog application code, we call ReplicationCoordinatorImpl::shouldRelaxIndexConstraint() which doesn’t even check the opCtx or the server parameter, it has it’s own decision making
We should investigate if we can unify those knobs. I am also wondering if we can also simplify OplogApplierUtils::applyOplogBatchCommon API. Currently it accepts - oplog application mode, allowNamespaceNotFoundErrorsOnCrudOps, isDataConsistent. Can this be simplified to just accept only the oplog application mode and the oplog application mode is used to decide whether to relax or enforce 'X'constraint?
- is related to
-
SERVER-76159 Image collection entry is not invalidated when update fails during initial sync
- Open
-
SERVER-73661 Improve applyOperation_inlock() API.
- Backlog
- related to
-
SERVER-89948 Refactor oplog application for observability
- Closed