我正在为nodetool修复开发一个自动脚本，它将在所有6个Cassandra节点上执行。我们在DC1中有3个，在DC2中有3个。只是想了解最坏的情况。如果在节点工具修复之前或期间DC1和DC2之间的连接丢失或者几个副本发生故障，会发生什么。它可能是网络问题，网络升级（通常在周末发生），或其他。我了解nodetool repair为该节点上的每个数据范围计算Merkle树，并将其与其他副本上的版本进行比较。因此，如果它们在副本之间没有连接，那么nodetool修复会如何表现？它真的会修复节点吗？所有节点启动并恢复连接后，是否必须重新运行节点工具修复。他们会有这个事件的副作用吗？我瞪着它但却找不到太多细节。任何见解都会有所帮助。
感谢。
答案 0 :(得分：1)
假设您正在使用vnodes，默认情况下这意味着每个节点都有256个范围，但这个想法是相同的。
如果在nodetool修复已经开始之后发生网络问题，您将在日志中看到一些成功修复的范围和其他范围。该错误将表示范围修复失败，因为节点＆＃34; 192.168.1.1已经死亡＆＃34;类似的东西。
如果在nodetool修复开始之前发生网络错误，则所有范围都将失败并出现相同的错误。
在这两种情况下，您都需要在解决网络问题后运行另一个nodetool修复。
我不知道您在这6个节点中拥有的数据量，但根据我的经验，如果群集可以处理它，最好每周在一周的另一天运行nodetool修复。例如，您可以在星期日修复节点1，在星期一修复节点2，依此类推。如果您有少量数据或一天中的添加/更新不是太多，您甚至可以每天进行一次维修。当你有一个已经修复的集群并且你经常运行nodetool修复时，它将花费更少的时间来完成，但是如果你有太多的数据，那么它可能是不可能的。
关于副作用，如果您使用一致性级别1，则只能注意数据的差异，如果您发生了针对＆＃34;未修复的＆＃34;节点数据将不同于＆＃34;修复的数据＆＃34;节点。例如，你可以通过将一致性级别提高到2来解决这个问题，如果2个节点未经修复，则可以再次解决这个问题。并且使用这两个节点解析您运行的查询，您将再次看到差异。你有一个权衡，因为最好的选择，以避免这种差异＆＃34;在查询中，一致性级别=复制因子，当其中一个节点关闭时整个群集关闭并且您将开始接收查询超时时会带来另一个问题。
希望它有所帮助！
答案 1 :(得分：1)
有多种可用的修复选项，您可以根据应用程序的使用情况选择一种。如果您正在使用DSE Cassandra，那么我建议安排OpsCenter修复，它通过提供小于gc_grace_seconds的持续时间来执行增量修复。
以下是修复的不同选项：
如果您已经投入生产，我建议您使用选项3，以避免因维修而对性能造成影响。
如果您想更详细地了解维修，请查看此here