For tracking delay in very recent versions, this exists:
> On Jul 11, 2018, at 1:05 AM, Simon Fontana Oscarsson
> <simon.fontana.oscars...@ericsson.com> wrote:
> I thought you just wanted to test how big delay you have, that's why I
> suggested trace.
> Your best option is to write with EACH_QUORUM as Alain said.
> That way you will get a response when the write is successful on all dcs.
> The downside is that the request will fail if one dc is down.
> As usual it's up to you to decide if that's acceptable or not.
> You could follow up with a LOCAL_QUORUM request if the EACH_QUORUM fails and
> rely on hints and repair to get consistency eventually.
> SIMON FONTANA OSCARSSON
> Software Developer
> Ölandsgatan 1
> 37133 Karlskrona, Sweden
>> On tis, 2018-07-10 at 16:32 +0000, Saladi Naidu wrote:
>> Trace would be significant burden on the cluster and it has to be on all the
>> time. I am trying to find a way to know when a row is written on demand
>> basis, is there a way to determine that?
>> Naidu Saladi
>> On Tuesday, July 10, 2018 2:24 AM, Simon Fontana Oscarsson
>> <simon.fontana.oscars...@ericsson.com> wrote:
>> Have you tried trace?
>> SIMON FONTANA OSCARSSON
>> Software Developer
>> Ölandsgatan 1
>> 37133 Karlskrona, Sweden
>>> On mån, 2018-07-09 at 19:30 +0000, Saladi Naidu wrote:
>>> Cassandra is an eventual consistent DB, how to find when a row is actually
>>> written in multi DC environment? Here is the problem I am trying to solve
>>> - I have multi DC (3 DC's) Cassandra cluster/ring - One of the application
>>> wrote a row to DC1(using Local Quorum) and within span of 50 ms, it tried
>>> to read same row from DC2 and could not find
>>> row. Our both DC's have sub milli second latency at network level, usually
>>> <2 ms. We promised 20 ms consistency. In this case Application could not
>>> find the row in DC2 in 50 ms
>>> I tried to use "select WRITETIME(authorizations_json) from
>>> token_authorizations where ...." to find when the Row is written in each
>>> DC, but both DC's returned same Timestamp. After further
>>> I found that Client V3 onwards Timestamp is supplied at Client level so
>>> WRITETIME does not help
>>> So how to determine when the row is actually written in each DC?
>>> Naidu Saladi