我有一个运行cassandra framework的dc/os集群,三个主节点和六个工作节点,在由于注册表问题导致框架崩溃之后,cassandra节点没有与数据同步,为了同步它,我尝试逐个修复密钥空间并检查“/nodetool compactionstats”状态。
维修后,我进入“/nodetool compactionstats”一个卡住的任务:
[root@server-worker1 bin]# ./nodetool compactionstats
pending tasks: 2
- system.IndexInfo: 1
- my_app_prod.profile_activation_history: 1
id compaction type keyspace table completed total unit progress
0d49d3d0-19d6-11eb-a65c-f71e0bcef8b1 Secondary index build my_app_prod profile_activation_history 3010912 3010912 bytes 100.00%
Active compaction remaining time : 0h00m00s
[root@server-worker1 bin]#
任务卡在100%以内,我怎么能强迫它完成?或者刷新“/nodetool compactionstats”的状态?
我签入了节点,但没有这样的进程在任何节点的内存中运行。我需要继续修复密钥空间,但是这个任务就在前面,因为在这个任务结束之前,修复将等待。
1条答案
按热度按时间m1m5dgzv1#
当表上有二级索引时,二级索引构建是cassandra正常操作的一部分。节点接收到的任何新变异都将被编入索引。
它作为压缩线程在与cassandra进程相同的jvm中运行,因此您不会看到单独的进程在机器的进程表上运行。
没有“强迫”他们完成的行动。当所需的数据索引完成时,它们将完成。
维修也是Cassandra正常运作的一部分。当新数据在修复期间流式传输到节点时,接收节点也将索引该数据。我想说的是,这些操作是并行的,一个操作并不妨碍另一个操作。干杯!