Query on Cassandra clusters

[Sumit Anvekar]

I have a couple questions.

1. I have a Cassandra cluster with 11 nodes, 5 of which have Cassandra
version 3.0.3 and then newer 5 nodes have 3.6.0 version. I has been running
fine until recently I am seeing higher amount of data residing in newer
boxes. The configuration file (YAML file) is exactly same on all nodes
(except for the node host names). Wondering if the version has something to
do with this scenario. Due to this scenario, a couple boxes are running
very high on memory (95% usage) whereas some of the older version nodes
have just 60-70% memory usage.

2. To counter #1, I am planning to upgrade system configuration of the
nodes where there is higher memory usage. But the question is, will it be a
problem if we have a Cassandra cluster, where in a couple of nodes have
double the system configuration than other nodes in the cluster.

Appreciate any comment on the same.

Sumit.

Why does Cassandra recommends Oracle JVM instead of OpenJDK?

[Kant Kodali]

Looking at this
http://www.theregister.co.uk/2016/12/16/oracle_targets_java_users_non_compliance/?mt=1481919461669
I don't know why Cassandra recommends Oracle JVM?

JVM is a great piece of software but I would like to stay away from Oracle
as much as possible. Oracle is just horrible the way they are dealing with
Java in General.

Re: Handling Leap second delay

[Harikrishnan Pillai]

http://www.datastax.com/dev/blog/preparing-for-the-leap-second-2017

