Re: Sstableloader

[Patrick Lee]

Over the past year we've migrated several clusters from DSE to Apache
Cassandra. We've mostly done I place conversions node by node with no
downtime.  DSE 4.8.X to Apache Cassandra 2.1.x

On Wed, May 29, 2019 at 8:55 PM Goetz, Anthony 
wrote:

> My team migrated from DSE to OSS a few years ago by doing datacenter
> switch.  You will need to update replication strategy for all keyspaces
> that are using Everywhere to NetworkTopologyStrategy before adding any OSS
> nodes.  As Jonathan mentioned, DSE nodes will revert this change on
> restart.  To account for this, we modified our init script to call a cql
> script that would make sure the keyspaces were set back to
> NetworkTopologyStrategy.
>
>
>
> High Level Plan:
>
>- Find DSE Cassandra binary version
>- Review config to make sure you are not using any DSE specific
>settings
>- Update replication strategy on keyspaces using Everywhere to
>NetworkTopologyStrategy
>- Add OSS DC using same binary version as DSE
>- Migrate clients to new OSS DC
>- Decommission DSE DC
>
>
>
> Note:  OpsCenter will stop working once you add OSS nodes.
>
>
>
> *From: *Jonathan Koppenhofer 
> *Reply-To: *Cassandra User List 
> *Date: *Wednesday, May 29, 2019 at 6:45 PM
> *To: *Cassandra User List 
> *Subject: *[EXTERNAL] Re: Sstableloader
>
>
>
> Has anyone tried to do a DC switch as a means to migrate from Datastax to
> OSS? This would be the safest route as the ability to revert back to
> Datastax is easy. However, I'm curious how the dse_system keyspace would be
> replicated to OSS using their custom Everywhere strategy. You may have to
> change the to Network topology strategy before firing up OSS nodes. Also,
> keep in mind if you restart any DSE nodes, it will revert that keyspace
> back to EverywhereStrategy.
>
>
>
> I also posted a means to migrate in place on this mailing list a few
> months back (thanks for help from others on the mailing list), but it is a
> little more involved and risky. Let me know if you can't find it, and I'll
> dig it up.
>
>
>
> Finally, DSE 5.0 is open source equivalent 3.0.x. recommend you go to OSS
> 3.0 then up to 3.11.
>
> On Wed, May 29, 2019, 5:56 PM Nitan Kainth  wrote:
>
> If cassandra version is same, it should work
>
>
>
> Regards,
>
> Nitan
>
> Cell: 510 449 9629
>
>
> On May 28, 2019, at 4:21 PM, Rahul Reddy  wrote:
>
> Hello,
>
>
>
> Does sstableloader works between datastax and Apache cassandra. I'm trying
> to migrate dse 5.0.7 to Apache 3.11.1 ?
>
>

Re: Sstableloader

[Goetz, Anthony]

My team migrated from DSE to OSS a few years ago by doing datacenter switch.  
You will need to update replication strategy for all keyspaces that are using 
Everywhere to NetworkTopologyStrategy before adding any OSS nodes.  As Jonathan 
mentioned, DSE nodes will revert this change on restart.  To account for this, 
we modified our init script to call a cql script that would make sure the 
keyspaces were set back to NetworkTopologyStrategy.

High Level Plan:

  *   Find DSE Cassandra binary version
  *   Review config to make sure you are not using any DSE specific settings
  *   Update replication strategy on keyspaces using Everywhere to 
NetworkTopologyStrategy
  *   Add OSS DC using same binary version as DSE
  *   Migrate clients to new OSS DC
  *   Decommission DSE DC

Note:  OpsCenter will stop working once you add OSS nodes.

From: Jonathan Koppenhofer 
Reply-To: Cassandra User List 
Date: Wednesday, May 29, 2019 at 6:45 PM
To: Cassandra User List 
Subject: [EXTERNAL] Re: Sstableloader

Has anyone tried to do a DC switch as a means to migrate from Datastax to OSS? 
This would be the safest route as the ability to revert back to Datastax is 
easy. However, I'm curious how the dse_system keyspace would be replicated to 
OSS using their custom Everywhere strategy. You may have to change the to 
Network topology strategy before firing up OSS nodes. Also, keep in mind if you 
restart any DSE nodes, it will revert that keyspace back to EverywhereStrategy.

