問題タブ [cassandra-2.2]

私が見逃したものを理解するのを手伝ってください。LIMIT句とORDER BY DESC句を使用したSELECTで、1 つのクラスター ノードの奇妙な動作が見られます。

トレース (一部のみ):

…<br> /10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] に REQUEST_RESPONSE メッセージを送信しています | 2016-02-29 22:17:25.117000 | 10.0.23.15 | 7862
REQUEST_RESPONSE メッセージを /10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] に送信しています | 2016-02-29 22:17:25.136000 | 10.0.25.57 | 6283
REQUEST_RESPONSE メッセージを /10.0.25.56 [MessagingService-Outgoing-/10.0.25.56] に送信しています | 2016-02-29 22:17:38.568000 | 10.0.24.51 | 457931
…

10.0.25.56 - コーディネーター ノード
10.0.23.15、10.0.24.51、10.0.25.57 - データを持つノード

コーディネーターは 10.0.24.51 からの応答を他のノードより 13 秒遅く取得します! なんでそうなの？どうすれば修正できますか？

パーティションキー (uid = 0x50236b6de695baa1140004bf) の行数は約 300 です。

ORDER BY ASC (クラスタリング順序) を使用するか、このパーティション キーの行数より少ないLIMIT値を使用すれば、すべて問題ありません。

Cassandra (v2.2.5) クラスターには 25 個のノードが含まれています。各ノードは約 400Gb のデータを保持します。

クラスタは AWS に配置されます。ノードは、VPC 内の 3 つのサブネットに均等に分散されます。ノードのインスタンスのタイプは c3.4xlarge (16 CPU コア、30GB RAM) です。EBS でバックアップされたストレージ (1 TB GP SSD) を使用します。

キースペース RF は 3 です。

列ファミリー:

nodetool gcstats (10.0.25.57):

nodetool gcstats (10.0.23.15):

nodetool gcstats (10.0.24.51):

RF 3 の 3 ノード クラスタがあります。

クラスターから 1 つのノードを排出するとすぐに、多数のノードが表示されます。

すべての書き込みと読み取りは整合性レベル QUORUM または ONE で行われるため、ノードが 1 つダウンしてもすべてが完全に機能するはずです。ただし、ノードがダウンしている限り、例外がスローされます。

Cassandra 2.2.4 + Java Cassandra Driver 2.1.10.2 を使用

クラスターを作成する方法は次のとおりです。

CONTACT_POINTS は、ノードの 3 つのパブリック IP の文字列配列です。

