web-dev-qa-db-ja.com

nodetoolの修復が完了したかどうかを知る方法

私は2ノードのApache cassandra（2.0.3）rep factorが1です。クラスターを持っています。cqlshで次のコマンドを使用してrep factorを2に変更します。

ALTER KEYSPACE "mykeyspace" WITH REPLICATION =   { 'class' : 'SimpleStrategy', 'replication_factor' : 2 };

次に、このタイプの変更を行った後、推奨される「nodetool repair」を実行しようとしました。

問題は、このコマンドが時々非常に早く終了することです。そのように終了すると、通常は「Lost notification ...」と表示され、終了コードはゼロではありません。

したがって、エラーなしで終了するまでこの「nodetool repair」を繰り返します。また、「nodetool status」が各ノードの予想ディスク容量を報告することを確認します。 （担当者係数1の場合、各ノードはそれぞれ約7GBであり、nodetoolの修復後は、平均でクラスターの使用がないと仮定して、それぞれ14GBになると予想しています）

この場合、「nodetool repair」が終了したことを判断するより正確な方法はありますか？

cassandracassandra-2.0nodetool
18
user3865568

一般的に、nodetool repair 2つのnodetoolコマンドを使用した操作：

  • 圧縮統計
  • netstats

修復操作には2つの異なるフェーズがあります。最初にノード間の差異を計算し（実行する修復作業）、次に適切なノードにデータをストリーミングすることでそれらの差異に作用します。

これにより、アクティブなマークルツリー計算がチェックされます。

$ nodetool compactionstats
pending tasks: 0
Active compaction remaining time :        n/a

修復ストリームは次の方法で監視できます。

$ nodetool netstats

実際、 TheLastPickle のAaron Mortonは、次のBashスクリプト/コマンドを使用して、アクティブな修復ストリームを監視することを提案しています。

while true; do date; diff <(nodetool -h localhost netstats) <(sleep 5 && nodetool -h localhost netstats); done

DataStaxのサポートフォーラムには、 ハンギング修理のトラブルシューティング に関する投稿があります。ハングした修復ストリームがある場合、netstatsでそれらを見ることができるはずです。これは、修復プロセス中にノードの1つが使用できなくなった場合に発生する可能性があります。特定の修復操作を監視するには、ログファイルで次のようなエントリを確認できます。

デバッグ[WRITE-/172.30.77.197] 2013-05-03 12：43：09,107 /172.30.77.197 Java.net.SocketExceptionへの書き込み中のOutboundTcpConnection.Java（行165）エラー：接続のリセット

System.logで修復セッションも示されることに注意してください。

[repair #02fc68f0-210c-11e7-aa88-c35a9a02c19a] Starting...

[repair #02fc68f0-210c-11e7-aa88-c35a9a02c19a] Completed...
49
Aaron

Repairコマンドを開始するときに、オプション--traceを使用して修復ストリームを監視できます。

nodetool repair --trace <key_space> <table>

3
tjeubaoit

Opscenterコンソールの[アクティビティ]で修復の進行状況を監視することもできます。

0
Selvaraj Subramanian