I also posted a means to migrate in place on this mailing list a few months 
back (thanks for help from others on the mailing list), but it is a little more 
involved and risky. Let me know if you can't find it, and I'll dig it up.

Finally, DSE 5.0 is open source equivalent 3.0.x. recommend you go to OSS 3.0 
then up to 3.11.
On Wed, May 29, 2019, 5:56 PM Nitan Kainth 
mailto:nitankai...@gmail.com>> wrote:
If cassandra version is same, it should work

Regards,
Nitan
Cell: 510 449 9629

On May 28, 2019, at 4:21 PM, Rahul Reddy 
mailto:rahulreddy1...@gmail.com>> wrote:
Hello,

Does sstableloader works between datastax and Apache cassandra. I'm trying to 
migrate dse 5.0.7 to Apache 3.11.1 ?

Re: Sstableloader

[Jonathan Koppenhofer]

Has anyone tried to do a DC switch as a means to migrate from Datastax to
OSS? This would be the safest route as the ability to revert back to
Datastax is easy. However, I'm curious how the dse_system keyspace would be
replicated to OSS using their custom Everywhere strategy. You may have to
change the to Network topology strategy before firing up OSS nodes. Also,
keep in mind if you restart any DSE nodes, it will revert that keyspace
back to EverywhereStrategy.

I also posted a means to migrate in place on this mailing list a few months
back (thanks for help from others on the mailing list), but it is a little
more involved and risky. Let me know if you can't find it, and I'll dig it
up.

Finally, DSE 5.0 is open source equivalent 3.0.x. recommend you go to OSS
3.0 then up to 3.11.

On Wed, May 29, 2019, 5:56 PM Nitan Kainth  wrote:

> If cassandra version is same, it should work
>
>
> Regards,
>
> Nitan
>
> Cell: 510 449 9629
>
> On May 28, 2019, at 4:21 PM, Rahul Reddy  wrote:
>
> Hello,
>
> Does sstableloader works between datastax and Apache cassandra. I'm trying
> to migrate dse 5.0.7 to Apache 3.11.1 ?
>
>

Re: Sstableloader

[Nitan Kainth]

If cassandra version is same, it should work


Regards,
Nitan
Cell: 510 449 9629

> On May 28, 2019, at 4:21 PM, Rahul Reddy  wrote:
> 
> Hello,
> 
> Does sstableloader works between datastax and Apache cassandra. I'm trying to 
> migrate dse 5.0.7 to Apache 3.11.1 ?

Re: Nodetool status load value

[Alain RODRIGUEZ]

Hello Simon,

Sorry if the question has already been answered.


This was probably answered here indeed (and multiple times I'm sure), but I
do not mind taking a moment to repeat this :).

About *why?*

