問題タブ [datastax-startup]

以下を設定しました。外部パブリック IP への rpc_address。リッスン アドレス: 内部 IP アドレス (ローカル ホストではない)、rpc_broad_cast: 内部 IP アドレス

デベロッパー センターでは、外部 IP とポート 9042 を使用しています。

何か間違ったことをしている場合はお知らせください。

クラスターで vnode を使用します。

ノードのトークン スペースが変更されると (vnode で自動的に、新しいノードを追加した後の修復またはクリーンアップ中に)、datastax nodejs ドライバーが数分間多くの「操作がタイムアウトしました - X 応答のみを受け取りました」と表示されることに気付きました。 .

ONE および LOCAL_QUORUM の一貫性を使用してみました。

これは、移動直後にコーディネーターが正しいノードにヒットしなかったことが原因だと思います。これは論理的な動作 (データが移動された) のように見えますが、この特定の問題に本当に対処したいと考えています。

これを避けるために私たちがすべきことは何ですか？カスタムの再試行ポリシーがありますか? キャッシング？一貫性の変更？

動作例

これを見ると：

それらのスパイクが見られます。

セットアップ:
各ノードに約 850G のデータを持つ 3 つのノード Cassandra クラスターがあり、Cassandra データ ディレクトリ (現在は 3 つのドライブ 800G + 100G + 100G で構成される) 用に LVM セットアップがあり、cassandra_logs 用に別のボリューム (非 LVM) があります。

バージョン:
Cassandra v2.0.14.425
DSE v4.6.6-1

問題:
各ノードの LVM に 3 番目 (100G) のボリュームを追加した後、すべてのノードのディスク I/O が非常に高くなり、頻繁にダウンします。サーバーにもアクセスできなくなり、サーバーを再起動する必要がありますが、サーバーは再起動しません。 t が安定し、10 ～ 15 分ごとに再起動する必要があります。

その他の情報:
すべてのノードで DSE 推奨のサーバー設定 (vm.max_map_count、ファイル記述子) が構成されてい
ます 各ノードの RAM : 24G 各
ノードの CPU : 6 コア / 2600MHz
各ノードのディスク : 1000G (データ ディレクトリ) / 8G (ログ) )

m4.* インスタンスに DSE をインストールしたいのですが、最新のComboAMIではサポートされていないようです。これは、インスタンス ストアに基づくインスタンスではなく、ebs ストアに基づくインスタンスであり、PV インスタンスではなく HVM インスタンスであるため、別の構成が必要です。

新しいプロビジョニング スクリプトの作業を開始しました。これは基本的に ComboAMI プロビジョニング スクリプトが行うことですが、ノードごとに接続する EBS ボリュームの RAID0 の作成と xfs ファイル システムの作成も追加します。

私の質問は 2 つの部分に分かれています。まず、DataStax の誰かがすでに似たようなことをして共有できるかどうか疑問に思っていました。

次に、m4.* インスタンス タイプで同様の AMI を構築した経験のある人はいますか? 私は、ComboAMI プロジェクトで何かを動作させることができませんでした。

(簡単にするために) レプリケーション係数が 1 の 3 つのノードからなるクラスターがあるとします。ノード A、B、C と呼びましょう。

リングによると、パーティション キー X は A に格納されるはずです。しかし、データベースの復旧により、パーティション キー X のデータはノード B に配置されてしまいました (そして、A は X をまったく格納しません)。

質問: を発行nodetool repairすると、パーティション キー X が最終的に A になることを確認できますか?

データベースの回復を行う実際の方法は、 のようなものを使用することだと理解していますがsstableloader、予期しない状況により、上記を実行する方が簡単な解決策になる可能性があります (うまくいく場合!)。