[http://www.datastax.com/wp-content/themes/datastax-2013/images/common/logo.png]

Preparing for the Leap Second, 2017 Jan 1 Edition | 
DataStax
www.datastax.com
Back in April of 2015 we published a blog post, ‘Preparing for the Leap 
Second’. In July, IERS announced another leap second which will take place on 
January 1st ...




From: Sanjeev T 
Sent: Tuesday, December 20, 2016 7:54:29 PM
To: user@cassandra.apache.org
Subject: Handling Leap second delay

Hi,

Can some of you share points on, the versions and handling leap second delay on 
Dec 31, 2016.

Regards
-Sanjeev

Handling Leap second delay

[Sanjeev T]

Hi,

Can some of you share points on, the versions and handling leap second
delay on Dec 31, 2016.

Regards
-Sanjeev

Re: iostat -like tool to parse 'nodetool cfstats'

[kurt Greaves]

Anything in cfstats you should be able to retrieve through the metrics
Mbeans. See https://cassandra.apache.org/doc/latest/operating/metrics.html

On 20 December 2016 at 23:04, Richard L. Burton III 
wrote:

> I haven't seen anything like that myself. It would be nice to have
> nodetool cfstats to be presented in a nicier format.
>
> If you plan to work on that, let me know. I would help contribute to it
> next month.
>
> On Tue, Dec 20, 2016 at 5:59 PM, Kevin Burton  wrote:
>
>> nodetool cfstats has some valuable data but what I would like is a 1
>> minute delta.
>>
>> Similar to iostat...
>>
>> It's easy to parse this but has anyone done it?
>>
>> I want to see IO throughput and load on C* for each table.
>>
>> --
>>
>> We’re hiring if you know of any awesome Java Devops or Linux Operations
>> Engineers!
>>
>> Founder/CEO Spinn3r.com
>> Location: *San Francisco, CA*
>> blog: http://burtonator.wordpress.com
>> … or check out my Google+ profile
>> 
>>
>>
>
>
> --
> -Richard L. Burton III
> @rburton
>

Re: Join_ring=false Use Cases

[Carlos Rolo]

Beware the Java Driver limitations around whitelisting IPs.

Works fine in Python.



Regards,

Carlos Juzarte Rolo
Cassandra Consultant / Datastax Certified Architect / Cassandra MVP

Pythian - Love your data

rolo@pythian | Twitter: @cjrolo | Skype: cjr2k3 | Linkedin:
*linkedin.com/in/carlosjuzarterolo
*
Mobile: +351 918 918 100
www.pythian.com

On Tue, Dec 20, 2016 at 9:25 PM, Matija Gobec  wrote:

> There is a talk from cassandra summit 2016 about coordinator nodes by Eric
> Lubow from SimpleReach. He explains how you can use that join_ring=false.
>
> On Tue, Dec 20, 2016 at 10:23 PM, kurt Greaves 
> wrote:
>
>> It seems that you're correct in saying that writes don't propagate to a
>> node that has join_ring set to false, so I'd say this is a flaw. In reality
>> I can't see many actual use cases in regards to node outages with the
>> current implementation. The main usage I'd think would be to have
>> additional coordinators for CPU heavy workloads.
>>
>> It seems to make it actually useful for repairs/outages we'd need to have
>> another option to turn on writes so that it behaved similarly to write
>> survey mode (but on already bootstrapped nodes).
>>
>> Is there a reason we don't have this already? Or does it exist somewhere
>> I'm not aware of?
>>
>> On 20 December 2016 at 17:40, Anuj Wadehra 
>> wrote:
>>
>>> No responses yet :)
>>>
>>> Any C* expert who could help on join_ring use case and the concern
>>> raised?
>>>
>>> Thanks
>>> Anuj
>>>
>>> On Tue, 13 Dec, 2016 at 11:31 PM, Anuj Wadehra
>>>  wrote:
>>> Hi,
>>>
>>> I need to understand the use case of join_ring=false in case of node
>>> outages. As per https://issues.apache.org/jira/browse/CASSANDRA-6961,
>>> you would want join_ring=false when you have to repair a node before
>>> bringing a node back after some considerable outage. The problem I see with
>>> join_ring=false is that unlike autobootstrap, the node will NOT accept
>>> writes while you are running repair on it. If a node was down for 5 hours
>>> and you bring it back with join_ring=false, repair the node for 7 hours and
>>> then make it join the ring, it will STILL have missed writes because while
>>> the time repair was running (7 hrs), writes only went to other others.
>>> So, if you want to make sure that reads served by the restored node at CL
>>> ONE will return consistent data after the node has joined, you wont get
>>> that as writes have been missed while the node is being repaired. And if
>>> you work with Read/Write CL=QUORUM, even if you bring back the node without
>>> join_ring=false, you would anyways get the desired consistency. So, how
>>> join_ring would provide any additional consistency in this case ??
>>>
>>> I can see join_ring=false useful only when I am restoring from Snapshot
>>> or bootstrapping and there are dropped mutations in my cluster which are
>>> not fixed by hinted handoff.
>>>
>>> For Example: 3 nodes A,B,C working at Read/Write CL QUORUM. Hinted
>>> Handoff=3 hrs.
>>> 10 AM Snapshot taken on all 3 nodes
>>> 11 AM: Node B goes down for 4 hours
>>> 3 PM: Node B comes up but data is not repaired. So, 1 hr of dropped
>>> mutations (2-3 PM) not fixed via Hinted Handoff.
>>> 5 PM: Node A crashes.
>>> 6 PM: Node A restored from 10 AM Snapshot, Node A started with
>>> join_ring=false, repaired and then joined the cluster.
>>>
>>> In above restore snapshot example, updates from 2-3 PM were outside
>>> hinted handoff window of 3 hours. Thus, node B wont get those updates.
>>> Node A data for 2-3 PM is already lost. So, 2-3 PM updates are only on one
>>> replica i.e. node C and minimum consistency needed is QUORUM so
>>> join_ring=false would help. But this is very specific use case.
>>>
>>> Thanks
>>> Anuj
>>>
>>>
>>
>

-- 


--

Re: iostat -like tool to parse 'nodetool cfstats'

[Richard L. Burton III]

I haven't seen anything like that myself. It would be nice to have nodetool
cfstats to be presented in a nicier format.

If you plan to work on that, let me know. I would help contribute to it
next month.

