Cassandra 顺序修复不会在一次运行中修复所有节点？

Question

前天，我使用以下命令在 5 节点 Cassandra 集群中的一个节点上对单个表执行了完整的顺序修复。

nodetool repair -full -seq -tr <keyspace> <table> > <logfile>

现在可以从下面的命令推断出发出命令的节点已正确修复

nodetool cfstats -H <keyspace.columnFamily>

但是，对于其他节点不能说相同，因为对于它们我得到修复百分比的随机值，明显更小。

我不确定这里发生了什么，看起来唯一为键空间和列族修复的节点是发出修复命令的节点。关于这里可能发生的事情或如何正确调查问题的任何猜测

谢谢!

Answer 1

您说您的集群有 5 个节点，但没有说明您为表使用的是哪个复制因子 (RF) - 我假设您使用的是常见的 RF=3。当RF=3时，每条数据在5个节点上复制3次。

您错过的关键点是，在这样的设置中，每个特定节点不包含所有数据。它包含多少总数据？我们做个简单的数学运算:如果实际插入表的数据量为X，那么集群存储的数据总量为3*X(因为RF=3，每条数据三份)。这个总数分布在 5 个节点上，因此每个节点将持有 (3*X)/5，即 3/5*X。

当您在一个特定节点上开始修复时，它只会修复该节点拥有的数据，即我们刚刚计算的总数据的 3/5。此修复所做的是针对该节点持有的每条数据，它将此数据与其他副本持有的副本进行比较，修复不一致并修复所有这些副本。这意味着当修复结束时，在我们修复的节点中，它的所有数据都被修复了。但是对于其他节点，并不是所有的数据都被修复了——只是与发起此修复的节点相交的部分。这个交集应该大约是数据的 3/5*3/5 或 36%(当然，所有内容都是随机分布的，因此您可能会得到接近 36% 但不完全是 36% 的数字)。

所以您现在可能已经意识到，这意味着“nodetool repair”不是集群范围的操作。如果在一个节点上启动，则只能保证修复一个节点上的所有数据，而在其他节点上可能修复较少。因此，您必须分别在每个节点上运行修复。

现在您可能会问:既然修复节点 1 也修复了节点 2 的 36%，那么如果我们已经完成了 36% 的工作，还修复节点 2 不是很浪费吗？确实，这是一种浪费。所以 Cassandra 有一个修复选项“-pr”(“主要范围”)，它确保每个数据的 3 个副本中只有一个会修复它。使用 RF=3，“nodetool repair -pr”将比没有“-pr”快三倍；您仍然需要在每个节点上单独运行它，当所有节点完成时，您的数据将在所有节点上 100% 修复。

所有这些都相当不方便，而且在长时间的维修过程中也很难从 transient 故障中恢复过来。这就是为什么 Datastax 和 ScyllaDB 的两种商业 Cassandra 产品都提供了一个单独的修复工具，它比“nodetool repair”更方便，确保以最有效的方式修复整个集群，并从 transient 问题中恢复而无需从头开始重新进行冗长的修复过程。