我们正在使用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
是否有解决此问题的建议方法？
答案 0 :(得分：0)
该文档页面列出的过程与我用来替换节点的过程略有不同，并且似乎没有提到运行nodetool decommission或nodetool removenode。我不想对集群做任何假设（例如，您可能是多DC），但是我相信您必须运行这些命令之一才能使集群从拓扑中删除死节点。
由于听起来您已经终止了正在运行“死节点”的实例，所以您将无法从中运行nodetool decommission。相反，我建议转到另一个节点，该节点仍然将其视为群集的一部分，并运行nodetool removenode。该命令将死节点的UUID作为参数，因此您可以通过nodetool status来找到它。
该命令正在长时间运行，因此我建议在screen或tmux会话中运行该命令。您可以通过运行nodetool removenode -- status来检查进度。该命令会将死节点拥有所有权的令牌重新分配给群集中的其他节点。
编辑只是想澄清一下，您发布的文档中概述的过程与我自己的描述不同，我指的是使用-Dcassandra.replace_address=address_of_dead_node运行新节点选项。无论如何，如果节点已死，并且无法重新加入群集，那么在其UUID上运行nodetool removenode不会有任何危害。
答案 1 :(得分：0)
如果在该节点上一切正常，您应该尝试替换同一节点的另一个选项。在这种情况下，我的意思是自己的节点替换没有数据范围移动，它将具有相同的范围，并将根据令牌范围从其他节点流式传输数据。