Details
-
Bug
-
Resolution: Fixed
-
Test Blocker
-
3.0
-
Security Level: Public
-
None
-
Untriaged
-
Unknown
-
June 30 - July 18
Description
Seeing data mismatch consistently since build 588 with -
./testrunner -i unixdcr.ini -t xdcr.uniXDCR.unidirectional.load_with_async_ops,items=100000,rdirection=unidirection,ctopology=chain,doc-ops=update, delete,sasl_buckets=1,replication_type=xmem
I'm also seeing some weird things.
There are 2 buckets, both have mismatch, let us just take default.
Source: 70403 (cbstats is consistent with this value)
[root@cen-0401 ~]# /opt/couchbase/bin/cbstats localhost:11211 all|grep curr_items
curr_items: 70403
Query on source returns only 70236 (http://10.1.3.93:8092/default/_design/dev_new/_view/docs?full_set=true&descending=false&stale=false&connection_timeout=60000&limit=100000&skip=0)
Destination : 7000, query returns 7000 items. (http://10.1.3.96:8092/default/_design/dev_new/_view/docs?full_set=true&descending=false&stale=false&connection_timeout=60000&limit=100000&skip=0)
The diff I provide based on the query is not going to be reliable. The clusters are available for debugging.
This Lost Deletes item count mismatch bug is seen ONLY on the source cluster's active vbuckets when:
1. A cluster has both active and replica vbuckets.
2. There is an active XDCR replication setup.
3. There are at least 10000 items inserted or updated and 30% of them deleted.
Attachments
Issue Links
- is duplicated by
-
-
- Closed
-
-
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
-
-
- Closed
-