cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Charulata Sharma (charshar)" <>
Subject Re: Read after Write inconsistent at times
Date Fri, 24 Feb 2017 20:32:28 GMT
Hi All,
      Thanks for your replies. I do not see an issue with NTP or with dropped messages.
However the tombstones count on the specific CF shows me this. This essentially indicates
that there are as many tombstones as Live cells in the CF isin't?
Now is that an issue and can this cause inconsistent read ?

Average live cells per slice (last five minutes): 0.8631938498408056

Maximum live cells per slice (last five minutes): 1.0

Average tombstones per slice (last five minutes): 1.1477603751799115E-5

Maximum tombstones per slice (last five minutes): 1.0



From: Jonathan Haddad <<>>
Reply-To: "<>" <<>>
Date: Friday, February 24, 2017 at 9:42 AM
To: "<>" <<>>
Subject: Re: Read after Write inconsistent at times

WRT to NTP, I first encountered this issue on my first cluster.  The problem with ntp isn't
just if you're doing inserts, it's if you're doing inserts in combination with deletes, and
using server timestamps with a greater variance than the period between the delete and the
insert.  Basically, you end up with a delete in the future and an insert in the past, and
the delete timestamp > insert timestamp.

+1 to Jan's recommendation on checking for dropped messages.

On Fri, Feb 24, 2017 at 9:35 AM Petrus Gomes <<>>

Check the tombstone count, If is it to high, your query will be impacted.

If tombstone is a problem, you can try to reduce your "gc_grace_seconds" to reduce tombstone
count(Carefully because you use cross data centers).

Petrus Silva

On Fri, Feb 24, 2017 at 12:07 AM, Jan Kesten <<>>

are your nodes at high load? Are there any dropped messages (nodetool tpstats) on any node?

Also have a look at your system clocks. C* needs them in thight sync - via ntp for example.
Side hint: if you use ntp use the same set of upstreams on all of your nodes - ideal your
own one. Using<> might lead to minimal dirfts in time
across your cluster.

Another thing that could help you out is using client side timestamps:
(of course only when you are using a single client or all clients are in sync via ntp).

Am 24.02.2017 um 07:29 schrieb Charulata Sharma (charshar):

Hi All,

In my application sometimes I cannot read data that just got inserted. This happens very intermittently.
Both write and read use LOCAL QUOROM.

We have a cluster of 12 nodes which spans across 2 Data Centers and a RF of 3.

Has anyone encountered this problem and if yes what steps have you taken to solve it


Jan Kesten,<>
Tel.: +49 561/4739664-0<tel:%2B49%20561%2F4739664-0> FAX: -9 Mobil: +49 160 / 90 98
41 68<tel:%2B49%20160%20%2F%2090%2098%2041%2068>
enercast GmbH Universitätsplatz 12 D-34127 Kassel HRB15471 Online-Prognosen für erneuerbare Energien
Geschäftsführung: Thomas Landgraf (CEO), Bernd Kratz (CTO), Philipp Rinder (CSO)

Diese E-Mail und etwaige Anhänge können vertrauliche und/oder rechtlich geschützte Informationen
enthalten. Falls Sie nicht der angegebene Empfänger sind oder falls diese E-Mail irrtümlich
an Sie adressiert wurde, benachrichtigen Sie uns bitte sofort durch Antwort-E-Mail und löschen
Sie diese E-Mail nebst etwaigen Anlagen von Ihrem System. Ebenso dürfen Sie diese E-Mail
oder ihre Anlagen nicht kopieren oder an Dritte weitergeben. Vielen Dank.

This e-mail and any attachment may contain confidential and/or privileged information. If
you are not the named addressee or if this transmission has been addressed to you in error,
please notify us immediately by reply e-mail and then delete this e-mail and any attachment
from your system. Please understand that you must not copy this e-mail or any attachment or
disclose the contents to any other person. Thank you for your cooperation.

View raw message