-
Type:
Improvement
-
Resolution: Fixed
-
Priority:
Major - P3
-
Affects Version/s: None
-
Component/s: Replication
-
None
-
Replication
-
Fully Compatible
-
v8.0
-
Repl 2024-05-27, Repl 2024-06-10, Repl 2024-06-24
This ticket is for the replication team to tighten-up the guarantees of the protocol and API for trailing on-disk state and is to serve as a placeholder and dependency for the recent views related bugs. The description below captures my conversation with lingzhi.deng@mongodb.com and suganthi.mani@mongodb.com.
The current API of onInitialDataAvailable/isDataRecovering is adequate for the near term, but it has a problem very specific to the views catalog since it is tightly coupled with collections. Namely, in the case of FCBIS, the views catalog is loaded from the last consistent (stable) snapshot, but due to the member state of the node at that point, isDataRecovering is still true. This causes the views catalog to not be kept in sync during oplog replay and so the namespaces it contains diverge from the available collections, causing false namespace conflicts.
This ticket is about decouplig isDataRecovering from the member state and making it becomes true immediately after rollback to stable, which will cover both FCBIS and replication rollback.
The changes will also cover the RS_REMOVED state and that will solve SERVER-89272.
Once this work is done, we can recommit the views fixes.
As part of this work we discussed giving better names to the methods to match their meanings more accurately:
- onInitialDataAvailable -> resetInMemoryState
- isDataRecoving -> isInMemoryStateInSync
- duplicates
-
SERVER-91032 ReplicaSetAwareService::onInitialDataAvailable() never called on primary with empty data files
-
- Closed
-
-
SERVER-69017 Clarify interface for initializing in-memory state
-
- Closed
-
- is depended on by
-
SERVER-90305 Ensure Pre-Image Truncate Markers are generated after data is consistent
-
- Open
-
-
SERVER-89272 Investigate why the config.shards insert on initial sync node in config shard doesn't have commit timestamp
-
- Blocked
-
-
SERVER-69017 Clarify interface for initializing in-memory state
-
- Closed
-
-
SERVER-90682 Keep the in-memory status of views up-to-date without reloading them on every operation in FallbackOpObserver
-
- Backlog
-
- is related to
-
SERVER-91032 ReplicaSetAwareService::onInitialDataAvailable() never called on primary with empty data files
-
- Closed
-
-
SERVER-91674 [Cluster Server Parameters] Adopt the improved repl interfaces to keep in-memory states in sync with data
-
- Backlog
-
- related to
-
SERVER-91506 [Security] Adopt the improved repl interfaces to keep in-memory states in sync with data
-
- Open
-
-
SERVER-91505 [Catalog] Adopt the improved repl interfaces to keep in-memory states in sync with data
-
- Backlog
-