Re: time tracking for down node for nodetool repair

Thanks everyone for your valuable suggestion. Really appreciate it Regards, Kunal Vaid On Mon, Apr 8, 2019 at 7:41 PM Nitan Kainth wrote: > Valid suggestion. Stick to the plan, avoid downtime of a node more than > hinted handoff window. OR increase window to a larger value, if you know it >

Re: Issue while updating a record in 3 node cassandra cluster deployed using kubernetes

>> I have a 3 node cassandra cluster with Replication factor as 2 and >> read-write consistency set to QUORUM. I am not sure what you want to achieve with this. If you have three nodes and RF 2, for each write there will be two replicas, right ... If one of your replicas is down out of two in

All time blocked in nodetool tpstats

Hi, My nodetool tpstats arw showing all time blocked high numbers a d also read dropped messages as 400 . Client is expeirince high timeouts. Checked few online forums they recommend to increase, native_transport_max_threads. As of jow its commented with 128 .. Is it adviabke to increase this and

Re: Questions about C* performance related to tombstone

Normal deletes are fine. Sadly there's a lot of hand wringing about tombstones in the generic sense which leads people to try to work around *every* case where they're used. This is unnecessary. A tombstone over a single row isn't a problem, especially if you're only fetching that one row back.

Re: How to monitor datastax driver compression performance?

tlp-stress has support for customizing payloads, but it's not documented very well. For a given data model (say the KeyValue one), you can override what tlp-stress will send over. By default it's pretty small, a handful of bytes. If you pass --field.keyvalue.value (the table name + the field

Re: [EXTERNAL] Issue while updating a record in 3 node cassandra cluster deployed using kubernetes

Thank you Sean for your response. We are also suspecting the same and analyzing/troubleshooting it around queries associated timestamp. Thanks, Mahesh Daksha On Tue, Apr 9, 2019 at 7:08 PM Durity, Sean R wrote: > My first suspicion would be to look at the server times in the cluster. It >

Questions about C* performance related to tombstone

Hi, I have a table defined like this: CREATE TABLE myTable ( course_id text, assignment_id text, assignment_item_id text, data text, boolean active, PRIMARY KEY (course_id, assignment_id, assignment_item_id) ); i.e. course_id as the partition key and assignment_id, assignment_item_id as

RE: [EXTERNAL] Issue while updating a record in 3 node cassandra cluster deployed using kubernetes

My first suspicion would be to look at the server times in the cluster. It looks like other cases where a write occurs (with no errors) but the data is not retrieved as expected. If the write occurs with an earlier timestamp than the existing data, this is the behavior you would see. The write

Re: How to monitor datastax driver compression performance?

tlp-stress allow us to define size of rows? Because I will see the benefit of compression in terms of request rates only if the compression ratio is significant, i.e. requires less network round trips. This could be done generating bigger partitions with parameters -n and -p, i.e. decreasing the

Issue while updating a record in 3 node cassandra cluster deployed using kubernetes

Hello All, I have a 3 node cassandra cluster with Replication factor as 2 and read-write consistency set to QUORUM. We are using Spring data cassandra. All infrastructure is deployed using kubernetes. Now in normal use case many records gets inserted to cassandra table. Then we try to

Re: ***UNCHECKED*** Query regarding cassandra column write time set by client Timestamp Generator

Thank you Ben and Varun. Will try these approaches. On Tue, Apr 9, 2019 at 3:12 PM Varun Barala wrote: > I'm not sure about the use cases. But other approaches can also be > considered:- > > * Every mutation will have the timestamp in the commitlog [So taking > backup of the commitlogs will

Re: ***UNCHECKED*** Query regarding cassandra column write time set by client Timestamp Generator

I'm not sure about the use cases. But other approaches can also be considered:- * Every mutation will have the timestamp in the commitlog [So taking backup of the commitlogs will give you this functionality] * At client side, you fetch the existing writetime for those columns from the db and also

Re: ***UNCHECKED*** Query regarding cassandra column write time set by client Timestamp Generator

Maybe stabledump can help you? https://cassandra.apache.org/doc/4.0/tools/sstable/sstabledump.html --- *Ben Slater* *Chief Product Officer* Read our latest technical blog

Re: ***UNCHECKED*** Query regarding cassandra column write time set by client Timestamp Generator

Thanks Ben for your response. WRITETIME gives the information of about the column value already residing int the table. We intend to know the timestamp of the record which is about to apply/update. This is needed to understand the timestamp difference of the data residing in table with the one

Re: ***UNCHECKED*** Query regarding cassandra column write time set by client Timestamp Generator

Not in the logs but I think you should be able to use the WRITETIME function to view via CQL (see https://cassandra.apache.org/doc/latest/cql/dml.html#select) Cheers Ben --- *Ben Slater* *Chief Product Officer*

Re: Multi-DC replication and hinted handoff

Hi, an update: I am pretty sure it is a problem with insufficient bandwidth. I can’t be sure because Cassandra does not seem to provide debug information on hint creation (only when replaying hints). When the bandwidth issue is solved I will try to reproduce the accumulation of hints by

***UNCHECKED*** Query regarding cassandra column write time set by client Timestamp Generator

Hello, I have configured the timestamp generator at cassandra client as below: cluster.setTimestampGenerator(new AtomicMonotonicTimestampGenerator()); My cassandra client inserting and updating few of the rows in a table. My query is where in the cassandra debug logs I can see the query write