2

注: この問題は、3 つのリージョン (各リージョンに 2 つ) にわたって 6 つのノードを持つ Cassandra 2.1.12.1047 (DSE 4.8.4) クラスターで見られます。

最近、クラスターのスキーマを更新しようとしたところ、更新が失敗していることがわかりました。クラスター内の 1 つのノードが変更を受け入れていない可能性があります。

us-east-1 のサーバーの 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

.187EC2 の問題により、数週間前にサーバーが突然終了したことがわかっています。

サーバーを正常な状態にするために何度も試みましたが、最終的には、 でこの.187ホストを報告していたサーバーを終了し、他のサーバーの 1 つからsystem.peersを実行しnodetool removenode、新しいサーバーをオンラインにしました。

新しいサーバーがオンラインになり、1 時間ほどで、他のサーバーとインライン化するために必要なアクティビティのバックログに追いついたようです (純粋に CPU 監視に基づく仮定)。

ただし、オンラインにしたばかりの新しいサーバー以外のクラスター内のサーバーからを実行すると、テーブルで.187報告された が表示されるため、状況は非常に奇妙です。system.peersnodetool 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 を使用するしか方法がありませんでした。詳細な手順を含むGist を次に示します ( 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 を使用して 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:

私はこれを自分で行う必要はありませんでした

自分でこれをしなければなりませんでした。完全に調べて、私自身の回答の手順も実行しました。

于 2016-03-02T19:29:40.760 に答える