Details
-
Bug
-
Resolution: Fixed
-
Major
-
2.0
-
Security Level: Public
-
None
-
1 bucket, 64 buckets, build - 2.0-1430
2 - 2 node cluster
unidirectional xdcr replication
Description
@Junyi: I ve currently assigned this bug to you. Please feel free to re-assign it to the right person.
Hi Junyi,
I am testing uni-directional XDCR replication as
1. Setup two clusters with (2:2) nodes. [ 1 bucket, 64 buckets, build - 2.0-1430]
2. Setup a unidirectional replication from cluster1- cluster2
3. Load 10k items on source, verified 10k items on destination cluster.
4. Delete 2000 items on source, expect same count on srouce and destination.
Output
Seeing 8000 items on source and 8003 items on destination.
Based on the recent code changes, we now would count curr valid items on destination as
curr_items - curr_temp_items?
So I got stats from the destination node for curr_ items, the temp items show a very unusually large number.
Any idea how to trouble shoot this?
<Screen Shot 2012-07-11 at 10.27.55 AM.png>
-Ketaki
----------------
./cbstats localhost:12002 vbucket-details (per vbucket curr_temp_items count)
./cbstats localhost:12002 all | grep curr_temp_items
Thanks,
Jin
-------
Output from vbucket-details shows some vbuckets have the underflow issue
Thanks Jin.
Seeing few vBuckets on both source/destination with underflow? issues - on delete items
Yep, will open a bug to track this.
[ The tests do run the expiry pager before collecting stats now]
vb_62:num_temp_items: 18446744073709551583
vb_62:ops_create: 159
vb_62:ops_delete: 33
vb_62:ops_reject: 0
vb_62:ops_update: 0
vb_62:pending_writes: 0
vb_62:queue_age: 0
vb_62:queue_drain: 192
vb_62:queue_fill: 192
vb_62:queue_memory: 0
vb_62:queue_size: 0
vb_63: replica
vb_63:ht_cache_size: 41875
vb_63:ht_item_memory: 41875
vb_63:ht_memory: 25096
vb_63:num_ejects: 0
vb_63:num_items: 125
vb_63:num_resident: 0
vb_63:num_temp_items: 18446744073709551585