Details
-
Bug
-
Resolution: Fixed
-
Critical
-
6.5.1, 6.6.0, 6.6.1, 6.6.2, 6.5.2, 6.5.0, 7.6.0, 6.6.3, 6.6.4, 6.6.5, 6.6.6, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.1.4, 7.0.5, 7.1.0, 7.1.1, 7.1.2, 7.2.0, 7.1.3, 7.2.1, 7.1.5, 7.2.4, 7.0.6, 7.1.7, 7.2.2, 7.1.6, 7.2.3, 7.2.5, 7.6.1
-
Untriaged
-
0
-
Unknown
Description
Consider the two data-structures in the remoteClusterSvc -
(1) cachedRefNodesList: The remoteClusterSvc will compute a cachedRefNodesList at the end of every refresh, which represents the current set of nodes in the target cluster at that time.
(2) nodeStatus: We also have nodeStatus map, which is a mapping of target cluster node to the connectivity status (RC_OK, RC_DEGRADED, RC_ERROR) as seen by XDCR.
At the end of every successful refresh loop, we would have (1). Using cachedRefNodesList of (1), nodeStatus i.e. (2) also has to be updated at the end of refresh loop. This is done by using a function called ConnectivityHelper.SyncWithValidList. This function has a flawed logic in-terms of removing stale nodes which previously existed, but doesn't exist anymore.
Because of this, we might end-up seeing "User intervention may be required" errors infinitely, because of the connectivity statuses of nodes that do not exists anymore, but still cached in nodeStatus.
Attachments
Issue Links
- is a backport of
-
MB-61977 XDCR - Connectivity node status map might not be synced with cachedRefNodesList after refresh
-
- Resolved
-
For Gerrit Dashboard: MB-61983 | ||||||
---|---|---|---|---|---|---|
# | Subject | Branch | Project | Status | CR | V |
210319,2 | MB-61983: Rectify the SyncWithValidNodeList logic to invalidate stale target nodes | trinity | goxdcr | Status: MERGED | +2 | +1 |