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
-
MB-10974 [TAP xmem XDCR] seqno number mismatch between source and destination for 1 updated item
- Closed
-
MB-10975 [TAP xmem XDCR] seqno/cas mismatch between source and destination for 7 expired (deleted) items
- Closed
- relates to
-
MB-10844 KV+XDCR (TAP) : system test - item count mismatch (memcached connection requests time out)
- Closed
-
MB-10913 Mutations (1 deleted items) not replicated, caused items mismatch on destination cluster
- Closed
-
MB-10494 curr_items, vb_active_curr_items stats don't have expected values while data is replicated on the destination cluster
- Closed