我们正在使用Apache-Cassandra v3.0.9并拥有3个DC。我们在运行nodetool修复时遇到了持续的麻烦，并且大多数情况下修复过程会导致大量中断。我们有3个不同的数据中心，包括4,4和4。 15个节点。 RF = 3时，总数据约为200 GB，我们正在使用LCS。 RAM为16 GB，其中6 GB专用于堆。大多数时候，我们尝试运行完全修复修复过程失败，GC暂停时间长，节点无响应。除了在修复时，我们的节点在堆上是好的，GC暂停几乎不是300毫秒。我有疑虑。
是否仍需要在gc_grace_seconds之前运行完全修复，或者只需在apache cassandra v3.0.9中进行增量修复
我是否需要在群集的每个节点，每个数据中心的任何一个节点或整个群集的任何节点上运行增量顺序修复？一个接一个或同时发生？
修复失败的缺点是什么，因为某些节点在修复过程中没有响应/死亡，在开始另一个修复会话之前需要注意的任何步骤。
根本不安排维修的缺点是什么？
我们在版本3.0.9上立即开始我们的cassandra部署。是否仍需要Apache Cassandra documentation中提到的迁移？
答案 0 :(得分：0)
仍需要完全修复。增量修复将SSTables拆分为“已修复”和“未修复”部件，“修复”部件将不会在以后修复，这就是为什么增量修复更有效。但是，如果“已修复”的sstables中存在数据损坏，则只有完全修复才能解决问题;我们的经验是每天进行增量修复，每个宽限期只进行一次全面修复。此外，当您进行增量修复时，可以延长宽限期。
更好地逐个对每个节点进行增量修复;你可以有一个cron作业或编写一个简单的调度程序来做到这一点;
修复失败，再次运行;没有我知道的副作用。
如果不进行修复，随着时间的推移，您的数据一致性就会受到威胁; Cassandra采用最终的一致性概念，这意味着除非您明确指定，否则在向其写入数据时它不能保证强一致性。修复非常重要，以保证后台数据都保持最新和一致;
如果您已在群集中运行完全修复，则不需要显式迁移。