数か月前、クラスターは一時的に 2 つのノードのみで正常に動作していましたが、理由は不明ですが、もうそうではなく、アイデアが不足しています :(

助けてくれてどうもありがとう！

Cassandra 2.2.5 を実行する 24 ノードの AWS クラスター (i2.xlarge) があります。大きなテーブルが 1 つと小さなテーブルがいくつかあります。大きなテーブルは、ほとんどのディスク領域を消費します。ディスク使用量が予期せず増加しています。

LCS を使用していますが、SSTable が上位レベルに移動していないことに気付きました。

表の cfstats は、SSTable がより高いレベルに圧縮されていないように見えることを示しています。

データセットの読み込みは約 1 か月前に完了し、ディスク使用率は 60 ～ 65% でした。データセットを更新しており、ディスク使用量は 1 日あたり約 0.5% 増加しています。現在、ノードは 75 ～ 80% 使用されています。行は更新されていますが、新しい行も削除されている行もありません。そのため、ディスク使用量が増えるとは予想していませんでした。私たちの最善の推測は、コンパクションが sstables から重複を削除していないということです。

データセットを強制的に圧縮しようとすると (nodetool compact)、ディスク容量が不足しているというエラーが発生します。

LCS に関するドキュメントでは、「圧縮による一時的な使用のために予約する必要があるのは、sstable サイズの 10 倍に十分なスペースのみである」と主張しています。私たちの場合、圧縮には 1977x 160MB が必要なようです。

LCS 圧縮レベルをリセットするための提案に出くわしました: ディスク容量が少ない Leveled Compaction Strategy

ただし、同じ問題を抱えた小さなデータセットを持つ小さなクラスターでこれを試したところ、進行した圧縮には、約束された 1.6G だけでなく、大量のスペースも必要であるように見えました。

前：

sstablelevelreset の実行後:

その後の最初の圧縮では、21698490019 バイトの圧縮が開始されました。これは、約 129 個の sstables に相当するデータのようです。

小さなクラスターでは十分な追加ディスク容量がありますが、大きなクラスターでは、圧縮を強制したり、sstablelevelreset ユーティリティを使用して圧縮を最初からやり直したりするのに十分なスペースがないようです。

圧縮が完了すると、sstable レベルは次のようになります (ドキュメントは継続的に更新されますが、データベースには追加されないことに注意してください)。

ディスク容量を回復するために他にできることはありますか? または、少なくともディスクの使用量が増えないようにするためですか?

テーブルは次のように定義されます。

ノードの 1 つからの完全な cfstats:

発生している圧縮について間違っているように見えるものがあります。特に次の 1 つを示します。

圧縮されている 23 個の sstables があることに気付いた場合: レベル 2 から 1 つ、レベル 4 から 1 つ、残りはレベル 3 からです。これらは最終的にレベル 3 に圧縮されますが、テーブルはレベルが上がるだけという印象を受けました。レベル 4 のテーブルがレベル 3 に圧縮されるのはなぜですか? ログでこれに気付いたので、頻繁に発生していることがわかります。たとえば、これはほぼ同じ時期の別のものです。

これが問題かどうかはわかりません。

Cassandra 2.2.3 で SELECT を実行するときの不可解な動作に対処しています。リングに 4 つのノードがあり、次のキースペース、テーブル、およびインデックスを作成します。

次に、テーブルにいくつかの行を挿入します。それらのいくつかは空のセットを持っています。デフォルトの CQL クライアントを介してこのクエリを実行し、期待どおりの行を取得します。

次に、制御できないいくつかのテストを実行します。彼らが何をしているのかはわかりませんが、いくつかの行を読み取り、おそらく挿入/更新/削除すると思います。インデックス、テーブル、またはキースペースの設定を削除または変更しないと確信しています。

テストの後、デフォルトの CQL クライアントを介して再度ログインし、次のクエリを実行します。

最初のものは何も返しません。2 番目の行は、code = 'test' の行を含むすべての行を返します。3 番目のクエリは、最初のクエリで取得できなかった予想される行を返します。

この行と他の行との唯一の違いは、前に説明したように、いくつかの空のセットを含む行の 1 つであるということです。いくつかの空のセットも含む別の行を照会すると、同じ動作が得られます。

問題はセカンダリインデックスに関連していると思います。どういうわけか、テスト中に実行された操作によって、インデックスが特定の行を表示できない状態のままになります。

私は明らかに何かが欠けています。この動作の原因について何か考えはありますか?

前もって感謝します。

アップデート：

問題を回避しましたが、別の場所で同じ問題を見つけました。問題が最初に発生したため、エラーの前に実行された操作について詳しく知りました。その列に TTL を設定する特定の列の更新です。いくつかの調査の結果、この問題に関連している可能性のある Jira の問題がいくつか見つかりました。

https://issues.apache.org/jira/browse/CASSANDRA-6782 https://issues.apache.org/jira/browse/CASSANDRA-8206

しかし、これらの問題は 2.0 と 2.1 では解決されているようで、私は 2.2 を使用しています。これらの変更は 2.2 に含まれていると思いますが、間違っている可能性があります。

2.2.53 つのノードで構成される新しい Cassandra クラスターに復元しています。

NEW クラスタの初期クラスタ ヘルス:

Datastax docsの復元手順の一部として、新しいクラスターで次のことを行います。

1) cassandra stop3 つのノードすべてで 1 つずつ。

2)cassandra.yamlバックアップされたトークンリング情報を使用して、3 つのノードすべてを編集します。[ドキュメントからのステップ 2]

