Nodetool 修复 -pr -full 与 Nodetool 修复 -pr答案

【问题标题】：Nodetool repair -pr -full vs Nodetool repair -prNodetool 修复 -pr -full 与 Nodetool 修复 -pr
【发布时间】：2021-06-18 17:17:18
【问题描述】：

我正在运行一个包含 1 个数据中心（6 个节点）的集群，每个节点上都安装了 Cassandra 3.11.0，复制因子为 2。我知道 nodetool repair -pr 将对该节点上的主要范围进行修复。我的问题是，nodetool repair -pr -full 与 nodetool repair -pr 有何不同？

我应该在高负载生产系统上使用哪种修复选项？

【问题讨论】：

标签： cassandra cassandra-3.0

【解决方案1】：

我的问题是nodetool repair -pr -full 与nodetool repair -pr 有何不同？

所以“完全”修复意味着源节点和目标节点之间的所有数据都将得到验证和修复。从本质上讲，它与“incremental”修复相反，后者只修复了一部分数据。这两个选项控制有多少数据被修复。

一旦确定（增量与完整），-pr 将在该子集上运行，然后才修复主副本。

此外，-full 是 Cassandra 3 的默认值；这将使-pr 和-pr -full 基本相同。

我应该在高负载生产系统上使用哪种修复选项？

我会支持亚历克斯所说的，并为此推荐Cassandra Reaper。它能够安排较慢时间的维修，并允许您暂停未及时完成的维修。

【讨论】：

我在 system.log 中看到相同的日志信息，方法是使用 -pr 或 -pr -full 运行修复，使用修复选项修复 keyspace main（并行：并行，主要范围：true，增量：false , 工作线程: 2, ColumnFamilies: [], dataCenters: [], hosts: [], # of range: 6, pull repair: false)，我怎样才能确保“repair -pr”正在进行全面修复？

【解决方案2】：

对于生产系统，最好使用令牌范围修复（使用-st/-et 选项）来限制节点上的负载。手动操作可能很乏味，但可以使用 Reaper 之类的工具自动完成，跟踪哪些令牌范围已修复，哪些未修复。

【讨论】：

【解决方案3】：

建议不要使用 -PR 选项执行增量修复。它会跳过未修复的非主副本，从长远来看不是一个好习惯！

【讨论】：

看起来像评论