問題タブ [nodetool]

ここ数日、gcstats を監視してきましたが、返される値が正しいとは信じられません。

nodetool gcstats [GC Reclaimed (MB)] は、データベースに対して何も実行されていない場合、最後の 5 回の実行で以下の値を示します

30356680056

663531768

4222674760

567091224

2147418944

キースペースの合計サイズは 1 GB 未満です。

管理者の間で、約 8 か月間 repair() が表示されなかった 4 ノードの Cassandra クラスターがあります。削除の方法はあまり見られません。nodetool repair を実行すると、システムが新しいデータを受け入れなくなり、修復が完了するまで誰も cqlsh に接続できないことに気付きました。修理によってダウンタイムが発生するのは正常ですか?

私はcassandraを使用していますが、 commitlog2.2.1ファイルが削除されていないことに気付きました（実際にはいくつかあるかもしれませんが、私は見ていませんが、commitlogディレクトリは空ではありません）。nodetool flush

1. 通常のフラッシュnodetool flush中または単にフラッシュ中に何が起こっていますか? このプロセス中にすべてのcommitlogファイルが削除されることになっていますか?

2. commitlogからのデータは、ノードの修復時またはフラッシュ時にのみ使用されますか?

Mac ProでEclipseを使用してdatastax Javaドライバーのテストを行っていました。基本的に、Eclipseでは、準備されたバッチステートメントを使用して（id、name）を記述していました.idの範囲は10000から1000000で、名前はstudent1-student10000（idの範囲による）です。Eclipse でコードを実行するたびに、すべてがうまくいき、nodetool cfhistograms と proxyhistograms、および cfstats を使用して結果を確認します。しかし、それは奇妙に思えます。読み取りレイテンシーと書き込みレイテンシーが増加するのを楽しみにしていたので、10000、100000、1000000、10000000 の範囲を追加すると、最終結果はレイテンシーが減少することがわかりました。

たとえば、10,000 の最初のテーブルと 100,000 の 2 番目のテーブルの cfhistograms の場合: パーセンタイル SSTables Write Latency 50% 0 14 75% 0 20 95% 0 42 98% 0 60 99% 0 60 Min 0 5 Max 0 179

パーセンタイル以下の 100,000 SSTables 書き込みレイテンシー 50% 0 10 75% 0 12 95% 0 24 98% 0 29 99% 0 42 最小 0 3 最大 0 1109

また、proxyhistogram の場合、10,000: パーセンタイル 読み取りレイテンシ 書き込みレイテンシ 50% 1331 72 75% 1916 103 95% 5722 215 98% 5722 310 99% 5722 372 最小 259 30 最大 5722 11864

パーセンタイル 読み取りレイテンシ 書き込みレイテンシ 50% 1331 42 75% 1916 50 95% 6866 103 98% 6866 149 99% 6866 215 最小 311 18 最大 6866 61214

誰でもこれについて何か考えがありますか？

前もって感謝します！

スティーブン

現在、Windows 7 で Cassandra 2.1.9
を使用しています。Cygwin で nodetool を使用しようとしていますが、以下のメッセージが表示されます。

このディレクトリのエイリアスを作成しようとしましたが、まだ運がありません。

助言がありますか？
ありがとう

「nodetool cfhistograms」を実行すると、表形式のデータが表示されます。

これらがどのように計算されるか説明してください。%le の概念は理解していますが、上記の結果を計算するために考慮される読み取り/書き込みの数を知りたいです。

Cassandra Datastax 2.2.3 クラスター (1 つのノードのみ) があり、テストとして新しいノードを追加しています。新しいノードを正常に追加して で開始した後bootstrap=false、 で再調整しようとしていnodetool repairます。

ただし、古いノードのログに次のエラーが表示されます。

この：

そして修復は失敗します：

実行してみましたnodetool repair -seq-結果は同じです。

質問？

• nodetool の修復にはどのくらいのメモリが必要ですか? それを確認する方法は？
• リングのバランスを今すぐ調整するにはどうすればよいですか? 修復を段階的にトリガーする方法はありますか?
• そうでない場合は、「仮想」RAM (おそらくスワップとして) を追加し、ヒープを増やして修復をトリガーできますか?

バージョン 2.0.9 を実行している cassandra クラスターがあります。Nodetool は最初から実行されていません (これらの修復をスケジュールするように要求されていないため)。各ノードには約 8GB のデータがあります。それは私にはかなり小さいようです。nodetool repair を実行しようとすると、永遠にかかるようです (2 日経っても完了しません)。

進展が見られません。私は、圧縮統計とネット統計をチェックするように指示しているスレッドを読んでいますが、それらはトラフィックがないことを示しています。ただし、nodetool repair コマンドは終了しません。それは私には普通ではないようです。システムのキースペースが修復中で問題ないというメッセージを受け取りました。ただし、入力した実際のデータは何も返しません。すべてのノードが稼働しています。system.log (CentOS 6 BTW) でエラーを確認しましたが、何もありません。コマンドと応答の数がまだ増えているかどうかを確認するコマンドを開始しましたが (これは事実です)、これは別のものからのものなのか、それともノードツールの修復に直接リンクされているのか疑問に思います。IO/ネットの飽和はないようです。そこで昨日、ツール range-repair.py を使用して修復を再開しました。過去 12 時間、余分な出力はありませんでした。最後の出力は次のとおりです。

この修復に永遠にかかる (または単に修復がハングする) ことの主な問題は、アプリの展開のために Cassandra をアップグレードしたいということです。この手順では、最初に nodetool の修復を実行します。アップグレードを開始する前に、これは実際に必要ですか? おそらく、nodetool の方が効率的に動作します (インクリメンタル オプションも利用できるようになりました)。

ここで誰が私を助けてくれますか? よろしくお願いします！