Growing Hints

Hello All We have one unusual issue on our cluster. We are seeing growing hints table on node although all the nodes are up and coming online with notetool status. I know Cassandra appends the hints in case if there is write timeout for other nodes. In our case all nodes are up and

Re: Insert with both TTL and timestamp behavior

Indeed, the TTL is computed based on LOCAL timestamp of the server and not based on the PROVIDED timestamp by the client ... (according to Mastering Apache Cassandra, 2nd edition, Nishant Neeraj, PackPublishing) On Wed, Dec 28, 2016 at 10:15 PM, Voytek Jarnot wrote: >

unsubscribe

weird jvm metrics

Hi There - I recently upgraded from cassandra 3.5 to 3.9 (DDC), and I noticed that the "new" jvm metrics are reporting with an extra '.' character in them. Here is a snippet of what I see from one of my nodes: ubuntu@ip-10-0-2-163:~$ sudo tcpdump -i eth0 -v dst port 2003 -A | grep 'jvm'

Re: Insert with both TTL and timestamp behavior

>It's not clear to me why for your use case you would want to manipulate the timestamps as you're loading the records unless you're concerned about conflicting writes getting applied in the correct order. Simple use-case: want to load historical data, want to use TWCS, want to use TTL. Scenario:

Re: Insert with both TTL and timestamp behavior

The purpose of timestamps is to guarantee out-of-order conflicting writes are resolved as last-write-wins. Cassandra doesn't really expect you to be writing timestamps with wide variations from record to record. Indeed, if you're doing this, it'll violate some of the assumptions in places such

Re: Openstack and Cassandra

Kilo is a bit old but the good news is that CPU pinning is available which IMHO is a must to run C* on Production.Of course your bottleneck will be shared HDDs. Best, Romain Le Mardi 27 décembre 2016 10h21, Shalom Sagges a écrit : Hi Romain,  Thanks for the

Insert with both TTL and timestamp behavior

It appears as though, when inserting with "using ttl [foo] and timestamp [bar]" that the TTL does not take the provided timestamp into account. In other words, the TTL starts at insert time, not at the time specified by the timestamp. Similarly, if inserting with just "using timestamp [bar]" and

Bulk Import Question

I'm following the example here for doing a bulk import into Cassandra: https://github.com/yukim/cassandra-bulkload-example Is there a way to get a number of rows written to a sstable set created via CQLSSTableWriter, without importing the sstable set into Cassandra? I'd like to do some QA on

Re: Read efficiency question

In the first case, the partitioning is based on key1,key2,key3. In the second case, partitioning is based on key1 , key2. Additionally you have a clustered key key3. This means within a partition you can do range queries on key3 efficiently. That is the difference. regards On Tue, Dec 27, 2016