私のアプリケーションログでは、デフォルトでcreate/alter tableステートメントを実行した後、cassandraドライバがスキーマを最大10秒間一致させる処理を行っているようです。Cassandra DDLの一貫性レベル
'テーブルを作成.. IF NOT EXISTS'のようなDDL文を実行しているときに、 'quorum'の整合性レベルを設定して、すべてのノードにテーブルを作成して伝播させることはできますか？
カサンドラでの1.1+以降のスキーマ変更（データ定義）はgossipで行われます。ゴシップを使用しているため、一般的なデータ操作要求（SELECT、DELETE、INSERTなど）とは別の読み取り/書き込みパスであるため、ゴシップは調整可能な整合性で動作しないため、このような操作のチューニング可能な一貫性はありません。私がリンクした記事から、が受動的にであることがわかりました。また、スキーマが変更されたときに到達できなかったノードがあると、スキーマの不一致/解決を得ることができます。
どのくらいの頻度でスキーマを変更していますか？スキーマの変更がわかるように、これまでのものより大幅に改善されたが、のように非常に高価な操作であり、すべてのノードは一貫性を持たなければならない。このため、Cassandraのスキーマの変更は避けてください（動的列）。どのくらいの頻度でスキーマが変更されているのか不思議に思うかもしれません。おそらくCassandraの高価なスキーマ変更を避けるために動的な列やテーブルを改造することができます。
整合性レベルを変更しても、クラスタが合意になるまでの時間は変わりません。これがクラスタで10秒かかる場合、クライアントはすべてのノードが一致するのを完全に待つのではなく、単にデフォルトのタイムアウトになる可能性があります。このプロセスの詳細については、Java Driver docsを参照してください。
アプリケーション外では、スキーマの状態をnodetool describeclusterで確認できます。これは、特定のノードがスキーマへの変更を受け入れていない場合に表示されます。オペレータの観点からのスキーマの不一致を解決するには、more informationがあります。
ありがとう@fromantor。スキーマを頻繁に変更しているわけではありません。スキーマを追加するときに新しいバージョンを公開するときもあります。そのような機会に、私たちはアプリログの失敗を見て、新しいテーブルスキーマをすべてのcassandraノードに伝播できないことを発見しました。 – ktewari