Cassandra tablestats 显示完全修复后修复率为 0.0%答案

【问题标题】：Cassandra tablestats showing 0.0 percent repaired after full repairCassandra tablestats 显示完全修复后修复率为 0.0%
【发布时间】：2018-09-10 21:50:27
【问题描述】：

我有一个由 4 个节点组成的 C* 3.11 集群，RF 为 3。在我运行 nodetool repair -full ks1 tb1 后，命令窗口显示

Starting repair command #18 (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx), repairing ks1 with repair options (parallelism: parallel, primary range: false, incremental: false, job threads: 1, ColumnFami lies: [device], dataCenters: [], hosts: [], # of ranges: 404, pull repair: false)

和

[2018-01-01 01:25:57,730] Repair completed successfully [2018-01-01 01:25:57,734] Repair command #18 finished in 29 seconds

所以我认为修复运行成功。尽管如此，当我检查nodetool tablestats ks1.tb1 时，命令窗口会显示

Percent repaired: 0.0

根据表的不同，结果可能是Percent repaired: 100.0 或Percent repaired: 70.0，许多仍然显示Percent repaired: 0.0，即使修复命令显示已成功修复。

我错过了什么？

【问题讨论】：

标签： cassandra

【解决方案1】：

已修复百分比指标用于增量修复。通过增量修复，有 2 套 sstables。修复和未修复。一旦马厩被修复，它将被移动到修复后的集合中，不再参与未来的修复。当您放置 --full 时，您指定不使用增量修复，而是使用子范围修复，在某些情况下仍然需要修复某个范围内的整个数据集，无论它之前是否已修复。示例场景是非本地 DC 中的 1 台主机上的磁盘故障，因此修复以从备份中更新替换，或单个节点超过提示的切换窗口等。

拥有 2 组 sstable 会产生很多开销（在从压缩修复期间锁定 sstable，以及在范围拆分 sstable 时锁定反压缩）。因此，当非增量修复运行时，sstables 不会被标记，因为它们避免了这些步骤。

【讨论】：