It seems there is an issue when an initial sync node attempts to acquire collection locks on a view during oplog replay. The lock acquisition would fail with CommandNotSupportedOnView. This results in updates/deletes not being applied correctly on the initial syncing node, leading to data inconsistency.
To resolve this, we should ensure that the shard server op observer does not run during recovery procedures. It looks like today we skip running the shard server op observer functions only if the node is standalone or primary.
- depends on
-
SERVER-89704 Commonize inRecoveryMode functions
-
- Closed
-
- is related to
-
-
- Blocked
-
-
-
- Blocked
-
-
-
- Closed
-