/var/lib/cassandra/data/system/*3) [手順 4 from docs]の内容を削除します。

4)cassandra startノード10.40.1.1、10.40.1.2、10.40.1.3それぞれ。

結果: 10.40.1.1正常に再起動します:

しかし、2 番目と 3 番目のノードは次のように再起動できません。

最終的なクラスタの健全性:

システム ディレクトリが削除された後、ノードの HostID が変更される可能性があることを理解しています。

私の質問は：

自分自身を置き換えるために開始時に明示的に述べる必要がありますか? ドキュメントが不完全ですか、それとも手順に何か不足がありますか?

Java クライアント アプリケーションで使用される 4 ノードの Cassandra (2.2.1) クラスターがあります。レプリケーション ファクターは 3、整合性レベルは読み取りと書き込みの LOCAL_QUORUM です。各ノードには約 5 GB のデータがあります。リクエストの量は、1 秒あたり約 2 ～ 4k です。削除操作はほとんどないため、少量のトゥームストーンが作成されます。

少し前に読み取りと書き込みのパフォーマンスが低下していることに気付きましたが、時間の経過とともに悪化しています。クラスターが非常に遅くなっています。読み取り (ほとんどの場合) と書き込みのタイムアウトが非常に頻繁になりました。ハードウェアが問題を引き起こすことはありません。クラスターが展開されているサーバーは、ディスク パフォーマンス、CPU および RAM リソースの点で非常に優れています。

問題の原因は不明ですが、根本的な原因を示している可能性があるいくつかのログ エントリに気付きました。

1. Java クライアント アプリケーション ログの例外スタック トレース:

   com.datastax.driver.core.exceptions.ReadTimeoutException: 整合性 LOCAL_QUORUM で読み取りクエリ中に Cassandra タイムアウトが発生しました (2 つの応答が必要でしたが、応答したレプリカは 1 つだけでした)

興味深いのは、1 つのノードがまだ応答していることです。

2. 失敗したヒント エラーのいくつかのエントリ:

   /1.1.1.1 へのヒントの再生に失敗しました。中止中 (135922 配信済み)、エラー: 操作がタイムアウトしました - 0 応答しか受信しませんでした。

3. Cassandra ログのいくつかの次の例外:

   リクエスト中に予期しない例外が発生しました。channel = [id: 0x10fc77df, /2.2.2.2:54459 :> /1.1.1.1:9042] java.io.IOException: 読み取り中にエラーが発生しました (...): io.netty.channel.epoll.Native で接続がタイムアウトしました.readAddress(ネイティブ メソッド) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.epoll.EpollSocketChannel$EpollSocketUnsafe.doReadBytes(EpollSocketChannel.java:675) ~[netty -all-4.0.23.Final.jar:4.0.23.Final] at io.netty.channel.epoll.EpollSocketChannel$EpollSocketUnsafe.epollInReady(EpollSocketChannel.java:714) ~[netty-all-4.0.23.Final. jar:4.0.23.Final] at io.netty.channel.epoll.EpollEventLoop.processReady(EpollEventLoop.java:326) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io. netty.channel.epoll.EpollEventLoop.run(EpollEventLoop.java:264) ~[netty-all-4.0.23.Final.jar:4.0.23.Final] at io.netty.util.concurrent.

4. 失敗したバッチ エラー:

   [<...>] の準備済みステートメントのバッチのサイズは 3453794 で、指定されたしきい値の 1024000 を 2429794 超えています。 (batch_size_fail_threshold_in_kb を参照)

バッチが大きすぎるようです。ところで、バッチ操作がたくさんあります。多分バッチはシステムに影響しますか？

5. 最後に、ほとんどの場合に見られる例外です。ログ レベルを DEBUG に切り替えた後、これらのエントリが次々と表示されます。

   TIOStreamTransport.java:112 - 出力ストリームを閉じるときにエラーが発生しました。java.net.SocketException: java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:116) でソケットが閉じられました ~[na:1.8.0_66] java.net.SocketOutputStream.write(SocketOutputStream.java:153) で ~[na: 1.8.0_66] java.io.BufferedOutputStream.flushBuffer(BufferedOutputStream.java:82) で ~[na:1.8.0_66] java.io.BufferedOutputStream.flush(BufferedOutputStream.java:140) で ~[na:1.8.0_66] java.io.FilterOutputStream.close(FilterOutputStream.java:158) で ~[na:1.8.0_66] org.apache.thrift.transport.TIOStreamTransport.close(TIOStreamTransport.java:110) で ~[libthrift-0.9.2. jar:0.9.2] org.apache.cassandra.thrift.TCustomSocket.close(TCustomSocket.java:197) で [apache-cassandra-2.2.1.jar:2.2.1] org.apache.thrift.transport.TFramedTransport で.close(TFramedTransport.java:

この問題の原因について何か考えはありますか?

ありがとうございました！

既存の Cassandra 2.2.x クラスター内の vNode の数が変更された場合、そのクラスター内のすべてのデータが失われますか?
vNode の数を変更して、すべてのデータを Cassandra クラスターに保存しておくことは可能ですか?

新しいcassandraノードを追加した後、cassandra接続で奇妙な問題に直面しています。

ノードを追加する前の状況:

• データセンター 1 のサーバー 1 に 1 つの cassandra ノード
• 多くのマシンに分散された完全に機能する Java アプリケーション
• データセンター 1 のサーバー 1 上の PHP nginx Web サーバー
• 完全に機能する PHP アプリケーション (結果表示用)

次に、データ センター 2 に 2 番目のストレージ サーバーを追加しました。両方のストレージ サーバーのレプリケーション係数は 1 です (すべてのデータは両方のサーバーにあります)。したがって、キースペースを変更しました。その結果、データはスムーズに同期され、その有効性は Datastax Devcenter アプリで確認されました。

ノードを追加した後の状況:

• データセンター 1 のサーバー 1 に 1 つの cassandra ノード
• データセンター 2 のサーバー 2 に 1 つの cassandra ノード
• 多くのマシンに分散された完全に機能する Java アプリケーション
• データセンター 1 のサーバー 1 上の PHP nginx Web サーバー
• PHP アプリケーションが例外でクラッシュします: All connections on all I/O threads are busy..すべての接続が利用可能であっても。

次に試したこと：

• Github Datastax PHP コード サンプルをダウンロードしました
• コンソールphpコマンドを介してコードからこの部分を実行すると、うまくいきました
• nginxを介してブラウザで同じコードを実行すると、再び受信しましたAll connections on all I/O threads are busy

nginx 構成または PHP webapp で何も変更していません。キースペースと同期サーバーを変更しました。

その「接続がビジー」エラーを取り除く方法はありますか?