問題タブ [nodetool]

Opscenter では、ノードの 1 つがオレンジ色になっています。圧縮に取り組んでいるようです。私は nodetool compactionstats を使用しましたが、これを行うたびに、Completed nad のパーセンテージは同じままです (間に時間があっても)。現在、そのノードのcassandraからのCPU負荷は見られません。そのため、スタックしているように見えます (60% 半ばのどこか)。また、他のいくつかのノードでは、同じ列ファミリで圧縮が行われています。進展が見られません。

編集: 突然、再び変化が見られます。しかし、進捗は上がらなかった。+60% から始まり、現在は 50.95% です。それで、圧縮が再開されたようです。EDIT2:実際に突然終了したようで、2 つの同様の名前の columnfamilies を混同しました。EDIT3: フィニッシュは別のノードにもありました。ノードの 1 つがまだこの「スタック」状態にあり、ドレインされており、Java に CPU を使用していません。

• 何も起こっていないことをどのように保証できますか?
• 特定のデータ サイズから圧縮を無効にすることをお勧めしますか? （各ノードで25GBだと思います）。
• この圧縮を停止できますか? nodetool stop 圧縮が機能していないようです。
• 圧縮を停止することは危険ですか?
• 圧縮中にcassandraプロセスを強制終了するのは危険ですか?

他に何かコメントはありますか？よろしくお願いします！

これは、スタックしているように見えるキースペースを grep した nodetool compactionstats の出力です。

また、system.log に次のような行が頻繁に表示されます。

非常に大きなテーブルの行数を取得しようとしていますが、約 10 万行あります。私が使用した：

nodetool cfstats

結果は次のとおりです。

鍵の数（目安）：30

なぜ見積もりがこんなに間違っているのですか？

ありがとう。

別のマシンに移動するために、Cassandra からすべてのデータをバックアップしようとしています。

これを行うためにnodetoolを使用しています。

nodetool を実行すると、新しい「スナップショット」フォルダーが各列ファミリーのフォルダー内に作成され、そのフォルダーには「my_backup」という名前のフォルダーが含まれます。ただし、このフォルダーのサイズはかなり小さいです (元のフォルダーのサイズの 10% 未満)。そのフォルダーを自分のマシンにコピーし、Cassandra を停止し、各キースペース内のファイルを置き換えて、Cassandra のバックアップを開始しました。

しかし、今私がするとき

元のサーバーよりも少ない数のエントリを取得します。

私は何か間違ったことをしていますか？別のマシンに移動するために Cassandra 内のデータの完全なバックアップを作成するにはどうすればよいですか?

nodetoolコンパクトのドキュメントには次のように書かれています：

このコマンドは、SizeTieredCompactionStrategy と DateTieredCompactionStrategy を使用するテーブルで圧縮プロセスを開始します。圧縮のキースペースを指定できます。

しかし、それは DateTieredCompactionStrategy に対して何をするのでしょうか?

副次的な質問:-s, --split-outputパラメータとは何ですか? 次のように説明されていますUse -s to not create a single big file。私は混乱しています - それが の目的ではないnodetool compactですか?

cassandra nodetool ヒストグラムのパーセンタイルとその他の列を読み取る方法は?

cassandra opscenter は、2 ～ 3 分ごとに「エージェントが接続に失敗しました」と「すべてのエージェントが接続されました」を切り替えますか? 何が起こっているのかわかりません。上の図に示すように、すべてのエージェントが 2 ～ 3 分間接続された後、エージェントとの接続に問題があると表示されます。また、すべての conf ファイルを確認しましたが、ssl はデフォルトのように使用されていません。これは AWS amazon を介して行われます。