>>> 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
