当我第一次开始使用Cassandra时，我使用了节俭。
创建表后，我不得不等待确保在所有节点上创建表。如果没有等待，节点可能没有准备就绪并且该表将无法使用（如果查询被发送到＆＃34;错误的节点＆＃34;将会发出许多错误。）
为了＆＃34; synchronized＆＃34;，我会等到describe_schema_versions()只返回一个版本的模式。这意味着它被冻结在所有节点上。
CQL中似乎没有等价物。这是否意味着旧版本（使用Thrift）的同步问题已修复？或者我在搜索中遗漏了什么？
答案 0 :(得分：3)
在CQL中，自从Cassandra 1.1进行模式更改后，您的协调器节点会完成所有繁重工作，以确保模式“同步”。如果在架构更改期间节点关闭，则在它再次启动之前，它会确保它具有来自其他节点的最新架构版本。More Detailed Information about the change from the old way here。这是关于如何解决模式冲突的另一个相关stackoverflow question。
答案 1 :(得分：3)
在执行模式更改语句后，现代DataStax驱动程序会自动检查并等待架构协议。 Cassandra为模式更改语句返回特殊响应，允许驱动程序自动执行此操作。一旦驱动程序获得该响应，它（阻塞地）查询执行查询的节点的system.peers表，以检查报告的其他节点的模式版本。它将继续在循环中执行此查询，直到达到架构协议或达到超时。
在Python驱动程序中，如果在未达到架构协议的情况下达到超时，则ResponseFuture对象（从execute_async()返回的对象）将其is_schema_agreed属性设置为False。我不确定其他语言的驱动程序是做什么的，但可能有类似的东西。
总而言之，您以前与Thrift驱动程序有关的检查现在是自动的，可能更强大。