集羣中具有空ID的Cassandra主機

Question

注意：我們在Cassandra 2.1.12.1047（DSE 4.8.4）羣集中看到此問題，該羣集在3個區域（每個區域中有2個）上有6個節點。

試圖在我們的集羣上最近更新模式，我們發現更新失敗。我們懷疑集羣中的一個節點不接受更改。

當我們檢查us-east-1中的一臺服務器的system.peers表時發現它有一個異常，它似乎是一個不存在的主機的完整條目。

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問題。

我們不得不多次試圖在試圖使服務器健康的，但後來最終直接結束這是報告在system.peers這.187主機的服務器，從其他服務器中的一個跑了nodetool removenode，然後帶來了新的服務器在線。

新的服務器上線了，並且在一個小時左右似乎已經趕上了將其與其他服務器內聯（需要純粹基於CPU監控）的積壓活動。

然而，事情現在很奇怪，因爲這是報道system.peers表的.187當我們比我們剛剛上線帶來了新的另外一個集羣中的任何服務器上運行一個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 

由於我不知道要刪除沒有Host 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] 

Answer 1

我從來沒有這樣做我自己，但可能留給你唯一要做的結果是assassinate端點。這是Cassandra 2.2中的一個nodetool命令（nodetool assassinate）。但在該版本之前，唯一的方法就是通過JMX。這裏有一個Gist with detailed instructions（說明和代碼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 

運行jmxterm

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

刺殺節點

例不良節點：10.0.0.100

• 連接到本地集羣
• 選擇Gossiper的MBean運行 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 

的IP 更新20160308：

我從來沒有過這種自己做的

剛把這個做我自己。完全查找，並按照我自己的答案中的步驟。