Question

注意：我们在Cassandra 2.1.12.1047（DSE 4.8.4）群集中看到了这个问题，在3个区域中有6个节点（每个区域2个）。

最近尝试在我们的集群上更新模式，我们发现更新失败了。我们怀疑群集中的一个节点没有接受更改。

当检查us-east-1中某个服务器的cassandra@cqlsh> SELECT peer, host_id FROM system.peers WHERE peer IN ('54.158.22.187', '54.196.90.253'); peer | host_id ---------------+-------------------------------------- 54.158.22.187 | 8ebb7f2c-8f81-44af-814b-a537b84834e0表时，它有一个异常，它似乎是一个不存在的主机的完整条目。

nodetool removenode

由于该主机不存在，我尝试使用error: Cannot remove self -- StackTrace -- java.lang.UnsupportedOperationException: Cannot remove self将其删除，但失败.187

我们知道由于EC2问题，几周前.187服务器突然终止。

我们尝试使服务器运行正常，但最终只是终止了在system.peers中报告此nodetool removenode主机的服务器，从.187运行了system.peers其中一台服务器，然后在线提供新服务器。

新服务器上线了，在一个小时左右的时间里似乎赶上了将其与其他服务器联机所需的积压活动（基于CPU监控的假设）。

但是，事情现在非常奇怪，因为当我们从群集中的任何服务器运行nodetool status而不是新的$ nodetool status Datacenter: DC1 =============== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack DN 54.158.22.187 ? 256 ? null r1 Datacenter: cassandra-ap-southeast-1-A ====================================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 54.255.xx.xx 7.9 GB 256 ? a0c45f3f-8479-4046-b3c0-b2dd19f07b87 ap-southeast-1a UN 54.255.xx.xx 8.2 GB 256 ? b91c5863-e1e1-4cb6-b9c1-0f24a33b4baf ap-southeast-1b Datacenter: cassandra-eu-west-1-A ================================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 176.34.xx.xxx 8.51 GB 256 ? 30ff8d00-1ab6-4538-9c67-a49e9ad34672 eu-west-1b UN 54.195.xx.xxx 8.4 GB 256 ? f00dfb85-6099-40fa-9eaa-cf1dce2f0cd7 eu-west-1c Datacenter: cassandra-us-east-1-A ================================= Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns Host ID Rack UN 54.225.xx.xxx 8.17 GB 256 ? 0e0adf3d-4666-4aa4-ada7-4716e7c49ace us-east-1e UN 54.224.xx.xxx 3.66 GB 256 ? 1f9c6bef-e479-49e8-a1ea-b1d0d68257c7 us-east-1d时，$ nodetool describecluster Cluster Information: Name: XXX Snitch: org.apache.cassandra.locator.DynamicEndpointSnitch Partitioner: org.apache.cassandra.dht.Murmur3Partitioner Schema versions: d140bc9b-134c-3dbe-929f-7a84c2cd4532: [54.255.17.28, 176.34.207.151, 54.225.11.249, 54.195.174.72, 54.224.182.94, 54.255.64.1] UNREACHABLE: [54.158.22.187]表中报告的{{1}}出现了我们刚上网。

{{1}}

由于我不知道删除没有主机ID的节点，我感到非常困惑。

我该怎么做才能摆脱这个流氓节点？

注意：以下是describecluster的结果

{{1}}

Answer 1

我自己从来没有这样做，但可能你唯一要做的就是assassinate端点。这在Cassandra 2.2中被制作成nodetool命令（nodetool assassinate）。但在该版本之前，唯一的方法是通过JMX。这是Gist with detailed instructions（Justen Walker的说明和代码）。

先决条件



登录到现有群集活动节点



下载JMX术语


wget的

$ wget -q -O jmxterm.jar
> http://downloads.sourceforge.net/cyclops-group/jmxterm-1.0-alpha-4-uber.jar
> curl

或

 $ curl -s -o jmxterm.jar
 http://downloads.sourceforge.net/cyclops-group/jmxterm-1.0-alpha-4-uber.jar

运行jmxterm

$ java -jar ./jmxterm.jar
Welcome to JMX terminal. Type "help" for available commands.
$>

暗杀节点

错误节点示例：10.0.0.100


连接到本地群集

选择Gossiper MBean运行   带有坏节点ip的unsafeAssassinateEndpoint

$>open
localhost:7199
#Connection to localhost:7199 is opened 

$>bean org.apache.cassandra.net:type=Gossiper
#bean is set to org.apache.cassandra.net:type=Gossiper

$>run unsafeAssassinateEndpoint 10.0.0.100
#calling operation unsafeAssassinateEndpoint of mbean org.apache.cassandra.net:type=Gossiper
#operation returns: null 

$>quit

更新20160308：

我自己从来没有这样做过

我必须自己做。完全抬头并按照我自己的答案中的步骤。

具有空ID的集群中的Cassandra主机

1 个答案: