0
votes

I have a DC/OS cluster running Cassandra framework, three masters and six workers, after a framework crash due to registry issues, the Cassandra nodes are not synced with the data, in order to sync it i tried to repair the Keyspaces one by one and check the "./nodetool compactionstats" status.

after the repair i got in the "./nodetool compactionstats" a stuck task:

[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]#

the task is stuck in 100%, how can i force it to finish ? or refresh the status of the "./nodetool compactionstats" ?

I checked in the nodes and no such process is running in memory in any node. I need to continue repairing the keyspaces but this task is standing in front of it because until this task is over the repair will wait.

1

1 Answers

0
votes

Secondary index builds are part of the normal operation of Cassandra when you have secondary indexes on tables. Any new mutation that a node receives will get indexed.

It runs as a compaction thread within the same JVM as the Cassandra process so you won't see a separate process running on a machine's process table.

There's no operation to "force" them to finish. They will finish when the required indexing of data has completed.

Repairs are also part of the normal operation of Cassandra. When new data is streamed to a node during a repair, that data will also be indexed by the receiving node. What I'm getting at is that those operations go hand-in-hand and one does not prevent the other from working. Cheers!