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

Question

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

3

为什么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' 的键空间，其中只有一个列族 'events':

[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天），因此垃圾回收程序需要删除墓碑等内容，但它们仍然存在于文件系统中。 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日。

- Konstantin Vustin

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- dilsingi · Accepted Answer

默认情况下，当删除列族时，Cassandra会拍摄快照。这是出于设计考虑，以防止意外截断（删除表中的所有记录）或意外删除该表。控制此行为的Cassandra.yaml参数是auto_snapshot。

引用块：无论在截断键空间还是删除列族之前是否对数据进行快照。强烈建议使用默认值true来提供数据安全性。如果将此标志设置为false，则在截断或删除时将丢失数据。 auto_snapshot: true 因此，根据您展示的屏幕截图，看起来“events”表已被删除至少4次并重新创建。因此，正确的清理方法是首先确定Cassandra针对键空间中给定表使用的正确UUID。在您的情况下，查询将是：

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

现在，手动使用“rm -rf”删除上述输出中不对应UUID的其他表目录。另外，“nodetool listsnapshots”没有给出任何快照的原因是活动表没有任何快照。但如果您进入其他4个“events”表目录之一并执行“ls -ltr”，则应该能够在其中找到快照目录，这些快照目录是在删除表时创建的。