1

我们正在使用 Cassandra 3.9.0。最近我们在 1 个节点上遇到了一些麻烦。当磁盘使用率达到 100% 时,此节点崩溃。

根据 Datastax 提供的以下说明,我们正在考虑用新节点替换节点的一种方法。 https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsReplaceNode.html

在测试环境中完成替换后,当我们从新节点执行nodetool status时,旧节点不会出现。但是,当从其他节点执行时,会出现旧的死节点。类似地,当nodetool gossipinfo在新传入节点以外的现有节点中执行时,会找到旧节点的引用。

如下图,我们将 a2 替换为 a4

Status=Up/Down
/ State=Normal/Leaving/Joining/Moving
--  Address     Load  Tokens  Owns(effective)  Host ID  Rack
UN  x.x.x.a1  4.52 GiB   256      72.0%       HOSTID1  rack1
DN  x.x.x.a2  4.56 GiB   256      77.5%       null     rack1
UN  x.x.x.a3  4.33 GiB   256      76.9%       HOSTID3  rack1
UN  x.x.x.a4  5.59 GiB   256      73.6%       HOSTID4  rack1

当节点工具状态从作为替换节点的新传入节点运行时,我们得到如下结果。

UN  x.x.x.a1  4.52 GiB   256      100.0%    HOSTID1  rack1
UN  x.x.x.a3  4.33 GiB   256      100.0%    HOSTID3  rack1
UN  x.x.x.a4  5.59 GiB   256      100.0%    HOSTID4  rack1

有什么推荐的方法来解决这种情况吗?

4

2 回答 2

1

如果该节点上一切正常,您应该尝试替换同一节点的另一个选项。在这种情况下,我的意思是自己的节点替换,数据没有范围移动,它将具有相同的范围,并将根据令牌范围从其他节点流式传输数据。

于 2021-05-31T05:26:21.753 回答
1

该文档页面概述了一个与我用来替换节点的过程略有不同的过程,并且似乎没有提到运行nodetool decommissionnodetool removenode. 我不想对您的集群做出任何假设(例如,您可能是多 DC),但我相信您必须运行其中一个命令才能让集群从拓扑中删除死节点。

由于听起来您已经终止了正在运行“死节点”的实例,因此您将无法从中运行nodetool decommission。相反,我建议在另一个节点上运行,该节点仍将其视为集群的一部分,并运行nodetool removenode. 该命令将死节点的 UUID 作为参数,因此您可以找到nodetool status要传入的 via。

该命令是长时间运行的,所以我建议在一个screentmux会话中运行它。您可以通过运行来检查进度nodetool removenode -- status。该命令会将死节点拥有所有权的令牌重新分配给集群中的其他节点。

编辑只是想澄清一下,我在您发布的文档中概述的过程与我自己的不同,我指的是专门指使用该-Dcassandra.replace_address=address_of_dead_node选项运行新节点。在任何情况下,如果节点已经死亡,并且无法重新加入集群,那么nodetool removenode在其 UUID 上运行并没有什么坏处。

于 2018-07-20T19:33:47.407 回答