时间戳

首页 > 解决方案 > Cassandra nodetool rebuild_index在nodetool compactionstats中卡在100％，如何刷新它并强制完成？

cassandra - Cassandra nodetool rebuild_index在nodetool compactionstats中卡在100％，如何刷新它并强制完成？

问题描述

我有一个运行 Cassandra 框架的 DC/OS 集群，三个 master 和六个 worker，在由于注册表问题导致框架崩溃后，Cassandra 节点未与数据同步，为了同步它我尝试一一修复 Keyspace并检查“./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”的状态？

我签入了节点，并且没有这样的进程在任何节点的内存中运行。我需要继续修复键空间，但这个任务就在它前面，因为直到这个任务结束，修复才会等待。

标签： cassandramesospheredcosnodetool

解决方案

当您在表上有二级索引时，二级索引构建是 Cassandra 正常操作的一部分。节点接收到的任何新突变都将被索引。

它在与 Cassandra 进程相同的 JVM 中作为压缩线程运行，因此您不会看到在机器的进程表上运行单独的进程。

没有“强制”他们完成的操作。当所需的数据索引完成时，它们将完成。

维修也是 Cassandra 正常运营的一部分。在修复期间将新数据流式传输到节点时，接收节点也将索引该数据。我的意思是，这些操作是齐头并进的，一个不会阻止另一个工作。干杯!

推荐阅读