Details
-
Type:
Bug
-
Status:
Closed
-
Priority:
Critical
-
Resolution: Fixed
-
Affects Version/s: 2.0
-
Fix Version/s: 2.0
-
Component/s: cross-datacenter-replication, UI
-
Security Level: Public
-
Labels:None
Description
Hi,
Today "flush" is not xdcr-replicated to the remote cluster, but we can flush data from either source/ destination and the other cluster/replication is left intact ( no impact of flush)
I ve opened bug to either stop/ warn the user of the consequences of using Flush while XDCR is on-going http://www.couchbase.com/issues/browse/MB-6761
We ve discussed this a bit in the past, and realize that a number of combination can arise with enabling flush with xdcr clusters.
For example , in a unidirectional setup.
One can flush data bucket from source, and replication is not broken. The source cluster has no items and destination cluster has the existing items. With new load coming in, this leaves the clusters
in a somewhat inconsistent state. Failing replication for this, would be ideal.
Likewise for a destination-flush
One can flush data bucket from destination, and replication is not broken. The destination cluster has no items and source cluster has the existing items. With new load coming in, this leaves the clusters
in a somewhat inconsistent state. Failing replication for this, would be ideal.
And likewise on a Bidirectional replication setup.
In the event, that we decide to enable flush+ Xdcr, we will need to add the following to our test-metrics to make sure this feature works under multiple combinations.
Since replication will fail/inconsistent with Flush, is it better to disable/ disallow flush + xdcr?
Today "flush" is not xdcr-replicated to the remote cluster, but we can flush data from either source/ destination and the other cluster/replication is left intact ( no impact of flush)
I ve opened bug to either stop/ warn the user of the consequences of using Flush while XDCR is on-going http://www.couchbase.com/issues/browse/MB-6761
We ve discussed this a bit in the past, and realize that a number of combination can arise with enabling flush with xdcr clusters.
For example , in a unidirectional setup.
One can flush data bucket from source, and replication is not broken. The source cluster has no items and destination cluster has the existing items. With new load coming in, this leaves the clusters
in a somewhat inconsistent state. Failing replication for this, would be ideal.
Likewise for a destination-flush
One can flush data bucket from destination, and replication is not broken. The destination cluster has no items and source cluster has the existing items. With new load coming in, this leaves the clusters
in a somewhat inconsistent state. Failing replication for this, would be ideal.
And likewise on a Bidirectional replication setup.
In the event, that we decide to enable flush+ Xdcr, we will need to add the following to our test-metrics to make sure this feature works under multiple combinations.
Since replication will fail/inconsistent with Flush, is it better to disable/ disallow flush + xdcr?
Activity
Farshid Ghods
made changes -
| Field | Original Value | New Value |
|---|---|---|
| Issue Type | Story [ 6 ] | Bug [ 1 ] |
Junyi Xie
made changes -
| Assignee | Junyi Xie [ junyi ] | Aliaksey Artamonau [ Aliaksey Artamonau ] |
Junyi Xie
made changes -
| Component/s | UI [ 10016 ] |
Junyi Xie
made changes -
| Attachment | Screen Shot 2012-10-03 at 2.12.03 PM.png [ 15275 ] |
Aleksey Kondratenko
made changes -
| Assignee | Aliaksey Artamonau [ Aliaksey Artamonau ] | Peter Wansch [ peter ] |
Peter Wansch
made changes -
| Summary | Disable Flush with XDCR. | Disable Flush with XDCR on the source cluster |
Peter Wansch
made changes -
| Assignee | Peter Wansch [ peter ] | Aleksey Kondratenko [ alkondratenko ] |
Peter Wansch
made changes -
| Priority | Major [ 3 ] | Critical [ 2 ] |
Aleksey Kondratenko
made changes -
| Status | Open [ 1 ] | Resolved [ 5 ] |
| Resolution | Fixed [ 1 ] |
Farshid Ghods
made changes -
| Status | Resolved [ 5 ] | Closed [ 6 ] |