我们使用的是Cassandra 3.9.0。最近我们在1个节点上遇到了一些问题。当达到100%的磁盘使用率时，此节点崩溃。
根据Datastax提供的以下说明，我们正在考虑用新节点替换节点的一种方法。https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsReplaceNode.html
在测试环境中完成替换后，当我们从新节点执行nodetool status时，旧节点不会显示。但是，当从其他节点执行时，旧的死节点会出现。类似地，当在新传入节点以外的现有节点中执行nodetool trozzinfo时，会找到旧节点的引用。
如下所示，我们将用a4 替换a2
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
有什么建议的方法来解决这种情况吗？
该文档页面概述了一个与我用来替换节点的流程略有不同的流程，并且似乎没有提到运行nodetool decommission或nodetool removenode。我不想对您的集群做出任何假设(例如，您可能是多DC(，但我相信您必须运行其中一个命令，才能让集群从拓扑中删除死节点。
因为听起来你已经终止了"死节点"运行的实例，所以你将无法从中运行nodetool decommission。相反，我建议转到另一个节点，一个仍然将其视为集群一部分的节点，并运行nodetool removenode。该命令将死节点的UUID作为参数，因此您可以通过nodetool status找到它来传递。
该命令是长时间运行的，因此我建议在screen或tmux会话中运行它。您可以通过运行nodetool removenode -- status来检查进度。该命令将把死节点拥有所有权的令牌重新分配给集群中的其他节点。
EDIT我只是想澄清一下，我所说的您发布的文档中概述的流程与我自己的流程不同，我特别指的是使用-Dcassandra.replace_address=address_of_dead_node选项运行新节点。在任何情况下，如果节点已死亡，并且无法重新加入集群，则在其UUID上运行nodetool removenode不会有任何危害。
您应该尝试的另一个选项是，如果在同一节点上一切正常，则替换该节点。我的意思是，在这种情况下，自己的节点替换没有数据的范围移动，它将具有相同的范围，并将根据令牌范围从其他节点流式传输数据。