バッチモードで削除直後に設定されたcassandra-cliは、紛失してしまいます。

Question

2つのノードからなるcassandra（シンプル）クラスタがあります。カスタムメイドのダンプからのリストア時には

、私たちは多くの場合、最初の列（COLUMN_1）が設定されません...私たちは

del column_family['row_1']; 
set column_family['row_1']['column1'] = '123'; 
set column_family['row_1']['column2'] = '456'; 
set column_family['row_1']['column3'] = '789'; 

のようなラインを持っている場合ことを発見しました。

は、我々は使用：私たちは、Debianのホスト上でカサンドラ1.0.10を使用している

$ cassandra-cli -h cassandra.host.name -k keyspace_name -f dump_file 

。

ダンプは、常にキー空間を削除してから再作成するので、実行すると実際には空になります。実際、deleteステートメントは必要ないことがわかっています。

私たちは削除しましたが、なぜこれが起こるのかまだ分かりません。私はこれが設計によってこのようなことが原因だと思っていますが、私たちはちょうど行方不明ですが、正確に何が「間違っている」か分かりません。

Answer 1

ここで起こっていることは、行削除のタイムスタンプと1つ以上の列書き込みが同じ値を持つことになると思います。 Cassandra-cliは、タイムスタンプ値にミリ秒を使用するという共通の規約に従っています。したがって、削除と挿入がすぐにそのように続くと、非常に可能です。

挿入された列と墓石のタイムスタンプが同じ場合、墓石が勝ちます。あなたの最初の列が一見消えてしまうのは理にかなっています。

ここでは、明示的なタイムスタンプで削除を書き込み、そのタイムスタンプに1を加えた他の列を書き込むことで問題を解決できました。この種のことは通常は必要ではありませんが、これらの書き込みはそれぞれが異なるカサンドラノードに移動することを可能にすることを目的としており、ユーザはいつでも正しい結果を得ることができます。タイムスタンプは競合解決メカニズムです。