Details
-
Bug
-
Resolution: Fixed
-
Blocker
-
3.0
-
Security Level: Public
-
CentOS 6.x , build 3.0.0-1174-rel
-
Untriaged
-
Unknown
-
Mar 9 - Mar 27
Description
--> Before expiration and after purging, all metadata match between source and destination clusters.
--> However, after expiration, there's some code that causes a deleted key at the source(!!!) to have seqno as 1. The seqno at destination is however 2, as expected.
--> The data below for uni-xdcr (C1 -> C2).
--> Not a recent regression, seen it once before in 3.0.0-9xx. Catching this bug totally depends on when I run the validation script after system test is completed. Expiration is usually set to 1 day and tombstone purge interval is 3 days on both source and destination. Once tombstones are purged, I don't see this mismatch. So I don't have a live cluster.
RevID or CAS mismatch -
172.23.105.44(C1): key:65ABEE18-153_100061 metadata:
172.23.105.54(C2): key:65ABEE18-153_100061 metadata:
{'deleted': 1, 'seqno': 2, 'cas': 1902841111553484, 'flags': 0, 'expiration': 1408646731} RevID or CAS mismatch -
172.23.105.44(C1): key:65ABEE18-153_100683 metadata:
172.23.105.54(C2): key:65ABEE18-153_100683 metadata:
{'deleted': 1, 'seqno': 2, 'cas': 1902841111336521, 'flags': 0, 'expiration': 1408646731}
RevID or CAS mismatch -
172.23.105.44(C1): key:65ABEE18-153_100713 metadata:
172.23.105.54(C2): key:65ABEE18-153_100713 metadata:
{'deleted': 1, 'seqno': 2, 'cas': 1902841111837670, 'flags': 0, 'expiration': 1408646731} RevID or CAS mismatch -
172.23.105.44(C1): key:65ABEE18-153_103240 metadata:
172.23.105.54(C2): key:65ABEE18-153_103240 metadata:
{'deleted': 1, 'seqno': 2, 'cas': 1902843752129236, 'flags': 0, 'expiration': 1408646733} RevID or CAS mismatch -
172.23.105.44(C1): key:65ABEE18-153_105170 metadata:
172.23.105.54(C2): key:65ABEE18-153_105170 metadata:
{'deleted': 1, 'seqno': 2, 'cas': 1902847773405995, 'flags': 0, 'expiration': 1408646737}Please let me know what/if you need in particular to diagnose this issue. Thanks!