git.net

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Inconsistent behaviour of counter update during cassandra intermediate upgrade


Hi,

I have raised jira ticket CASSANDRA-14881 for this issue  .
This ticket is not assigned to anyone. Please help me to assign this ticket to relevant person who can put some thought on it.

Note that When all nodes are successfully upgraded OR when 2 nodes gets upgraded to 3.11.2 and 3rd non-upgraded node is down then we don't see such issue  and counter update works as expected.




On Tue, Nov 6, 2018 at 4:58 PM Laxmikant Upadhyay <laxmikant.hcl@xxxxxxxxx> wrote:
Hi All,

I have 3 node (A,B,C) 2.1.16 cassandra cluster which i am upgrading to cassandra 3.11.2.
My current cluster status is node a has been upgrade to 3.11.2, B is down, and C is on cassandra 2.1.16

when i run counter update using cqlsh it is behaving strange inconsistent way , sometimes the update actualy applied and sometimes it does not apply at all.


See the below example of cqlsh logged in to node A:
===============Incorrect update : update not applied ========
user@cqlsh:ks> select * from "counterTable";

 key              | column1        | value
------------------+----------------+-------
 key1 | count |     0
 
user@cqlsh:ks> UPDATE "counterTable" SET value = value + 100 WHERE key = 'key1' AND column1 = 'count';

user@cqlsh:ks> select * from "counterTable";

 key              | column1        | value
------------------+----------------+-------
 key1 | count |     0


 ===============Correct update : update applied successfully ========
user@cqlsh> USE ks ;
user@cqlsh:ks> select * from "counterTable";

 key              | column1        | value
------------------+----------------+-------
 key1 | count |  -100
 
user@cqlsh:ks> UPDATE "counterTable" SET value = value + 100 WHERE key = 'key1' AND column1 = 'count';

user@cqlsh:ks> select * from "counterTable";

 key              | column1        | value
------------------+----------------+-------
 key1 | count |     0


I have attached the output with trace enabled (with actual timestamp) for both correct and incorrect counter update .

What is the reason of this weird behavior ?
--

regards,
Laxmikant Upadhyay



--

regards,
Laxmikant Upadhyay