2 つのデータ センターがあり、それぞれのレプリケーション ファクターは 3 です。
データが両方の DC (6 ノード、または 3 + 1) に格納されるまで、CL.ALL ブロックで書き込みますか? ローカル DC の 3 つのレプリカすべてが書き込みの成功を確認するまでブロックすると仮定します。
CL.ONE で読み取ることができるように、すべてのレプリカのデータを単一の DC に格納する CL.ALL_LOCAL のようなものが必要です。アイデアは、単一の DC 内のすべてのレプリカがデータを永続化するまでブロックを書き込み、次の読み取りでは新しいデータを読み取る可能性が高いということです。
現在、あなたが説明しているものを提供する一貫性レベルはありません。最も近いのは LOCAL_QUORUM で、ローカル データセンターのノードのクォーラムが応答した後に返されます。
必要に応じて、jira にチケットを提出して、この機能を追加できます。
Cassandra 1.1 のコードをチェックしたところ、マルチ DC 展開で CL.ALL を使用して書き込みを行うと、興味深い動作に気付きました。おそらく私はコードを間違って解釈しました.... とにかく：
最初に、行の変更を送信するためにノードの IP アドレスを収集します。これは、クライアントによって提供される一貫性レベルとは無関係です。1.0 では、すべての DC からのすべてのノードでしたが、1.1 からは、ローカル DC からすべてのノードを取得し、さらに各リモート DC から 1 つのノードを取得します (残りのノードは、メッセージの「転送先」と同じです)。各ミューテーションは個別のスレッドで送信されるため、リクエストは並行して実行できます。このような各ミューテーションは、メッセージング サービスによってメッセージとして処理されます。リモート DC のノードがメッセージを受信すると、「転送先」で指定された残りのノードに転送します。
クライアントによって提供される一貫性レベルは、受信メッセージを確認する必要があるノードの数を定義します。CL.ALL の場合、この数はレプリケーション ファクターによって決定されます。興味深いことに、ローカル DC からすべてのノードにメッセージを送信し、リモート DC からノードにメッセージを送信したため、これらの削除ノードからも確認応答が返されます。はいこれは依然としてレプリケーション係数によって定義される数ですが、notwork レイテンシーによっては、どのノードが受信メッセージを確認したかを確認できません。ローカルおよびリモート DC からのノードが混在している可能性がありますが、ローカル DC からのノードのみである可能性もあります。 . 最悪の場合、どのローカル ノードもメッセージを受信せず、リモート DC から確認が行われる可能性があります (多数の DC がある場合)。これの意味は -CL.ALL を使用して書き込みを行っても、ローカル DC からメッセージをすぐに読み取ることができるというわけではありません。