微信公众号搜"智元新知"关注
微信扫一扫可直接关注哦!

为什么不应该运行 nodetool removenode?

如何解决为什么不应该运行 nodetool removenode?

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

解决方法

Datastax 文档深入介绍了 nodetool removenode 的用例。

https://docs.datastax.com/en/dse/5.1/dse-admin/datastax_enterprise/tools/nodetool/toolsRemoveNode.html

为什么它会很糟糕的要点是:

警告:此命令会触发集群流。很大 环境,额外的流媒体活动会导致更多未决 nodetool tpstats 输出中的八卦任务。节点可以开始 显示离线,可能需要重新启动以清除积压日志 待处理的八卦任务。

根据文档,这是应该使用它的时候:

当节点宕机无法使用nodetool decommission时,使用nodetool removenode。仅在关闭的节点上运行此命令。

,

默认的偏好顺序是:

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

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

如果被移除的节点是可操作的,那么您通常会运行退役并允许该节点将数据从自身流式传输到其他节点,这些节点现在将保存之前在被移除节点上的副本之一。

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

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

您还可以使用 nodetool [decommission | removenode] force 强制终止退役或移除节点 - 但是,这意味着数据的其中一个副本尚未重新建立到另一个节点,从而使您的弹性降低。

你为什么要这样做?出于同样的流媒体原因,如果您接受一段时间内的弹性损失,您可以以受控方式逐个节点推出修复。此选项不应被视为您的“默认方法”或轻率的选择 - 我无法强调或大胆地强调这一点。

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

在所有这 3 个选项之外 - 最好的选择是如果您打算替换节点,那么执行替换而不是删除/添加是赢家 - 这只会要求新节点将数据流式传输到它来自另一个副本,并且没有进一步的令牌环范围移动。说明here

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

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。