Cassandra 数据在没有设置 TTL 的情况下压缩直到删除？答案

【问题标题】：Cassandra data compacted until deletion with no TTL set up?Cassandra 数据在没有设置 TTL 的情况下压缩直到删除？
【发布时间】：2019-11-26 18:49:29
【问题描述】：

我正在我的 Cassandra 集群 (v3.11.5) 上测试节点修复，同时使用 cassandra-stress (v3.11.4) 对其进行压力测试。磁盘空间用完，修复失败。结果，八卦在节点上被禁用。被反压缩的 Sstable 被清理（实际上 = 删除），在一分钟内将磁盘使用量降低了约一半（每个节点约 1.5TB）。我明白这一点。

我不明白的是接下来发生的事情。 sstables 开始不断压缩成更小的sstables，并最终被删除。结果，磁盘使用量继续下降（这次是缓慢的），大约一天后，它从每个节点约 1.5TB 下降到每个节点约 50GB。驻留在集群中的数据是由 cassandra-stress 随机生成的，因此我无法确认它是否完好无损，但我发现它极不可能，因为磁盘使用率下降了很多。另外我没有设置 TTL（至少我知道，可能会丢失一些东西），所以我不希望数据被删除。但我相信是这样的。

无论如何，谁能指出发生了什么？

表架构：

> desc test-table1;

CREATE TABLE test-keyspace1.test-table1 (
    event_uuid uuid,
    create_date timestamp,
    action text,
    business_profile_id int,
    client_uuid uuid,
    label text,
    params text,
    unique_id int,
    PRIMARY KEY (event_uuid, create_date)
) WITH CLUSTERING ORDER BY (create_date DESC)
    AND bloom_filter_fp_chance = 0.1
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = ''
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.LeveledCompactionStrategy'}
    AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.DeflateCompressor'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 864000
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 0
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

日志：

DEBUG [CompactionExecutor:7] 2019-11-23 20:17:19,828 CompactionTask.java:255 - Compacted (59ddec80-0e20-11ea-9612-67e94033cb24) 4 sstables to [/data/cassandra/data/test-keyspace1/test-table1-f592e9600b9511eab562b36ee84fdea9/md-3259-big,] to level=0.  93.264GiB to 25.190GiB (~27% of original) in 5,970,059ms.  Read Throughput = 15.997MiB/s, Write Throughput = 4.321MiB/s, Row Throughput = ~909/s.  1,256,595 total partitions merged to 339,390.  Partition merge counts were {2:27340, 3:46285, 4:265765, }
(...)
DEBUG [CompactionExecutor:7] 2019-11-24 03:50:14,820 CompactionTask.java:255 - Compacted (e1bd7f50-0e4b-11ea-9612-67e94033cb24) 32 sstables to [/data/cassandra/data/test-keyspace1/test-table1-f592e9600b9511eab562b36ee84fdea9/md-3301-big,] to level=0.  114.787GiB to 25.150GiB (~21% of original) in 14,448,734ms.  Read Throughput = 8.135MiB/s, Write Throughput = 1.782MiB/s, Row Throughput = ~375/s.  1,546,722 total partitions merged to 338,859.  Partition merge counts were {1:12732, 2:42441, 3:78598, 4:50454, 5:36032, 6:52989, 7:21216, 8:34681, 9:9716, }
DEBUG [CompactionExecutor:15] 2019-11-24 03:50:14,852 LeveledManifest.java:423 - L0 is too far behind, performing size-tiering there first
DEBUG [CompactionExecutor:15] 2019-11-24 03:50:14,852 CompactionTask.java:155 - Compacting (85e06040-0e6d-11ea-9612-67e94033cb24) [/data/cassandra/data/test-keyspace1/test-table1-f592e9600b9511eab562b36ee84fdea9/md-3259-big-Data.db:level=0, /data/cassandra/data/test-keyspace1/test-table1-f592e9600b9511eab562b36ee84fdea9/md-3299-big-Data.db:level=0, /data/cassandra/data/test-keyspace1/test-table1-f592e9600b9511eab562b36ee84fdea9/md-3298-big-Data.db:level=0, /data/cassandra/data/test-keyspace1/test-table1-f592e9600b9511eab562b36ee84fdea9/md-3300-big-Data.db:level=0, /data/cassandra/data/test-keyspace1/test-table1-f592e9600b9511eab562b36ee84fdea9/md-3301-big-Data.db:level=0,]
(...)
DEBUG [NonPeriodicTasks:1] 2019-11-24 06:02:50,117 SSTable.java:105 - Deleting sstable: /data/cassandra/data/test-keyspace1/test-table1-f592e9600b9511eab562b36ee84fdea9/md-3259-big

编辑：

我进行了一些额外的测试。据我所知，没有设置 TTL，请在 cassandra-stress 开始插入数据后立即查看查询结果：

> SELECT event_uuid, create_date, ttl(action), ttl(business_profile_id), ttl(client_uuid), ttl(label), ttl(params), ttl(unique_id) FROM test-table1 LIMIT 1;

 event_uuid                           | create_date                     | ttl(action) | ttl(business_profile_id) | ttl(client_uuid) | ttl(label) | ttl(params) | ttl(unique_id)
--------------------------------------+---------------------------------+-------------+--------------------------+------------------+------------+-------------+----------------
 00000000-001b-adf7-0000-0000001badf7 | 2018-01-10 10:08:45.476000+0000 |        null |                     null |             null |       null |        null |           null

所以 TTL 和墓碑删除都不应该与这个问题有关。很可能没有重复，因为数据是高度随机的。也没有对复制因子进行任何更改。

我发现每次 cassandra-stress 停止后数据量都会减少。可悲的是，仍然不知道确切的原因。

【问题讨论】：

你能在其中一个 sstables 上做一个 sstabledump 来看看里面吗？如果它们不是太大，请查看其中的一些。
我可以，但我应该寻找什么？乍一看，唯一突出的是“聚类”字段，它是一个时间戳，有时取值可以追溯到 1975 年。不确定这是否可以预期。
我只是想了解一下您的结构。实际上，我在答案中提到的一种情况必须发生。这是在压缩时“清理”数据的唯一方式。您的上述信息显示没有 TTL，但想用 sstabledump 仔细检查（即使您在上面发布的结果应该足够好）。另外，尝试查看 sstables 中是否有任何重复的键。如果运行删除，墓碑也可能存在。正在寻找那些。
我什至不能 100% 确定数据是否已清理完毕。这很可能，但我唯一确定的是磁盘使用率下降，并且正在进行压缩和 sstable 删除。将尝试查看垃圾场。希望它们会有一些有用的东西。

标签： cassandra

【解决方案1】：

我想，当您从 Cassandra 的角度考虑时，对于您的数据为何会缩小，确实只有几个选项： 1) TTL 在 GC Grace 之后过期 2) 删除过去的 GC 宽限期 3）多个sstables中存在相同的记录（即“更新”） 4) 将 RF 更改为较低的数字（本质上是“清理” - 令牌重新分配）

在上述任何情况下，当压缩运行时，它会删除或协调可能会减少空间消耗的记录。如果不再有 sstables，就很难确定发生了哪些（如果不是上述情况的组合）。

-吉姆

【讨论】：

我已经用附加信息编辑了原始帖子。