問題タブ [datastax-startup]

datastax を使用して、6 つのノード、1 つの Solr、5 つの Spark ノードがあります。私のクラスターは、EBS ボリュームを備えた Amazon EC2 と同様のサーバー上にあります。各ノードには 3 つの EBS ボリュームがあり、LVM を使用して論理データ ディスクを構成します。私の OPS センターでは、同じノードが頻繁に応答しなくなり、データ システムからの接続タイムアウトが発生します。私のデータ量は、3 つのレプリカで約 400GB です。毎分バッチ間隔で 20 のストリーミング ジョブがあります。これが私のエラーメッセージです：

編集：

これらは私のより具体的な構成です。私が何か間違ったことをしているかどうかを知りたいのですが、もしそうなら、それが何であるか、そしてそれを修正する方法を詳細に知るにはどうすればよいですか?

アウトヒープはに設定されています

現在のヒープ:

ヒープ構成:

ヒープ使用量:

なぜこれが起こるのかわかりません。どうもありがとう。

私の datastax クラスター nodetool リングは、重複したトークン (8814750030873335965) を示しています。これらの 1 つには空のアドレスがあります。これを修正する理由や方法がわかりません。

以下の結果をご覧ください。

助けてくれてありがとう。

OpsCenter にノードをインストールしようとすると、次のエラーが発生します。

スタック トレースあり:

com.jcraft.jsch.ChannelSftp.start(ChannelSftp.java:315) com.jcraft.jsch.Channel.connect(Channel.java:152) com.jcraft.jsch.Channel.connect(Channel.java:145) clj_ssh. ssh$connect_channel.invoke(ssh.clj:512) clj_ssh.ssh$ssh_sftp.invoke(ssh.clj:732) lcm.jobs.multinode.common$run_command.invoke(common.clj:707) lcm.jobs.multinode. install.InstallJob.run(install.clj:310) lcm.jobs.multinode.common$run_job.invoke(common.clj:72) lcm.jobs.multinode.common$process_run__18006$fn__18007.invoke(common.clj:90) clojure.core.async$thread_call$fn__8944.invoke(async.clj:434) clojure.lang.AFn.run(AFn.java:22) java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) java. util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) java.lang.Thread.run(Thread.java:745)

に基づいて EC2 を立ち上げましたDataStax Auto-Clustering AMI 2.5.1-pv。スムーズに進むことを期待していましたが、そうではありませんでした..

何か案が？

注: 少し再フォーマットを行い、追加情報を追加しました。

これを見てください: Question_Answer 質問

したい - DSE 5.0 と、今年の C* Summit で言及された 5.1 と 5.2 の今後の変更について、同じアドバイスが役に立ちますか?

私たちのユースケースは次のとおりです。

プラットフォームは常に利用可能でなければなりません。(Cassandra)
データは検索可能でなければなりません。(SOLR / Lucene)
プラットフォームは、分析 / データ ウェアハウス / BI など (Graph / Spark) を提供する必要があります。

DSE のおかげで、これらすべてが 1 つの製品で可能になります。ありがとうDataStax！

しかし、保存されているデータの量とトランザクション数は非常に控えめです。
私たちの仕様は、アプリケーション内で 100 の同時セッションを対象としています。もちろん、これは 100 の同時 DB リクエスト / 操作には変換されません。

ほとんどの場合、私たちのアプリケーションは日常のエンタープライズ CRUD アプリケーションに似ています。

ばかげているわけではありませんが、AWS インスタンスは完全に無料というわけではありません。
ワークロードごとに個別のクラスターを用意する (継続的な可用性のために十分なレプリケーションを行う) ことは、コストの問題になります。

私は理解していますが、概念実証はいくつかの助けを提供できますが、実際のワークロード/実際のユーザーがサービス/アプリケーションを通過することなく、「本番」システムと悪意のあるユーザーのみが実際に洞察を提供できる方法で提供できます。あなたができる最善のことは、「ロードされた」機能テストです。

要するに、プラットフォームの観点からは、ここで少し立ち往生しています。 地理的に分離するための 2 つのデータ センター DC ごとに 2 つのラック ラックごとに 2 つのノード

local_quorum の 3 CL のRF パフォーマンスの問題が発生していることがわかった場合は、スケール アウトできます - 追加のラックを追加するか、最初の 2 つのラックに追加のノード。 V ノードやトークンの数については、わかりません。











DSE Search のドキュメントには、V ノードによって 30% のオーバーヘッドが追加されると記載されているため、V ノードを使用すべきではないように思えますが、ドキュメントの表では、16 または 32 を使用するようにも記載されています。

すべてのワークロードを 1 つのノードで正常に実行できる場合 (要件は本当に最小限です)、V ノード (16 または 32) で実行しますか、それとも単一のトークンを実行しますか?

最後に、別の代替手段はありますか？
同じデータセンターに異なるワークロードを持つノードを配置できますか? 特定のワークロードの RAM/CPU 要件を使用して個々のノードが設定されている場所は?

データセンターごとに 4 つのノードがあると仮定します (出発点としてのみ - 単一ノードで Search を正常に実行できるかどうか、または単一ノードで Spark を実行できるかどうかはわかりません)

ノード 1: Cassandraのみ
ノード 2 : Cassandra と検索
ノード 3 : Cassandra とグラフ
ノード 4 : Cassandra と Spark

検索に 64 GB の RAM が必要な場合 - それでいいのですが、Cassandra のみのノードはわずか 8 または 16 で十分に機能します

。ワークロードの種類ごとの CPU とメモリの条件 - ただし、DC は 1 つしかありません。(冗長性のために 2 つ用意しますが、実質的には単一の DC インストールです: ミラー化されます)

よろしくお願いします。

昨日、私たちのクラスターで破損したセカンダリ インデックスを見つけました。(DSE 4.8.10、c* 2.1.15)。SELECT ステートメントを使用して、データがテーブルにあることを確認しました。を使用した後nodetool rebuild_index cf tn idx_name、次を使用して正しいクエリ結果を取得できましたselect * from <table_name> where <pk> = 'x' and <idx_key> = 'y';

私の質問は - セカンダリ インデックスの破損の可能性を検出、監視、または積極的に探す方法はありますか? 本番環境で壊れた、検出されないセカンダリ インデックスが存在するのは本当に嫌です。

スタンドアロンのスパーク ジョブがあり、ジョブが終了するたびに、次の警告が表示されます。これの意味と解決方法がよくわかりません。お役に立てれば幸いです。ありがとう