Details
-
Bug
-
Resolution: Won't Fix
-
Critical
-
Cheshire-Cat
-
Untriaged
-
1
-
No
Description
Ns_server is introducing quorum failover as a feature, and has a finalized plan with KV that details how the system behaves if manifests roll back.
XDCR will need to handle this situation when it occurs on either the source, target, or both.
Update 4/13: Per discussion with KV and Ns_server teams, the solution in the proposed doc link will not be fully implemented due to the amount of risk involved with changes on KV side. Instead, this MB will keep track of XDCR MVP handling of quorum failover on source side and target side to ensure that it won't error out and cause production down time. To reiterate, the MVP (this MB) is not to ensure that mis-map won't happen during replication, but rather that XDCR in CBServer will gracefully detect quorum failover (either on source or target) and gracefully recover its internal state.
Update 4/19: Per ns_server's proposal to bump up manifest and collection IDs per quorum failover, this resolves the issue of ID rollback and reuse that would have plagued XDCR. Nothing needs to be done once the proposal is implemented.
However, without ns_server's fix in 7.0 release, the target-side problem described in the document (link below) can still exist and may require documentation.
Attachments
Issue Links
- depends on
-
MB-45711 Increment next colleciton ID and manifest ID by 0x1000 after quorum failover
- Closed
- relates to
-
DOC-8445 XDCR - potential issues with target-side quorum failover
- Closed
-
MB-45505 KV should use the Chronicle history ID provided in collections manifest to "force" manifests on vbuckets
- Closed
- links to