清除未使用的 Cassandra 目录的最佳方法是什么

Question

为什么Cassandra的gc在压缩过程中没有删除列族中未使用的目录？如何安全地删除它们？

我有一个 5 节点的 Cassandra 集群：

# nodetool status
Datacenter: datacenter1
=======================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.97.18.21  5.13 GiB   256          60.4%             8a6828d8-db43-4722-82fd-dd37ec1c25a1  rack1
UN  10.97.18.23  7.53 GiB   256          60.4%             adb18dfd-3cef-4ae3-9766-1e3f17d68588  rack1
UN  10.97.18.22  8.3 GiB    256          62.8%             1d6c453a-e3fb-4b3b-b7c1-689e7c8fbbbb  rack1
UN  10.97.18.25  5.1 GiB    256          60.1%             c8e4a4dc-4a05-4bac-b4d2-669fae9282b0  rack1
UN  10.97.18.24  7.97 GiB   256          56.3%             f2732a23-b70a-41a5-aaaa-1be95002ee8a  rack1

我有一个密钥空间"loan_products"，只有一个列系列"事件"：

[cqlsh 5.0.1 | Cassandra 3.11.1 | CQL spec 3.4.4 | Native protocol v4]
Use HELP for help.
cqlsh> 
cqlsh> DESCRIBE KEYSPACE loan_products ;
CREATE KEYSPACE loan_products WITH replication = {'class': 'SimpleStrategy', 'replication_factor': '3'}  AND durable_writes = true;
CREATE TABLE loan_products.events (
persistence_id text,
partition_nr bigint,
sequence_nr bigint,
timestamp timeuuid,
timebucket text,
event blob,
event_manifest text,
message blob,
meta blob,
meta_ser_id int,
meta_ser_manifest text,
ser_id int,
ser_manifest text,
tag1 text,
tag2 text,
tag3 text,
used boolean static,
writer_uuid text,
PRIMARY KEY ((persistence_id, partition_nr), sequence_nr, timestamp, timebucket)
) WITH CLUSTERING ORDER BY (sequence_nr ASC, timestamp ASC, timebucket ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
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';

我根本没有快照：

# nodetool listsnapshots
Snapshot Details: 
There are no snapshots

列系列的默认gc_grace_seconds = 864000(10天)，因此 gc 不得不删除逻辑删除等，但它们仍然存在于文件系统中。Parallel-ssh 显示：

[1] 11:50:34 [SUCCESS] 10.97.18.21
total 20
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 13:01 events-a83b3be0e61711e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 13:02 events-bbedb500e61c11e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 19:08 events-48c2b750e61d11e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 19:19 events-16c0b670e65011e7a2863103117dd196
drwxr-xr-x. 3 cassandra cassandra 4096 янв 15 11:46 events-c156cc40e65111e7a2863103117dd196
[2] 11:50:34 [SUCCESS] 10.97.18.22
total 20
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 13:00 events-a83b3be0e61711e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 13:01 events-bbedb500e61c11e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 19:08 events-48c2b750e61d11e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 19:19 events-16c0b670e65011e7a2863103117dd196
drwxr-xr-x. 3 cassandra cassandra 4096 янв 15 11:49 events-c156cc40e65111e7a2863103117dd196
[3] 11:50:34 [SUCCESS] 10.97.18.23
total 20
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 13:00 events-a83b3be0e61711e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 13:01 events-bbedb500e61c11e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 19:07 events-48c2b750e61d11e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 19:19 events-16c0b670e65011e7a2863103117dd196
drwxr-xr-x. 3 cassandra cassandra 4096 янв 15 11:48 events-c156cc40e65111e7a2863103117dd196
[4] 11:50:34 [SUCCESS] 10.97.18.25
total 20
drwxr-xr-x. 3 cassandra cassandra 4096 янв  9 15:08 events-a83b3be0e61711e7a2863103117dd196
drwxr-xr-x. 3 cassandra cassandra 4096 янв  9 15:08 events-bbedb500e61c11e7a2863103117dd196
drwxr-xr-x. 3 cassandra cassandra 4096 янв  9 15:08 events-48c2b750e61d11e7a2863103117dd196
drwxr-xr-x. 3 cassandra cassandra 4096 янв  9 15:08 events-16c0b670e65011e7a2863103117dd196
drwxr-xr-x. 3 cassandra cassandra 4096 янв 15 11:45 events-c156cc40e65111e7a2863103117dd196
[5] 11:50:34 [SUCCESS] 10.97.18.24
total 20
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 13:00 events-a83b3be0e61711e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 13:01 events-bbedb500e61c11e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 19:08 events-48c2b750e61d11e7a2863103117dd196
drwxr-xr-x. 4 cassandra cassandra 4096 дек 21 19:19 events-16c0b670e65011e7a2863103117dd196
drwxr-xr-x. 3 cassandra cassandra 4096 янв 15 11:50 events-c156cc40e65111e7a2863103117dd196

由于我只看到一个 ID为 c156cc40e65111e7a2863103117dd196的目录正在使用中，上次更新是在 1 月 15 日

Answer 1

默认情况下，每当删除列系列时，Cassandra 都会拍摄快照。这是设计使然，以防止意外截断(删除表中的所有记录)或意外删除该表。Cassandra.yaml 中控制这一点的参数auto_snapshot

是否在密钥空间截断之前拍摄数据的快照 或删除列族。强烈建议默认为 true 应用于提供数据安全。如果将此标志设置为 false，则将 在截断或丢弃时丢失数据。auto_snapshot：真

因此，根据您显示的屏幕截图，看起来"事件"表至少被删除了 4 次并重新创建。因此，清理此问题的正确方法是首先找出Cassandra在键空间中用于给定表的正确UUID。在您的情况下，查询将是

select id from system_schema.tables where keyspace_name = 'loan_products' and table_name = 'events' ;

现在通过"rm -rf"手动删除其他表目录，用于上述输出中不对应的 UUID。

这也是"nodetool listsnapshots"没有提供任何快照的原因，因为活动表没有任何快照。但是，如果您转到其他 4 个"事件"表目录中的任何一个并执行"ls -ltr"，您应该能够在其中找到快照目录，这些目录是在删除表时创建的。