On Tue, Dec 20, 2016 at 5:59 PM, Kevin Burton  wrote:

> nodetool cfstats has some valuable data but what I would like is a 1
> minute delta.
>
> Similar to iostat...
>
> It's easy to parse this but has anyone done it?
>
> I want to see IO throughput and load on C* for each table.
>
> --
>
> We’re hiring if you know of any awesome Java Devops or Linux Operations
> Engineers!
>
> Founder/CEO Spinn3r.com
> Location: *San Francisco, CA*
> blog: http://burtonator.wordpress.com
> … or check out my Google+ profile
> 
>
>


-- 
-Richard L. Burton III
@rburton

iostat -like tool to parse 'nodetool cfstats'

[Kevin Burton]

nodetool cfstats has some valuable data but what I would like is a 1 minute
delta.

Similar to iostat...

It's easy to parse this but has anyone done it?

I want to see IO throughput and load on C* for each table.

-- 

We’re hiring if you know of any awesome Java Devops or Linux Operations
Engineers!

Founder/CEO Spinn3r.com
Location: *San Francisco, CA*
blog: http://burtonator.wordpress.com
… or check out my Google+ profile

Re: Incremental repair for the first time

[kurt Greaves]

No workarounds, your best/only option is to upgrade (plus you get the
benefit of loads of other bug fixes).

On 16 December 2016 at 21:58, Kathiresan S 
wrote:

> Thank you!
>
> Is any work around available for this version?
>
> Thanks,
> Kathir
>
>
> On Friday, December 16, 2016, Jake Luciani  wrote:
>
>> This was fixed post 3.0.4 please upgrade to latest 3.0 release
>>
>> On Fri, Dec 16, 2016 at 4:49 PM, Kathiresan S <
>> kathiresanselva...@gmail.com> wrote:
>>
>>> Hi,
>>>
>>> We have a brand new Cassandra cluster (version 3.0.4) and we set up
>>> nodetool repair scheduled for every day (without any options for repair).
>>> As per documentation, incremental repair is the default in this case.
>>> Should we do a full repair for the very first time on each node once and
>>> then leave it to do incremental repair afterwards?
>>>
>>> *Problem we are facing:*
>>>
>>> On a random node, the repair process throws validation failed error,
>>> pointing to some other node
>>>
>>> For Eg. Node A, where the repair is run (without any option), throws
>>> below error
>>>
>>> *Validation failed in /Node B*
>>>
>>> In Node B when we check the logs, below exception is seen at the same
>>> exact time...
>>>
>>> *java.lang.RuntimeException: Cannot start multiple repair sessions over
>>> the same sstables*
>>> *at
>>> org.apache.cassandra.db.compaction.CompactionManager.doValidationCompaction(CompactionManager.java:1087)
>>> ~[apache-cassandra-3.0.4.jar:3.0.4]*
>>> *at
>>> org.apache.cassandra.db.compaction.CompactionManager.access$700(CompactionManager.java:80)
>>> ~[apache-cassandra-3.0.4.jar:3.0.4]*
>>> *at
>>> org.apache.cassandra.db.compaction.CompactionManager$10.call(CompactionManager.java:700)
>>> ~[apache-cassandra-3.0.4.jar:3.0.4]*
>>> *at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>>> ~[na:1.8.0_73]*
>>> *at
>>> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>>> ~[na:1.8.0_73]*
>>>
>>> Can you please help on how this can be fixed?
>>>
>>> Thanks,
>>> Kathir
>>>
>>
>>
>>
>> --
>> http://twitter.com/tjake
>>
>

Re: Join_ring=false Use Cases

[Matija Gobec]

There is a talk from cassandra summit 2016 about coordinator nodes by Eric
Lubow from SimpleReach. He explains how you can use that join_ring=false.

On Tue, Dec 20, 2016 at 10:23 PM, kurt Greaves  wrote:

