Надгробия Кассандры не удаляются через месяц после фактического рекордного TTL

Возникла проблема с DSE 4.7.

Надгробия не удаляются даже после сжатия, очистки, перестроения_индекса и восстановления. записи имеют 15-дневный ttl.

вывод sstablemetadata предполагает, что 90% надгробий

Любые идеи?

стабильный вывод метаданных

SSTable: ./abcd-abcd-ka-478675
Partitioner: org.apache.cassandra.dht.Murmur3Partitioner
Bloom Filter FP chance: 0.010000
Minimum timestamp: 1527521280829593
Maximum timestamp: 1527596173976435
SSTable max local deletion time: 1528892173
Compression ratio: 0.36967428395684393
Estimated droppable tombstones: 0.9073013816277629
SSTable Level: 0
Repaired at: 0
ReplayPosition(segmentId=1520529283052, position=4626679)
Estimated tombstone drop times:%n
1528817679:  18318196
1528818619:  20753822
1528819513:  24176310
.
.
.

Count               Row Size        Cell Count
1                          0                 0
2                          0           1752560
3                          0                 0
4                          0           6355421
5                          0                 0
6                          0            687302
7                          0                 0
8                          0            529613
10                         0            444801
12                         0            410107
14                         0            456011
17                         0           1347893
20                         0            184960
24                         0            152814
.
.
.
770                  1347893               137
924                   184960               109
1109                  220403                68
1331                  121620                86
1597                 2044030               102
1916                  185601               195
2299                  184816            158273
2759                  868754                 0
3311                   62795                 0
3973                    1668                 0
4768                    2143                 0
5722                 1812541                 0
6866                     828                 0
.
.
.             
Ancestors: [476190, 474027, 475201, 478160]
Estimated cardinality: 20059264

cassandra datastax tombstone datastax-enterprise cassandra-2.1
person Vikas Lalwani    schedule 03.07.2018    source источник
comment
что такое gc_grace_period?   -  person Alex Ott    schedule 03.07.2018
comment
какую стратегию компакации вы используете?   -  person root    schedule 03.07.2018
comment
Стратегия сжатия — DateTieredCompactionStrategy, а gc_grace_period — 864000 (10 дней). Это 20 дней сверх льготного периода gc.   -  person Vikas Lalwani    schedule 04.07.2018
comment
Я столкнулся с почти такой же проблемой: O   -  person Raghvendra Singh    schedule 20.07.2018

Ответы (2)


arrow_upward
1
arrow_downward

Cassandra помечает данные TTL надгробной плитой по истечении запрошенного времени. Надгробие существует для gc_grace_seconds. После того как данные помечены надгробной плитой, они автоматически удаляются в ходе обычного процесса сжатия. вы можете попытаться запустить серьезное уплотнение, чтобы выселить надгробную плиту.

person Payal    schedule 04.07.2018
comment
nodetool compact работал на некоторых нодах, на некоторых нет. - person Vikas Lalwani; 06.07.2018
comment
Основное уплотнение работало на большинстве узлов, но это все еще не объясняет, почему надгробия не были удалены после льготного периода gc. - person Vikas Lalwani; 24.07.2018

arrow_upward
0
arrow_downward

Надгробия удаляются после нормального уплотнения. Но все же иногда вы находите устаревшие данные (даже в prod) в надгробии. Причина может заключаться в том, что из всех узлов в этом кластере один не работает, и данные из надгробия не были удалены из-за этого узла. Также иногда нулевые значения вставляются в первичный ключ, что приводит к захоронению данных.

person Techturff    schedule 03.07.2018