This difference is expected. It can be due to multiple factors such as:
- Different compaction states on distinct nodes
- Ongoing compaction and temporary SSTables
- Different number of tombstones evicted (somewhat related to the first
point)
- imbalances in schema/workload (not applicable here, all nodes have 100%
of the data)
- A low number of vnodes (that is good for many other reasons) does have a
negative impact on distribution. (Not applicable, with 256 nodes, data
should be almost perfectly distributed)
- Any snapshots?
- ... (others that don't come to mind right now...)

Anyway, to answer your question more precisely:

Is it OK to have differences between nodes ?


Yes, with this proportions it is perfectly ok. Nodes have a similar dataset
and I imagine queries are well distributed. The situation seems to be
normal, at least nothing looking wrong in this `nodetool status` output I
would say.

C*heers,
---
Alain Rodriguez - al...@thelastpickle.com
France / Spain

The Last Pickle - Apache Cassandra Consulting
http://www.thelastpickle.com



Le mer. 29 mai 2019 à 08:09, Simon ELBAZ  a écrit :

> Hi,
>
> Sorry if the question has already been answered.
>
> Where nodetool status is run on a 3 node cluster (replication factor : 3),
> the load between the different nodes is not equal.
>
> *# nodetool status opush*
> *Datacenter: datacenter1*
> *===*
> *Status=Up/Down*
> *|/ State=Normal/Leaving/Joining/Moving*
> *--  Address   Load   Tokens  Owns (effective)  Host
> ID   Rack*
> *UN  192.168.11.3  9,14 GB256 100,0%
> 989589e8-9fcf-4c2f-85e9-c0599ac872e5  rack1*
> *UN  192.168.11.2  8,54 GB256 100,0%
> 42223dd0-1adf-433c-810d-8bc87f0d3af4  rack1*
> *UN  192.168.11.4  8,92 GB256 100,0%
> 1cecacc3-c301-4ae9-a71e-1a1a944d5731  rack1*
>
> Is it OK to have differences between nodes ?
>
> Thanks for your answer.
>
> Simon
>
>

Re: Sstableloader

[Alain RODRIGUEZ]

Hello,

I can't answer this question about the sstableloader (even though I think
it should be ok). My understanding, even though I'm not really up to date
with latest Datastax work, is that DSE uses a modified but compatible
version of Cassandra, for everything that is not 'DSE feature'
specifically. Especially I expect SSTable format to be the same.
SSTable loader has always been slow and inefficient for me though I did not
use it much.

I think the way out DSE should be documented somewhere in Datastax docs, if
not I think you can ask Datastax directly (or maybe someone here can help
you).