> It seems that you're correct in saying that writes don't propagate to a
> node that has join_ring set to false, so I'd say this is a flaw. In reality
> I can't see many actual use cases in regards to node outages with the
> current implementation. The main usage I'd think would be to have
> additional coordinators for CPU heavy workloads.
>
> It seems to make it actually useful for repairs/outages we'd need to have
> another option to turn on writes so that it behaved similarly to write
> survey mode (but on already bootstrapped nodes).
>
> Is there a reason we don't have this already? Or does it exist somewhere
> I'm not aware of?
>
> On 20 December 2016 at 17:40, Anuj Wadehra  wrote:
>
>> No responses yet :)
>>
>> Any C* expert who could help on join_ring use case and the concern raised?
>>
>> Thanks
>> Anuj
>>
>> On Tue, 13 Dec, 2016 at 11:31 PM, Anuj Wadehra
>>  wrote:
>> Hi,
>>
>> I need to understand the use case of join_ring=false in case of node
>> outages. As per https://issues.apache.org/jira/browse/CASSANDRA-6961,
>> you would want join_ring=false when you have to repair a node before
>> bringing a node back after some considerable outage. The problem I see with
>> join_ring=false is that unlike autobootstrap, the node will NOT accept
>> writes while you are running repair on it. If a node was down for 5 hours
>> and you bring it back with join_ring=false, repair the node for 7 hours and
>> then make it join the ring, it will STILL have missed writes because while
>> the time repair was running (7 hrs), writes only went to other others.
>> So, if you want to make sure that reads served by the restored node at CL
>> ONE will return consistent data after the node has joined, you wont get
>> that as writes have been missed while the node is being repaired. And if
>> you work with Read/Write CL=QUORUM, even if you bring back the node without
>> join_ring=false, you would anyways get the desired consistency. So, how
>> join_ring would provide any additional consistency in this case ??
>>
>> I can see join_ring=false useful only when I am restoring from Snapshot
>> or bootstrapping and there are dropped mutations in my cluster which are
>> not fixed by hinted handoff.
>>
>> For Example: 3 nodes A,B,C working at Read/Write CL QUORUM. Hinted
>> Handoff=3 hrs.
>> 10 AM Snapshot taken on all 3 nodes
>> 11 AM: Node B goes down for 4 hours
>> 3 PM: Node B comes up but data is not repaired. So, 1 hr of dropped
>> mutations (2-3 PM) not fixed via Hinted Handoff.
>> 5 PM: Node A crashes.
>> 6 PM: Node A restored from 10 AM Snapshot, Node A started with
>> join_ring=false, repaired and then joined the cluster.
>>
>> In above restore snapshot example, updates from 2-3 PM were outside
>> hinted handoff window of 3 hours. Thus, node B wont get those updates.
>> Node A data for 2-3 PM is already lost. So, 2-3 PM updates are only on one
>> replica i.e. node C and minimum consistency needed is QUORUM so
>> join_ring=false would help. But this is very specific use case.
>>
>> Thanks
>> Anuj
>>
>>
>

Re: Join_ring=false Use Cases

[kurt Greaves]

It seems that you're correct in saying that writes don't propagate to a
node that has join_ring set to false, so I'd say this is a flaw. In reality
I can't see many actual use cases in regards to node outages with the
current implementation. The main usage I'd think would be to have
additional coordinators for CPU heavy workloads.

It seems to make it actually useful for repairs/outages we'd need to have
another option to turn on writes so that it behaved similarly to write
survey mode (but on already bootstrapped nodes).

Is there a reason we don't have this already? Or does it exist somewhere
I'm not aware of?

On 20 December 2016 at 17:40, Anuj Wadehra  wrote:

