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
-
SERVER-89272 Investigate why the config.shards insert on initial sync node in config shard doesn't have commit timestamp
-
- Blocked
-
-
-
- Blocked
-
-
-
- Closed
-