10
  1. 我在 EC2 上有 12 个节点的 cassandra 集群。
  2. 由于某些故障，我们完全丢失了一个节点。我的意思是那台机器不再存在。
  3. 因此，我创建了具有与死节点不同的 ip 和相同令牌的新 EC2 实例，并且我还在该节点上备份了数据，因此它工作正常
  4. 但问题是死节点 ip 在描述集群中仍然显示为无法访问的节点。
  5. 由于该节点（EC2 实例）不再存在，我无法使用nodetool decommission或nodetool disablegossip

我怎样才能摆脱这个无法访问的节点

4

2 回答 2

12

我遇到了同样的问题，我用 解决了它removenode，这不需要您查找和更改节点令牌。

首先，获取节点 UUID：

nodetool status

DN  192.168.56.201  ?          256     13.1%  4fa4d101-d8d2-4de6-9ad7-a487e165c4ac  r1
DN  192.168.56.202  ?          256     12.6%  e11d219a-0b65-461e-babc-6485343568f8  r1
UN  192.168.2.91    156.04 KB  256     12.4%  e1a33ed4-d613-47a6-8b3b-325650a2bbd4  RAC1
UN  192.168.2.92    156.22 KB  256     13.6%  3a4a086c-36a6-4d69-8b61-864ff37d03c9  RAC1
UN  192.168.2.93    149.6 KB   256     11.3%  20decc72-8d0a-4c3b-8804-cc8bc98fa9e8  RAC1

如您所见，.201 和 .202 已失效且位于不同的网络上。这些已更改为 .91 和 .92，但未进行适当的退役和重新调试。我正在安装网络并犯了一些错误......

其次，使用以下命令删除 .201：

nodetool removenode 4fa4d101-d8d2-4de6-9ad7-a487e165c4ac

（在旧版本中是nodetool remove ...）

但就像对于nodetool removetoken ...，它阻塞...（参见 samarth 在 psandord 答案中的评论）但是，它有一个副作用，它将 UUID 放在要删除的节点列表中。所以接下来我们可以强制删除：

nodetool removenode force

（在旧版本中是nodetool remove ...）

现在节点接受它告诉我它正在删除无效条目的命令：

RemovalStatus：删除令牌 (-9136982325337481102)。等待来自 [/192.168.2.91,/192.168.2.92] 的复制确认。

我们还看到它与其他两个启动的节点进行通信，因此需要一点时间，但它仍然非常快。

接下来 anodetool status不显示 .201 节点。我用 .202 重复，现在状态是干净的。

之后，您可能还想运行 psanford 回答中提到的清理：

nodetool cleanup

清理应该在所有节点上一个一个地运行，以确保完全考虑到更改。

于 2014-10-31T22:53:06.677 回答
7

通常在更换节点时，您希望将新节点的令牌设置为(failure node's token) - 1并让它引导。从 1.0 开始，您可以在启动时指定一个标志来替换死节点：“cassandra.replace_token=”。

由于您已经添加了具有相同令牌的新节点，因此还有一个额外的步骤：

  1. 将新节点的令牌移动到(failure node's token) - 1使用nodetool move
  2. nodetool removetoken <failed node's token>从上行节点之一运行
  3. nodetool cleanup在每个节点上运行

这些基本上是1.0 之前的指令，用于用额外的令牌移动替换死节点。

于 2011-12-21T17:12:09.007 回答