[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cassandra-user
Subject:    Re: restoring a counter
From:       Sylvain Lebresne <sylvain () datastax ! com>
Date:       2012-07-27 8:36:17
Message-ID: CAKkz8Q0-MLSX5z+VWUzFYAn3DSXjOC7zwrpHUAkfMKtzLk-fsA () mail ! gmail ! com
[Download RAW message or body]

>>>   a) how does that setting affect C* in a non-restoring start?
>
> renew_counter_id regenerates a new "NodeId" for the cassandra VM which
> is used to keep track of the counter shards the node holds. If you
> regenerate node ids on each restart, you will most likely corrupt your
> counter data.

The description of NodeId is correct but the part about regenerating
it could lead to counter data corruption is not. There is no risk of
corrupting counter by regenerating the node id too often (or at least
there should not be), but it does have an impact on performance.
Basically, if you restart with the -Dcassandra.renew_counter_id=true,
the internal representation for your counter will become bigger (the
size occupied on disk, not the counter value itself) over time. And by
over time I mean, with new counter increment coming in. So if you
restart even a few times with the flag on over a short period of time,
it's fine, it won't have much negative impact, but in general it is a
one shot flag and you should not leave it on.

>>>   b) if it's < bad > (for some value of that), should I stop C*+remove
>>> the setting+start C* after the value has been repaired?

The short answer is no. The renewal of the node id that the flag
trigger is done at startup and once it's done, it's done. When you
start with the flag on, the only thing you want to make sure is to not
have the flag on for the next restart, but there is no reason to force
that restart.

--
Sylvain
[prev in list] [next in list] [prev in thread] [next in thread]