Cassandra 2.0.12 (DataStax Community エディション) を実行する 9 ノードのクラスターがありました。このクラスターを拡張する必要があったため、DataStax に従ってさらに 3 つのノードを追加しました。
私たちのアプリケーションは Light Weight Transaction 機能を利用しており、新しいノードが JOINING 状態 (古いノードからデータがストリーミングされている) である間、LWT を含むほとんどのアプリケーション呼び出しが次のエラーで失敗することがわかりました。
com.datastax.driver.core.exceptions.UnavailableException: 一貫性 SERIAL でクエリに使用できる十分なレプリカがありません (6 つが必要ですが、5 つしか有効ではありません)
よくわかりません
レプリケーション ファクターが 3 のときに、エラー メッセージに 6 ノードが必要であると表示されるのはなぜですか。これは、現在新しいノードによって所有されている範囲の古いノードから新しいノードにデータがストリーミングされている間、PAXOS では古いノードと新しいノードの両方が必要になることを意味しますか?さまざまなPAXOSステージに関与していますか？
私の理解では、新しいノードがクラスターに参加している間、古いノードは引き続きすべてのクライアント要求を取得しますが (新しいノードが現在所有しているトークン範囲に対して)、古いノードはすべての書き込み要求を新しいノードに転送し、読み取り要求を引き続き処理します。 . CAS操作はREADとWRITEの両方を意味するため、LWTとPaxosでどのように機能しますか。これが、CAS (IF NOT EXISTS) 操作を実行するときに 6 ノードの応答が必要な理由である可能性があります。その場合でも、ほとんどの CAS 操作が失敗するのはなぜですか? 新しいノードが参加している間に LWT にバグの可能性がありますか、それとも新しいノードが非常にビジーで応答していないという事実ですか。私の場合、新しいノードが JOINING 状態にある間、常に非常にビジーではなかったと確信していますが、LWT 呼び出しは、JOINING 状態にある間はほぼ常に失敗していました。
3 つの新しいノードのうち 2 つがクラスターに参加するとすぐに、エラーの数が大幅に減少し、3 番目のノードも参加するとすぐに確認できました (最初のノードが参加するのに約 5 時間かかり、その後 10 ～ 20 分で他のノードが続きました)。すべてのエラーがなくなり、アプリケーションは正常に戻りました。
誰かがこの動作と、実際に「本番環境」をアップグレードするときにこれらのエラーを回避するために何ができるかを説明してもらえますか (上記のテストはテスト環境で行われました)。