Details
-
Bug
-
Resolution: Fixed
-
Blocker
-
3.0
-
Security Level: Public
-
All OS
-
Untriaged
-
Centos 64-bit
-
Unknown
Description
Test run on build 3.0.0-866
Steps to reproduce:
- Setup two clusters - src-A and dest-B (each with three nodes and one bucket each) with xdcr
- Setup two floating nodes on dest-B
- Create 80 K items, ensure all items are replicated on the dest-B cluster
- Failover two nodes at dest-B
- Add one node at dest-B cluster
- run cbrecovery from src-A to dest-B
- Ensure cbrecovery completes successfully
- do rebalance on dest-B cluster
- ensure rebalance completes
- Do mutations on src-A cluster
- Verify meta data on dest-B cluster matches src-A cluster
Bug: Meta data does not match between src-A and dest-B cluster.
Source meta data:
{'deleted': 0, 'seqno': 1, 'cas': 6811709964931922, 'flags': 0, 'expiration': 0}[2014-06-25 01:10:42,636] - [task:1206] ERROR - Dest meta data:
{'deleted': 0, 'seqno': 1, 'cas': 0, 'flags': 0, 'expiration': 0}Found using jenkins job: http://qa.sc.couchbase.com/view/All/job/ubuntu_x64--38_01--cbrecovery-P1/44/consoleFull
After failing over and rebalancing nodes on a destination cluster and then replicating from the source cluster to destination cluster, the document metadata is inconsistent between source and destination clusters. This behavior occurs when the cbrecovery (1st) and rebalance (2nd) sequence is performed.