My guess is that the safest way out, without any downtime is probably to
perform a datacenter 'switch':
- Identify the Apache Cassandra version used under the hood by DSE (5.0.7).
Let's say it's 3.11.1 (I don't know)
- Add a new Apache Cassandra datacenter to your DSE cluster using this
version (I would rather use 3.11.latest in this case though... 3.11.1 had
memory leaks and other wild issues).
- Move client to this new DC
- Shutdown the old DC.

I wrote a runbook to perform such an operation not that long ago, you can
find it here:
https://thelastpickle.com/blog/2019/02/26/data-center-switch.html

I don't know for sure that this is the best way to go out of DSE, but that
would be my guess and the first thing I would investigate (before
SSTableLoader, clearly).

Hope that helps, even though it does not directly answers the question
(that I'm unable to answer) about SSTable & SSTableLoader compatibility
with DSE clusters.

C*heers

Le mar. 28 mai 2019 à 22:22, Rahul Reddy  a
écrit :

> Hello,
>
> Does sstableloader works between datastax and Apache cassandra. I'm trying
> to migrate dse 5.0.7 to Apache 3.11.1 ?
>

Re: Can sstable corruption cause schema mismatch?

[Nitan Kainth]

All ports are open.
We tried rolling restart and full cluster down and start one mode at a time.
Changes down were:
Storage addition
Ddl for column drop and recreate

Schema version is same for few nodes and few shows unavailable.

Network has been verified in detail and no severe packet drops.


Regards,
Nitan
Cell: 510 449 9629

> On May 29, 2019, at 10:04 AM, Alain RODRIGUEZ  wrote:
> 
> Ideas that come mind are:
> 
> - Rolling restart of the cluster
> - Use of 'nodetool resetlocalschema'  --> function name speaks for itself. 
> Note that this is to be ran on each node you think is having schema issues
> - Are all nodes showing a schema version showing the same one?
> - Port not fully open across all nodes?
> - Anything in the logs?
> 
> Do you know what triggered this situation in the first place?
> 
> C*heers,
> ---
> Alain Rodriguez - al...@thelastpickle.com
> France / Spain
> 
> The Last Pickle - Apache Cassandra Consulting
> http://www.thelastpickle.com
> 
>> Le mar. 28 mai 2019 à 18:28, Nitan Kainth  a écrit :
>> Thank you Alain.
>> 
>> Nodetool describecluster shows some nodes unreachable, different output from 
>> each node. 
>> Node1 can see all 4 nodes up.
>> Node 2 says node 4 and node 5 unreachable
>> Node 3 complains about node node 2 and node 1
>> 
>> Nodetool status shows all nodes up and read writes are working for most most 
>> operations. 
>> 
>> Network looks good. Any other ideas?
>> 
>> 
>> Regards,
>> Nitan
>> Cell: 510 449 9629
>> 
>>> On May 28, 2019, at 11:21 AM, Alain RODRIGUEZ  wrote:
>>> 
>>> Hello Nitan,
>>> 
 1. Can sstable corruption in application tables cause schema mismatch?
>>> 
>>> I would say it should not. I could imagine in the case that the corrupted 
>>> table hits some 'system' keyspace sstable. If not I don' see how corrupted 
>>> data can impact the schema on the node.
>>>  
 2. Do we need to disable repair while adding storage while Cassandra is 
 down?
>>> 
>>> I think you don't have to, but that it's a good idea.
>>> Repairs would fail as soon/long as you have a node down that should be 
>>> involved (I think there is an option to change that behaviour now).
>>> Anyway, stopping repair and restarting it when all nodes are probably 
>>> allows you a better understanding/control of what's going on. Also, it 
>>> reduces the load in time of troubles or maintenance, when the cluster is 
>>> somewhat weaker.
>>> 
>>> C*heers,
>>> ---
>>> Alain Rodriguez - al...@thelastpickle.com
>>> France / Spain
>>> 
>>> The Last Pickle - Apache Cassandra Consulting
>>> http://www.thelastpickle.com
>>> 
>>> 
>>> 
 Le mar. 28 mai 2019 à 17:13, Nitan Kainth  a écrit :
 Hi,
 
 Two questions:
 1. Can sstable corruption in application tables cause schema mismatch?
 2. Do we need to disable repair while adding storage while Cassandra is 
 down?
 
 
 Regards,
 Nitan
 Cell: 510 449 9629

Re: Collecting Latency Metrics

[shalom sagges]

If I only send ReadTotalLatency to Graphite/Grafana, can I run an average
on it and use "scale to seconds=1" ?
Will that do the trick?

Thanks!

On Wed, May 29, 2019 at 5:31 PM shalom sagges 
wrote:

> Hi All,
>
> I'm creating a dashboard that should collect read/write latency metrics on
> C* 3.x.
> In older versions (e.g. 2.0) I used to divide the total read latency in
> microseconds with the read count.
>
> Is there a metric attribute that shows read/write latency without the need
> to do the math, such as in nodetool tablestats "Local read latency" output?
> I saw there's a Mean attribute in org.apache.cassandra.metrics.ReadLatency
> but I'm not sure this is the right one.
>
> I'd really appreciate your help on this one.
> Thanks!
>
>
>

Re: Collecting Latency Metrics

[Paul Chandler]

There are various attributes under 
org.apache.cassandra.metrics.ClientRequest.Latency.Read these measure the 
latency in milliseconds

Thanks 

Paul
www.redshots.com

> On 29 May 2019, at 15:31, shalom sagges  wrote:
> 
> Hi All,
> 
> I'm creating a dashboard that should collect read/write latency metrics on C* 
> 3.x. 
> In older versions (e.g. 2.0) I used to divide the total read latency in 
> microseconds with the read count. 
> 
> Is there a metric attribute that shows read/write latency without the need to 
> do the math, such as in nodetool tablestats "Local read latency" output?
> I saw there's a Mean attribute in org.apache.cassandra.metrics.ReadLatency 
> but I'm not sure this is the right one. 
> 
> I'd really appreciate your help on this one. 
> Thanks!
> 
> 


-
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org

Re: Collecting Latency Metrics

[Alain RODRIGUEZ]

Hello,

This metric is available indeed:

Most of the metrics available are documented here:
http://cassandra.apache.org/doc/latest/operating/metrics.html

For client requests (coordinator perspective latency):
http://cassandra.apache.org/doc/latest/operating/metrics.html#client-request-metrics
For local requests (per table/host latency, locally, no network
communication included):
http://cassandra.apache.org/doc/latest/operating/metrics.html#table-metrics

LatencySpecial type that tracks latency (in microseconds) with a Timer plus
> a Counter that tracks the total latency accrued since starting. The
> former is useful if you track the change in total latency since the last
> check. Each metric name of this type will have ‘Latency’ and ‘TotalLatency’
> appended to it.


You need 'Latency', not 'TotalLatency'. I would guess that's the issue
because latencies are available for as far as I remember (including C*2.0,
1.2 for sure :)).

Also, be aware that quite a few things changed in the metric structure
between C* 2.1 and C*2.2 (and C*3.0 is similar to C*2.2).

Examples of changes:
- ColumnFamily --> Table
- 99percentile --> p99
- 1MinuteRate -->  m1_rate
- metric name before KS and Table names and some other changes of this kind.
- ^ aggregations / aliases and indexes changed because of this ^ - breaking
most of the charts (in my case at least).
- ‘.value’ is not appended to the metric name anymore for gauges, nothing
instead.

For example (Grafana / Graphite):
From
```aliasByNode(averageSeriesWithWildcards(cassandra.$env.$dc.$host.org.apache.cassandra.metrics.ColumnFamily.$ks.$table.ReadLatency.95percentile,
2, 3), 1, 7, 8, 9)```
to
```aliasByNode(averageSeriesWithWildcards(cassandra.$env.$dc.$host.org.apache.cassandra.metrics.Table.ReadLatency.$ks.$table.p95,
2, 3), 1, 8, 9, 10)```


Another tip, is to use ccm locally (https://github.com/riptano/ccm) for
example and 'jconsole $cassandra_pid'. I use this -->jconsole $(ccm node1
show | grep pid | awk -F= '{print $2}')
Once you're in, you can explore available mbeans and find the metrics
available in 'org.apache.cassandra.[...]'. It's not ideal as you search
'manually' but it allowed me to find some metrics in the past or fix issues
from the doc above.

Out of curiosity, may I ask what backend you used for your monitoring?

C*heers,
---
Alain Rodriguez - al...@thelastpickle.com
France / Spain

The Last Pickle - Apache Cassandra Consulting
http://www.thelastpickle.com



Le mer. 29 mai 2019 à 15:32, shalom sagges  a
écrit :

> Hi All,
>
> I'm creating a dashboard that should collect read/write latency metrics on
> C* 3.x.
> In older versions (e.g. 2.0) I used to divide the total read latency in
> microseconds with the read count.
>
> Is there a metric attribute that shows read/write latency without the need
> to do the math, such as in nodetool tablestats "Local read latency" output?
> I saw there's a Mean attribute in org.apache.cassandra.metrics.ReadLatency
> but I'm not sure this is the right one.
>
> I'd really appreciate your help on this one.
> Thanks!
>
>
>

Re: Collecting Latency Metrics

[Chris Lohfink]

To answer your question
org.apache.cassandra.metrics:type=Table,name=ReadTotalLatency can give you
the total local read latency in microseconds and you can get the count from
the Latency read metric.

If you are going to do that be sure to do it on the delta from previous
query (new - last) for both total latency and counter or else you will
slowly converge to a global average that will almost never change as the
quantity of reads simply removes outliers. The mean attribute of the
Latency metric you mentioned will give you an approximation for this
actually as its taking the total/count of a decaying histogram of the
latencies. It will however be even less accurate than using the deltas
since the bounds of the decaying wont necessarily match up with your
reading intervals and histogram introduces a worst case 20% round up. Even
with using deltas though this will hide outliers, you could end up with
really bad queries that don't even show up as a tick on your graph
(although *generally* it will).

Chris

On Wed, May 29, 2019 at 9:32 AM shalom sagges 
wrote:

> Hi All,
>
> I'm creating a dashboard that should collect read/write latency metrics on
> C* 3.x.
> In older versions (e.g. 2.0) I used to divide the total read latency in
> microseconds with the read count.
>
> Is there a metric attribute that shows read/write latency without the need
> to do the math, such as in nodetool tablestats "Local read latency" output?
> I saw there's a Mean attribute in org.apache.cassandra.metrics.ReadLatency
> but I'm not sure this is the right one.
>
> I'd really appreciate your help on this one.
> Thanks!
>
>
>

Re: Can sstable corruption cause schema mismatch?

[Alain RODRIGUEZ]

Ideas that come mind are:

- Rolling restart of the cluster
- Use of 'nodetool resetlocalschema'  --> function name speaks for itself.
Note that this is to be ran on each node you think is having schema issues
- Are all nodes showing a schema version showing the same one?
- Port not fully open across all nodes?
- Anything in the logs?

Do you know what triggered this situation in the first place?

C*heers,
---
Alain Rodriguez - al...@thelastpickle.com
France / Spain

The Last Pickle - Apache Cassandra Consulting
http://www.thelastpickle.com

Le mar. 28 mai 2019 à 18:28, Nitan Kainth  a écrit :

> Thank you Alain.
>
> Nodetool describecluster shows some nodes unreachable, different output
> from each node.
> Node1 can see all 4 nodes up.
> Node 2 says node 4 and node 5 unreachable
> Node 3 complains about node node 2 and node 1
>
> Nodetool status shows all nodes up and read writes are working for most
> most operations.
>
> Network looks good. Any other ideas?
>
>
> Regards,
>
> Nitan
>
> Cell: 510 449 9629
>
> On May 28, 2019, at 11:21 AM, Alain RODRIGUEZ  wrote:
>
> Hello Nitan,
>
> 1. Can sstable corruption in application tables cause schema mismatch?
>>
>
> I would say it should not. I could imagine in the case that the corrupted
> table hits some 'system' keyspace sstable. If not I don' see how corrupted
> data can impact the schema on the node.
>
>
>> 2. Do we need to disable repair while adding storage while Cassandra is
>> down?
>>
>
> I think you don't have to, but that it's a good idea.
> Repairs would fail as soon/long as you have a node down that should be
> involved (I think there is an option to change that behaviour now).
> Anyway, stopping repair and restarting it when all nodes are probably
> allows you a better understanding/control of what's going on. Also, it
> reduces the load in time of troubles or maintenance, when the cluster is
> somewhat weaker.
>
> C*heers,
> ---
> Alain Rodriguez - al...@thelastpickle.com
> France / Spain
>
> The Last Pickle - Apache Cassandra Consulting
> http://www.thelastpickle.com
>
>
>
> Le mar. 28 mai 2019 à 17:13, Nitan Kainth  a
> écrit :
>
>> Hi,
>>
>> Two questions:
>> 1. Can sstable corruption in application tables cause schema mismatch?
>> 2. Do we need to disable repair while adding storage while Cassandra is
>> down?
>>
>>
>> Regards,
>>
>> Nitan
>>
>> Cell: 510 449 9629
>>
>

Collecting Latency Metrics

[shalom sagges]

Hi All,

I'm creating a dashboard that should collect read/write latency metrics on
C* 3.x.
In older versions (e.g. 2.0) I used to divide the total read latency in
microseconds with the read count.

Is there a metric attribute that shows read/write latency without the need
to do the math, such as in nodetool tablestats "Local read latency" output?
I saw there's a Mean attribute in org.apache.cassandra.metrics.ReadLatency
but I'm not sure this is the right one.

I'd really appreciate your help on this one.
Thanks!

Re: Counter table in Cassandra

[Paul Chandler]

Hi Garvit,

When updating counters, Cassandra does a read then a write, so there is an 
overhead of using counters. This is all explained here: 
https://www.datastax.com/dev/blog/whats-new-in-cassandra-2-1-a-better-implementation-of-counters
 


There is a design pattern that can be used instead of counters, this will not 
work if you need instant accuracy, but if you are looking for a count value to 
be “eventually" correct then it will be a lot less taxing on cassandra. I have 
outlined this pattern in a blog post, when I wrote it I was advising a team 
that was performing a lot of count(*) on a table, so it starts from that 
premise rather than using counters, but the result is the same. This can be 
found here: http://www.redshots.com/cassandra-counting-without-using-counters/ 


I hope these links help.

Regards

Paul Chandler



> On 29 May 2019, at 10:18, Attila Wind  wrote:
> 
> Hi Garvit,
> 
> I can not answer your main question but when I read your lines one thing was 
> popping up constantly: "why do you ask this?" 
> 
> So what is the background of this question? Do you see anything smelly?
> 
> Actually
> a) I always assumed so naturally there are of course lots of in-parallel 
> activities (writes) against any tables includin counters. So of course there 
> is a race condition and probably threads yes
> 
> b) Cassandra do not have isolated transactions so of course in a complex flow 
> (using multiple tables) there is no business data consistency guarantee for 
> sure
> 
> c) until you are doing just +/- ops it is a mathematical fact that execution 
> order of writes is not really important. Repeating +1 increase 5 times will 
> result in higher counter by num 5...
> 
> Please share your background I am interested in it!
> 
> Cheers
> Attila
> 
> 2019. máj. 29., Sze 2:34 dátummal Garvit Sharma  > ezt írta:
> Hi,
> 
> I am using counter tables in Cassandra and I want to understand how the 
> concurrent updates to counter table are handled in Cassandra.
> 
> There are more than one threads who are responsible for updating the counter 
> for a partition key. Multiple threads can also update the counter for the 
> same key.
> 
> In case when more than one threads updating the counter for the same key, how 
> Cassandra is handling the race condition?
> 
> UPDATE cycling.popular_count
>  SET popularity = popularity + 1
>  WHERE id = 6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47;
> 
> Are there overheads of using counter tables? 
> Are there alternatives to counter tables?
> 
> Thanks,
> -- 
> 
> Garvit Sharma
> github.com/garvitlnmiit/ 
> 
> No Body is a Scholar by birth, its only hard work and strong determination 
> that makes him master.

