jna.jar が利用可能な 6 つの m1.large インスタンスで実行されている AWS EC2 Cassandra 1.2.8 クラスターがあります。s3 からデータのスナップショットをダウンロードし、それを新しいクラスターにインストールする災害復旧のテストを行っています。次に、ノードで nodetool repair を実行しようとしました。しばらくすると (1 時間ほどかかる場合があります)、定期的にメッセージが表示されます。
failed with error java.io.IOException: Cannot proceed on repair because a neighbor (/10.0.22.162) is dead: session failed
10.0.22.162 にログインすると、CassandraDaemon Java プロセスがまだ実行されていることがわかりnetstat -antますが、インスタンスがポート 9160 をリッスンしていないことが示されます。
カサンドラのログを見ると、最後に次のように表示されます。
INFO [AntiEntropyStage:1] 2013-08-20 16:08:53,340 AntiEntropyService.java (line 245) [repair #cdb7f2a0-09b2-11e3-bc42-4bd65b6bc771] Sending completed merkle tree to /10.0.32.59 for (dummy,foo)
ERROR [Thread-1657] 2013-08-20 16:08:53,828 FileUtils.java (line 381) Stopping RPC server
INFO [Thread-1657] 2013-08-20 16:08:53,828 ThriftServer.java (line 116) Stop listening to thrift clients
ERROR [Thread-1657] 2013-08-20 16:08:53,830 FileUtils.java (line 387) Stopping native transport
INFO [Thread-1657] 2013-08-20 16:08:53,838 Server.java (line 151) Stop listening for CQL clients
どこで/どのようにこれを追跡し、リサイクルサーバーが長期休暇をとる理由を理解できる人はいますか?
ノードツールの修復はプロセスの豚であることを知っているので、誰かがそれがリソースに縛られていると私に言った場合、それを追跡する方法についてもう少し情報が必要になるかもしれません.