如何摆脱替换后显示为空的节点？

Question

我有一个3个节点的集群（Cassandra 3.9）；一个节点死了。 我从头开始构建了一个新节点，并使用此页面https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsReplaceNode.html中的信息“替换”了死节点。 看起来替换没问题。

我又添加了两个节点以增强集群。

几天过去了，在nodetool status中的5个节点中的3个上，死节点仍然可见并标记为“ down”：

--  Address       Load       Tokens       Owns (effective)  Host ID                               Rack
UN  192.168.1.9   16 GiB     256          35.0%             76223d4c-9d9f-417f-be27-cebb791cddcc  rack1
UN  192.168.1.12  16.09 GiB  256          34.0%             719601e2-54a6-440e-a379-c9cf2dc20564  rack1
UN  192.168.1.14  14.16 GiB  256          32.6%             d8017a03-7e4e-47b7-89b9-cd9ec472d74f  rack1
UN  192.168.1.17  15.4 GiB   256          34.1%             fa238b21-1db1-47dc-bfb7-beedc6c9967a  rack1
DN  192.168.1.18  24.3 GiB   256          33.7%             null                                  rack1
UN  192.168.1.22  19.06 GiB  256          30.7%             09d24557-4e98-44c3-8c9d-53c4c31066e1  rack1

它的主机ID为空，因此我不能使用nodetool removenode。此外 nodetool assassinate 192.168.1.18失败：

error: null
-- StackTrace --
java.lang.NullPointerException

在system.log中：

INFO  [RMI TCP Connection(16)-127.0.0.1] 2019-03-27 17:39:38,595 Gossiper.java:585 - Sleeping for 30000ms to ensure /192.168.1.18 does not change
INFO  [CompactionExecutor:547] 2019-03-27 17:39:38,669 AutoSavingCache.java:393 - Saved KeyCache (27316 items) in 163 ms
INFO  [IndexSummaryManager:1] 2019-03-27 17:40:03,620 IndexSummaryRedistribution.java:75 - Redistributing index summaries
INFO  [RMI TCP Connection(16)-127.0.0.1] 2019-03-27 17:40:08,597 Gossiper.java:1029 - InetAddress /192.168.1.18 is now DOWN
INFO  [RMI TCP Connection(16)-127.0.0.1] 2019-03-27 17:40:08,599 StorageService.java:2324 - Removing tokens [-1061369577393671924,...]

在system.peers中，死节点显示并具有与替换节点相同的ID：

cqlsh> select peer, host_id from system.peers;

 peer         | host_id
--------------+--------------------------------------
 192.168.1.18 | 09d24557-4e98-44c3-8c9d-53c4c31066e1
 192.168.1.22 | 09d24557-4e98-44c3-8c9d-53c4c31066e1
  192.168.1.9 | 76223d4c-9d9f-417f-be27-cebb791cddcc
 192.168.1.14 | d8017a03-7e4e-47b7-89b9-cd9ec472d74f
 192.168.1.12 | 719601e2-54a6-440e-a379-c9cf2dc20564

死节点和替换节点在system.peers中具有不同的令牌。

所以我的问题是：

• 您能解释出什么问题吗？
• 如何解决此问题并摆脱该死节点？

Answer 1

从system.peers中获得了主机ID，因此可以尝试使用主机ID来进行nodetool removenode / assassinate。

 peer         | host_id
 --------------+--------------------------------------
  192.168.1.18 | 09d24557-4e98-44c3-8c9d-53c4c31066e1