You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Ryan Svihla <rs...@foundev.pro> on 2015/01/06 20:04:42 UTC

Re: Re: Cassandra update row after delete immediately, and read that, the data not right?

so the coordinator node of a given request sets the timestamp unless
overridden by the client (which you can do on a per statement basis), while
you can move all of your timestamps to client side, eventually as you add
more clients you have a similar problem set and will still have to use NTP
to keep your clients in sync.

Ultimately for a large variety of reasons, it's probably better to just
make sure your cassandra nodes are in sync.


On Thu, Dec 25, 2014 at 10:26 PM, <yh...@sina.com> wrote:

> Hi, all:
>
>    The test program first insert one row and then delete it, then read it
> to compare.
>
>    The test program run this flow row by row, not batch.
>
>
>     Today I found the problem is caused by the deletion timestamp. The
> machine running the test program may not be time sync with cassandra
> machine strictly.
>
>
>
>      Why cassandra use the local timestamp for deletion??
>
>
>
> 发件人:Jack Krupansky <ja...@gmail.com>
> 收件人:user@cassandra.apache.org, yhqruc@sina.com
> 主题:Re: Cassandra update row after delete immediately, and read that, the
> data not right?
> 日期:2014年12月25日 21点04分
>
> What RF?
>
> Is the update and read immediately after the delete and insert, or is the
> read after doing all the updates?
>
> Is the delete and insert done with a single batch?
>
> -- Jack Krupansky
>
> On Thu, Dec 25, 2014 at 4:14 AM, <yh...@sina.com> wrote:
>
> Hi, all
>   I write a program to test the cassandra2.1. I have 6 nodes cluster.
>   First, I insert 1 million row data into cassandra. the row key from 1 to
> 1000000.
>
>   Then I run my test program. My test program first delete(use batch
> mutate) the row and insert (use batch mutate) that row,
>
>      then read (use gen_slice_range) the same row. After that check
> whether the read data is same with the insert data or not.
>   The consistency level used is quorum.
>
>   I found there some cases that not the same. About 1/10000. In this error
> cases, some column is not same.
>
>   Then I use cassandra-cli to check the data, found that column is not
> exist. It seems insert partly.
>   My test program has 20 threads. the QPS 800 about
>
>   What's wrong with cassandra??
>
>
> Thanks!
>
>
>


-- 

Thanks,
Ryan Svihla