Re: Counter table in Cassandra

[Attila Wind]

Hi Garvit,

I can not answer your main question but when I read your lines one thing
was popping up constantly: "why do you ask this?"

So what is the background of this question? Do you see anything smelly?

Actually
a) I always assumed so naturally there are of course lots of in-parallel
activities (writes) against any tables includin counters. So of course
there is a race condition and probably threads yes

b) Cassandra do not have isolated transactions so of course in a complex
flow (using multiple tables) there is no business data consistency
guarantee for sure

c) until you are doing just +/- ops it is a mathematical fact that
execution order of writes is not really important. Repeating +1 increase 5
times will result in higher counter by num 5...

Please share your background I am interested in it!

Cheers
Attila

2019. máj. 29., Sze 2:34 dátummal Garvit Sharma  ezt
írta:

> Hi,
>
> I am using counter tables in Cassandra and I want to understand how the
> concurrent updates to counter table are handled in Cassandra.
>
> There are more than one threads who are responsible for updating the
> counter for a partition key. Multiple threads can also update the counter
> for the same key.
>
> In case when more than one threads updating the counter for the same key,
> how Cassandra is handling the race condition?
>
> UPDATE cycling.popular_count
>  SET popularity = popularity + 1
>  WHERE id = 6ab09bec-e68e-48d9-a5f8-97e6fb4c9b47;
>
>
> Are there overheads of using counter tables?
> Are there alternatives to counter tables?
>
> Thanks,
> --
>
> Garvit Sharma
> github.com/garvitlnmiit/
>
> No Body is a Scholar by birth, its only hard work and strong determination
> that makes him master.
>

Nodetool status load value

[Simon ELBAZ]

Hi,

Sorry if the question has already been answered.

Where nodetool status is run on a 3 node cluster (replication factor : 
3), the load between the different nodes is not equal.


/# nodetool status opush//
//Datacenter: datacenter1//
//===//
//Status=Up/Down//
//|/ State=Normal/Leaving/Joining/Moving//
//--  Address   Load   Tokens  Owns (effective)  Host 
ID   Rack//
//UN  192.168.11.3  9,14 GB    256 100,0% 
989589e8-9fcf-4c2f-85e9-c0599ac872e5  rack1//
//UN  192.168.11.2  8,54 GB    256 100,0% 
42223dd0-1adf-433c-810d-8bc87f0d3af4  rack1//
//UN  192.168.11.4  8,92 GB    256 100,0% 
1cecacc3-c301-4ae9-a71e-1a1a944d5731  rack1/


Is it OK to have differences between nodes ?

Thanks for your answer.

Simon