cassandra - 为什么不应该运行 nodetool removenode？

Question

我想知道为什么不运行nodetool removenode是最佳实践。它是干什么用的？是否有要运行的命令层次结构？运行上述命令时会出现什么样的问题？任何使用 removenode 的第一手经验/噩梦故事？总体为什么不呢？

标签： cassandraoperation

Answer 1

默认的偏好顺序是：

1. 更换节点选项（如果计划更换）
2. 退役
3. 移除节点
4. 暗杀

但是 - 在某些情况下，您仍然会选择较低的条目而不是较早的条目。

如果要删除的节点是可操作的，那么您通常会运行停用并允许节点将数据从自身流式传输到其他节点，这些节点现在将持有之前在要删除的节点上的副本之一。

删除节点将导致令牌范围重新计算并移动，可能需要所有节点开始将数据流式传输到现在拥有该范围的其他节点。

如果节点无法运行，您可以执行 nodetool removenode - 这将触发相同的范围移动并导致大量流式传输。默认情况下存在流式吞吐量限制，可以进行调整以限制这种影响。

您也可以通过使用强制终止停用或删除节点nodetool [decommission | removenode] force- 但是，这意味着数据的一个副本尚未重新建立到另一个节点，从而使您的弹性降低。

为什么要这么做？出于同样的流式传输原因，如果您接受一段时间内的弹性损失，您可以以受控方式逐个节点推出修复。不应将此选项视为您的“默认方法”或轻率的选择-我不能强调或足够大胆。

最后一个选项，当 decommission / removenode 不可用时，是暗杀节点 - 这与执行 removenode 几乎相同，然后立即强制执行。然后，您必须设法以相同的方式进行维修和清理。

在所有这 3 个选项之外 - 最好的选择是如果您打算替换节点，那么执行替换而不是删除/添加是赢家 - 这只需要新节点有数据从其他复制品的，并没有进一步的令牌环范围移动。这里的说明

如果数据磁盘可用，也可以在不流式传输数据的情况下进行替换，此处的说明