2

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

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

当检查system.peers我们在 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运行 a nodetool removenode，然后使新服务器联机。

新服务器上线，大约一个小时后，它似乎赶上了将其与其他服务器内联所需的积压活动（纯粹基于 CPU 监控的假设）。

但是，现在事情变得非常奇怪，因为当我们从集群中的任何服务器运行 a 时，表.187中报告的system.peers内容就会出现，而不是我们刚刚上线的新服务器。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

由于我不知道如何删除没有主机 ID 的节点，所以我很困惑。

我能做些什么来摆脱这个流氓节点？

注意：这是 describecluster 的结果

$ 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]
4

1 回答 1

3

我自己从来没有这样做过，但可能你唯一要做的就是到达assassinate终点。nodetool assassinate这在 Cassandra 2.2 中被做成了 nodetool 命令 ( )。但在该版本之前，唯一的方法是通过 JMX。这是一个带有详细说明的要点（Justen Walker的说明和代码）。

先决条件

  1. 登录到现有集群活动节点

  2. 下载 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
  1. 运行 jmxterm
$ java -jar ./jmxterm.jar
Welcome to JMX terminal. Type "help" for available commands.
$>

暗杀节点

坏节点示例：10.0.0.100

  • 连接到本地集群
  • 选择 Gossiper MBean 使用坏节点的 ip 运行 unsafeAssassnateEndpoint
$>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：

我自己从来没有这样做过

只好自己做这件事。完全抬头并按照我自己的答案中的步骤进行操作。

于 2016-03-02T19:29:40.760 回答