> No responses yet :)
>
> Any C* expert who could help on join_ring use case and the concern raised?
>
> Thanks
> Anuj
>
> On Tue, 13 Dec, 2016 at 11:31 PM, Anuj Wadehra
>  wrote:
> Hi,
>
> I need to understand the use case of join_ring=false in case of node
> outages. As per https://issues.apache.org/jira/browse/CASSANDRA-6961, you
> would want join_ring=false when you have to repair a node before bringing a
> node back after some considerable outage. The problem I see with
> join_ring=false is that unlike autobootstrap, the node will NOT accept
> writes while you are running repair on it. If a node was down for 5 hours
> and you bring it back with join_ring=false, repair the node for 7 hours and
> then make it join the ring, it will STILL have missed writes because while
> the time repair was running (7 hrs), writes only went to other others.
> So, if you want to make sure that reads served by the restored node at CL
> ONE will return consistent data after the node has joined, you wont get
> that as writes have been missed while the node is being repaired. And if
> you work with Read/Write CL=QUORUM, even if you bring back the node without
> join_ring=false, you would anyways get the desired consistency. So, how
> join_ring would provide any additional consistency in this case ??
>
> I can see join_ring=false useful only when I am restoring from Snapshot or
> bootstrapping and there are dropped mutations in my cluster which are not
> fixed by hinted handoff.
>
> For Example: 3 nodes A,B,C working at Read/Write CL QUORUM. Hinted
> Handoff=3 hrs.
> 10 AM Snapshot taken on all 3 nodes
> 11 AM: Node B goes down for 4 hours
> 3 PM: Node B comes up but data is not repaired. So, 1 hr of dropped
> mutations (2-3 PM) not fixed via Hinted Handoff.
> 5 PM: Node A crashes.
> 6 PM: Node A restored from 10 AM Snapshot, Node A started with
> join_ring=false, repaired and then joined the cluster.
>
> In above restore snapshot example, updates from 2-3 PM were outside hinted
> handoff window of 3 hours. Thus, node B wont get those updates. Node A data
> for 2-3 PM is already lost. So, 2-3 PM updates are only on one replica i.e.
> node C and minimum consistency needed is QUORUM so join_ring=false would
> help. But this is very specific use case.
>
> Thanks
> Anuj
>
>

Cipher Suite Cassandra 2.1.14 Encryption

[Jacob Shadix]

I was testing client encryption w/cqlsh and get the following error when
using TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 as the cipher. Any ideas why?

Last error: _ssl.c:492: EOF occurred in violation of protocol")})
-- Jacob Shadix

Re: Join_ring=false Use Cases

[Anuj Wadehra]

No responses yet :)
Any C* expert who could help on join_ring use case and the concern raised?
Thanks
Anuj 
 
  On Tue, 13 Dec, 2016 at 11:31 PM, Anuj Wadehra wrote: 
   Hi,
I need to understand the use case of join_ring=false in case of node outages. 
As per https://issues.apache.org/jira/browse/CASSANDRA-6961, you would want 
join_ring=false when you have to repair a node before bringing a node back 
after some considerable outage. The problem I see with join_ring=false is that 
unlike autobootstrap, the node will NOT accept writes while you are running 
repair on it. If a node was down for 5 hours and you bring it back with 
join_ring=false, repair the node for 7 hours and then make it join the ring, it 
will STILL have missed writes because while the time repair was running (7 
hrs), writes only went to other others. So, if you want to make sure that reads 
served by the restored node at CL ONE will return consistent data after the 
node has joined, you wont get that as writes have been missed while the node is 
being repaired. And if you work with Read/Write CL=QUORUM, even if you bring 
back the node without join_ring=false, you would anyways get the desired 
consistency. So, how join_ring would provide any additional consistency in this 
case ??
I can see join_ring=false useful only when I am restoring from Snapshot or 
bootstrapping and there are dropped mutations in my cluster which are not fixed 
by hinted handoff.
For Example: 3 nodes A,B,C working at Read/Write CL QUORUM. Hinted Handoff=3 
hrs.10 AM Snapshot taken on all 3 nodes11 AM: Node B goes down for 4 hours3 PM: 
Node B comes up but data is not repaired. So, 1 hr of dropped mutations (2-3 
PM) not fixed via Hinted Handoff.5 PM: Node A crashes.6 PM: Node A restored 
from 10 AM Snapshot, Node A started with join_ring=false, repaired and then 
joined the cluster.
In above restore snapshot example, updates from 2-3 PM were outside hinted 
handoff window of 3 hours. Thus, node B wont get those updates. Node A data for 
2-3 PM is already lost. So, 2-3 PM updates are only on one replica i.e. node C 
and minimum consistency needed is QUORUM so join_ring=false would help. But 
this is very specific use case.  
ThanksAnuj
  

RE: FW: Cassandra trigger to send notifications

[Oren Yekutieli]

Got it. Thanks!

Regards,
Oren

From: DuyHai Doan [mailto:doanduy...@gmail.com]
Sent: Tuesday, December 20, 2016 10:11 AM
To: user@cassandra.apache.org
Subject: Re: FW: Cassandra trigger to send notifications

Right now CDC is very very LOW LEVEL, you'll need to

1. Use a CommitLogReader to read the changes from the CDC files
2. Perform de-duplication by yourself

I'll blog post a technical deep dive about CDC in the future once I have time 
to play with it

On Mon, Dec 19, 2016 at 9:57 PM, Oren Yekutieli 
> wrote:
Thank you both Matija and Eric.
I have read somewhere about CDC but I didn’t know that it is already released.
I also didn’t find good documentation of it except for the design doc and Jira 
ticket, where in both cases it is hard to know what really was released.
As a newbie to Cassandra I will probably do need a more ‘user friendly’ CDC 
documentation. Is it available somewhere?

Regards,
Oren

From: Eric Stevens [mailto:migh...@gmail.com]
Sent: Saturday, December 17, 2016 12:32 AM
To: user@cassandra.apache.org
Subject: Re: FW: Cassandra trigger to send notifications


You probably want to look at change data capture rather than triggers: 
http://cassandra.apache.org/doc/latest/operating/cdc.html

Be aware that one of your criteria regarding operation order is going to be 
very difficult to guarantee due to eventual consistency.

On Fri, Dec 16, 2016, 2:43 AM Matija Gobec 
> wrote:
Hi Oren,

I've spent a reasonable time working out triggers and I would say that your 
best bet is doing this in the app.
Just publish a rabbitmq message from the app when you execute a statement.
If your goal is to have an audit then try batch writing data to the tables and 
delta to their audit counterparts.

Matija

On Fri, Dec 16, 2016 at 9:14 AM, Oren Yekutieli 
> wrote:
Hello,

In a Cassandra cluster I want to push a notification to rabbitmq whenever a 
change (insert/update/delete) was made to some Cassandra tables, with the 
following requirements:
The notifications should:

1.  Be ordered in the same order the changes were stored.

2.  Be sent only if the change was (or going to be) committed successfully.
And in case of insert/update:

3.  Include all the row values.

4.  Indicate what values were changed.

I’m trying to figure out if Cassandra triggers are the correct way to go.
According to 
http://www.datastax.com/dev/blog/whats-new-in-cassandra-2-0-prototype-triggers-support,
 one of the potential use cases for triggers is:
•>> implementing alerts/notifications
I also played a bit with the example given here: 
http://stackoverflow.com/questions/35161747/example-of-creating-triggers-in-cassandra-and-does-this-support-only-for-java
 and from what I read and learned so far I assume that:
Regarding #1, I doubt if the notification order can be kept since the trigger 
is invoked on the coordinator node while there are multiple clients that can 
connect to the various cluster nodes (coordinators).
Regarding #2, I’m not sure that notification will be sent only for changes that 
are going to be committed successfully since the trigger is invoked before the 
change is being applied.
Regarding #3, I seen that this requirement is fulfilled.
Regarding #4, I didn’t find a way to figure out what values are actually 
changed, without re-reading the current (old) values from the table which of 
course impose a significant performance penalty.

