Re: Secondary Index Cleanup

2018-03-02 Thread malte


We use 3.11.0 on Linux.



What's the C* version do you use? Sounds like the secondary index is very
out of sync with the parent cf.

On Fri, Mar 2, 2018 at 6:23 AM, Malte Krüger 
wrote:


hi,

we have an CF which is about 2 gb in size, it has a seondary index on one
field (UUID).

the index has a size on disk of about 10 gb. it only shrinks a little when
forcing a compaction through jmx.

if i use sstabledump i see a lot of these:

"partition" : {
  "key" : [ "123c50d1-1ceb-489d-8427-2f34065325f8" ],
  "position" : 306166973
},
"rows" : [
  {
"type" : "row",
"position" : 306167031,
"clustering" : [ "f28f46930805495aa7d6cba291d92e87" ],
"liveness_info" : { "tstamp" : "2017-10-30T16:49:37.160361Z" },
"cells" : [ ]
  },

...

normally i can find the key as an indexed field, but most of the keys in
the dump do no longer exist in the parent CF.

these keys are sometimes months old. (we have gc_grace_seconds set to 30
mins)

if i use nodetool rebuild_index it does not help, but if i drop the index
und recreate it size goes down  two several hundred mb!


what is the reason the cleanup does not work automatically and how can i
fix this?

-Malte


-
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org





--
Dikang





-
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org



Re: Secondary Index Cleanup

2018-03-02 Thread Dikang Gu
What's the C* version do you use? Sounds like the secondary index is very
out of sync with the parent cf.

On Fri, Mar 2, 2018 at 6:23 AM, Malte Krüger 
wrote:

> hi,
>
> we have an CF which is about 2 gb in size, it has a seondary index on one
> field (UUID).
>
> the index has a size on disk of about 10 gb. it only shrinks a little when
> forcing a compaction through jmx.
>
> if i use sstabledump i see a lot of these:
>
> "partition" : {
>   "key" : [ "123c50d1-1ceb-489d-8427-2f34065325f8" ],
>   "position" : 306166973
> },
> "rows" : [
>   {
> "type" : "row",
> "position" : 306167031,
> "clustering" : [ "f28f46930805495aa7d6cba291d92e87" ],
> "liveness_info" : { "tstamp" : "2017-10-30T16:49:37.160361Z" },
> "cells" : [ ]
>   },
>
> ...
>
> normally i can find the key as an indexed field, but most of the keys in
> the dump do no longer exist in the parent CF.
>
> these keys are sometimes months old. (we have gc_grace_seconds set to 30
> mins)
>
> if i use nodetool rebuild_index it does not help, but if i drop the index
> und recreate it size goes down  two several hundred mb!
>
>
> what is the reason the cleanup does not work automatically and how can i
> fix this?
>
> -Malte
>
>
> -
> To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
> For additional commands, e-mail: user-h...@cassandra.apache.org
>
>


-- 
Dikang


Secondary Index Cleanup

2018-03-02 Thread Malte Krüger

hi,

we have an CF which is about 2 gb in size, it has a seondary index on 
one field (UUID).


the index has a size on disk of about 10 gb. it only shrinks a little 
when forcing a compaction through jmx.


if i use sstabledump i see a lot of these:

    "partition" : {
  "key" : [ "123c50d1-1ceb-489d-8427-2f34065325f8" ],
  "position" : 306166973
    },
    "rows" : [
  {
    "type" : "row",
    "position" : 306167031,
    "clustering" : [ "f28f46930805495aa7d6cba291d92e87" ],
    "liveness_info" : { "tstamp" : "2017-10-30T16:49:37.160361Z" },
    "cells" : [ ]
  },

...

normally i can find the key as an indexed field, but most of the keys in 
the dump do no longer exist in the parent CF.


these keys are sometimes months old. (we have gc_grace_seconds set to 30 
mins)


if i use nodetool rebuild_index it does not help, but if i drop the 
index und recreate it size goes down  two several hundred mb!



what is the reason the cleanup does not work automatically and how can i 
fix this?


-Malte


-
To unsubscribe, e-mail: user-unsubscr...@cassandra.apache.org
For additional commands, e-mail: user-h...@cassandra.apache.org