Aaron,

Everytime after I ran the truncate I did

select count(*) from datapoints;

and a non zero value was returned.

I never got any errors after the truncate. All the nodes seem to be
available as I was connected to all the servers via ssh and ran cassandra
using ./cassandra -f

I had to do some more testing so I wrote some c# to delete the rows
explicitly.

I am currently benchtesting our cluster so will do a truncate again after I
have finished inserting data and will report my results.


On 8 February 2013 02:13, aaron morton <aa...@thelastpickle.com> wrote:

> Double check the truncate worked, all nodes must be available for it
> execute.
>
> If you can provide the output from the cqlsh from truncating and selecting
> that would be helpful.
>
> Cheers
>
> -----------------
> Aaron Morton
> Freelance Cassandra Developer
> New Zealand
>
> @aaronmorton
> http://www.thelastpickle.com
>
> On 8/02/2013, at 2:55 AM, Jabbar <aja...@gmail.com> wrote:
>
> Hello,
>
> I'm having problems truncating or deleting the contents of a table. If I
> truncate the table and then do a select count(*) I get a value above zero.
>  If I drop the table, recreate the table the select count(*) still returns
> a non zero value.
>
> The truncate or delete operation does not return any errors.
>
> I am using cassandra 1.2.1 with java 1.6.0 u 39 64 bit in centos 6.3
>
> My keyspace definition is
>
> CREATE KEYSPACE studata WITH replication = {
>   'class': 'SimpleStrategy',
>   'replication_factor': '3'
> };
>
>
> My table definition is
>
> CREATE TABLE datapoints (
>   siteid bigint,
>   channel int,
>   time timestamp,
>   data float,
>   PRIMARY KEY ((siteid, channel), time)
> ) WITH
>   bloom_filter_fp_chance=0.010000 AND
>   caching='KEYS_ONLY' AND
>   comment='' AND
>   dclocal_read_repair_chance=0.000000 AND
>   gc_grace_seconds=864000 AND
>   read_repair_chance=0.100000 AND
>   replicate_on_write='true' AND
>   compaction={'class': 'SizeTieredCompactionStrategy'} AND
>   compression={'sstable_compression': 'SnappyCompressor'};
>
>
> It has 3,504,000,000  rows, consisting of 100,000 partition keys.
>
>
> Is there anything that I'm doing wrong?
>
>
>
> --
> Thanks
>
>  A Jabbar Azam
>
>
>


-- 
Thanks

 A Jabbar Azam

Reply via email to