Are my assumptions correct?
If yes then triggers are not the right approach. What other ways can be taken?

Regards,
Oren

Re: FW: Cassandra trigger to send notifications

[DuyHai Doan]

Right now CDC is very very LOW LEVEL, you'll need to

1. Use a CommitLogReader to read the changes from the CDC files
2. Perform de-duplication by yourself

I'll blog post a technical deep dive about CDC in the future once I have
time to play with it

On Mon, Dec 19, 2016 at 9:57 PM, Oren Yekutieli 
wrote:

> Thank you both Matija and Eric.
>
> I have read somewhere about CDC but I didn’t know that it is already
> released.
>
> I also didn’t find good documentation of it except for the design doc and
> Jira ticket, where in both cases it is hard to know what really was
> released.
>
> As a newbie to Cassandra I will probably do need a more ‘user friendly’
> CDC documentation. Is it available somewhere?
>
>
>
> Regards,
>
> Oren
>
>
>
> *From:* Eric Stevens [mailto:migh...@gmail.com]
> *Sent:* Saturday, December 17, 2016 12:32 AM
> *To:* user@cassandra.apache.org
> *Subject:* Re: FW: Cassandra trigger to send notifications
>
>
>
> You probably want to look at change data capture rather than triggers:
> http://cassandra.apache.org/doc/latest/operating/cdc.html
>
> Be aware that one of your criteria regarding operation order is going to
> be very difficult to guarantee due to eventual consistency.
>
>
>
> On Fri, Dec 16, 2016, 2:43 AM Matija Gobec  wrote:
>
> Hi Oren,
>
>
>
> I've spent a reasonable time working out triggers and I would say that
> your best bet is doing this in the app.
>
> Just publish a rabbitmq message from the app when you execute a statement.
>
> If your goal is to have an audit then try batch writing data to the tables
> and delta to their audit counterparts.
>
>
>
> Matija
>
>
>
> On Fri, Dec 16, 2016 at 9:14 AM, Oren Yekutieli <
> oren.yekuti...@ecitele.com> wrote:
>
> Hello,
>
>
>
> In a Cassandra cluster I want to push a notification to rabbitmq whenever
> a change (insert/update/delete) was made to some Cassandra tables, with the
> following requirements:
>
> The notifications should:
>
> 1.  Be ordered in the same order the changes were stored.
>
> 2.  Be sent only if the change was (or going to be) committed
> successfully.
>
> And in case of insert/update:
>
> 3.  Include all the row values.
>
> 4.  Indicate what values were changed.
>
>
>
> I’m trying to figure out if Cassandra triggers are the correct way to go.
>
> According to http://www.datastax.com/dev/blog/whats-new-in-cassandra-2-
> 0-prototype-triggers-support, one of the potential use cases for triggers
> is:
>
> ·>> implementing alerts/notifications
>
> I also played a bit with the example given here: http://stackoverflow.com/
> questions/35161747/example-of-creating-triggers-in-
> cassandra-and-does-this-support-only-for-java and from what I read and
> learned so far I assume that:
>
> Regarding #1, I doubt if the notification order can be kept since the
> trigger is invoked on the coordinator node while there are multiple clients
> that can connect to the various cluster nodes (coordinators).
>
> Regarding #2, I’m not sure that notification will be sent only for changes
> that are going to be committed successfully since the trigger is invoked
> before the change is being applied.
>
> Regarding #3, I seen that this requirement is fulfilled.
>
> Regarding #4, I didn’t find a way to figure out what values are actually
> changed, without re-reading the current (old) values from the table which
> of course impose a significant performance penalty.
>
>
>
> Are my assumptions correct?
>
> If yes then triggers are not the right approach. What other ways can be
> taken?
>
>
>
> Regards,
>
> Oren
>
>
>
>
>
>