5

我正在开发一个用于 nodetool 修复的自动化脚本，该脚本将在所有 6 个 Cassandra 节点上每个周末执行。我们在 DC1 中有 3 个，在 DC2 中有 3 个。只是想了解最坏的情况。如果 DC1 和 DC2 之间的连接丢失或几个副本在节点工具修复之前或期间发生故障，会发生什么情况。这可能是网络问题、网络升级（通常发生在周末）或其他原因。我知道 nodetool repair 为该节点上的每个数据范围计算 Merkle 树，并将其与其他副本上的版本进行比较。因此，如果它们在副本之间没有连接性，节点工具修复将如何表现？它真的会修复节点吗？在所有节点都启动并恢复连接后，我是否必须重新运行节点工具修复。他们会不会是这个事件的任何副作用？我盯着它看，但找不到太多细节。任何见解都会有所帮助。

谢谢。

4

2 回答 2

1

假设您正在使用 vnodes，默认情况下，这意味着每个节点有 256 个范围，但想法是相同的。

如果在 nodetool 修复已经开始之后发生网络问题，您将在日志中看到某些范围已成功修复而其他范围没有。该错误会说范围修复失败，因为节点“192.168.1.1 已死”之类的。

如果在 nodetool repair 开始之前发生网络错误，则所有范围都将失败并出现相同的错误。

在这两种情况下，您都需要在网络问题解决后运行另一个 nodetool repair。

我不知道您在这 6 个节点中拥有的数据量，但根据我的经验，如果集群可以处理它，最好在一周的不同日子每周运行一次 nodetool repair。例如，您可以在周日修复节点 1，在周一修复节点 2，依此类推。如果您有少量数据或一天中的添加/更新不是太多，您甚至可以每天运行一次修复。当您有一个已经修复的集群并且您更频繁地运行 nodetool repair 时，它将花费更少的时间来完成，但是如果您的数据太多，它可能是不可能的。

关于副作用，如果您使用一致性级别 1，您只能注意到数据的差异，如果您对“未修复”节点运行查询，则数据将与“修复”节点上的数据不同。例如，您可以通过将一致性级别提高到 2 来解决此问题，然后再次如果 2 个节点“未修复”并且您运行的查询使用这 2 个节点解决，您将再次看到差异。您需要在此处进行权衡，因为避免查询中这种“差异”的最佳选择是让一致性级别 = 复制因子，当其中 1 个节点关闭时，这会带来另一个问题，整个集群都关闭了，您将开始接收查询超时。

希望能帮助到你！

于 2013-11-22T18:34:42.960 回答
1

有多种修复选项可用，您可以根据您的应用程序使用情况选择一种。如果您使用的是 DSE Cassandra，那么我建议您安排 OpsCenter 修复，它通过提供小于 gc_grace_seconds 的持续时间来进行增量修复。

以下是进行维修的不同选择：

  1. 默认（无）：将修复所有 3 个分区范围：运行它的节点拥有的 1 个主副本和 2 个副本。总共将涉及 5 个节点 2 个节点将固定 1 个分区范围，2 个节点将固定 2 个分区范围，1 个节点将固定 3 个分区范围。
  2. -par：将并行执行上述操作。
  3. -pr ：将仅修复运行它的节点的主分区范围。如果您使用 EACH_QUORUM 的写入一致性，那么也使用 -local 选项来减少跨 DC 流量。

如果您已经投入生产，我建议您使用选项 3，以避免因维修而对性能产生任何影响。

如果您想更详细地了解维修，请在此处查看

于 2016-05-26T19:59:56.243 回答