Cassandra 中特定行的更新似乎丢失了答案

【问题标题】：UPDATEs to a specific row in Cassandra appear to go missingCassandra 中特定行的更新似乎丢失了
【发布时间】：2013-06-08 18:04:31
【问题描述】：

我正在试验一个 4 节点 Cassandra (1.2) 集群，我刚刚在 CentOS 6.4 上跨 4 个 VM 设置该集群。首先，我创建了一个复制因子为 3 的键空间，并在其中创建了几个表，并用少量行填充每个表 - 全部使用 Cqlsh。简单的 INSERT、SELECT 和 UPDATE 似乎工作正常。

然后我开始随机断开一些节点，以查看集群的功能。虽然其中两个节点处于脱机状态，但我运行了一些返回正确结果的 SELECT。随后，我尝试更新现有行，根据“nodetool getendpoints”，该行托管在离线节点以及运行 Cqlsh 的本地节点上。使两个节点重新联机后，对更新的行运行 SELECT 并不返回更新的数据值。我等了一会儿，再次尝试 SELECTing，但仍然返回原始数据。我还尝试了以下方法，但都没有返回更新的数据：

重新运行 UPDATE 几次
更新同一行中的不同列 - 该字段未更新
重新启动集群中的所有四个节点

不同行中同一列的 UPDATE 工作正常，这与上面的 #2 一起让我认为这是行数据的问题。

下面的 sn-p 显示了一个 SELECT 在看似成功的 UPDATE 之前和之后返回原始数据：

cqlsh:demo> select email, active from users where email = 'john.doe@bti360.com';

email               | active
--------------------+--------
john.doe@bti360.com |   True

cqlsh:demo> update users set active = false where email = 'john.doe@bti360.com';

cqlsh:demo> select email, active from users where email = 'john.doe@bti360.com';

email               | active
--------------------+--------
john.doe@bti360.com |   True

我是 Cassandra 的新手，所以我很可能会遗漏一些东西。任何有助于发现这里发生的事情的建议或故障排除提示（要检查的文件或要运行的命令）将不胜感激。

【问题讨论】：

如果使用一致性级别 ALL，是否返回更新数据？您可以在 cqlsh 中使用 'CONSISTENCY ALL' 进行设置。
不幸的是，它没有。
在这种情况下更新失败。当您在节点关闭的情况下进行更新时，您是否有 cqlsh 输出？
这很难说，因为我在第一次幻像 UPDATE 之前和之后做了很多类似的操作，但我不记得当时看到过失败。无论哪种方式，为什么对同一行的后续更新会继续丢失？我绝对没有得到任何错误。
您能否粘贴所有 cqlsh 输出以进行更新并选择显示此行为的内容？

标签： cassandra

【解决方案1】：

这可以通过服务器之间的时钟不匹配来解释。更新的时间戳由从客户端接收更新的服务器设置。如果服务器不同步，您可能会遇到这样的行为，即旧更新具有较晚的时间戳，因此会覆盖后续写入。

要找出答案，首先检查服务器上的时钟。您应该始终在 Cassandra 服务器之间运行 NTP，以便时钟相同。

您可以通过使用 WRITETIME 获取时间戳来确认这是否是实际问题：

select WRITETIME(active) from users where email = 'john.doe@bti360.com';

这是自纪元以来的微秒。将值写入不同的行并获取其时间戳。如果这更早，那么这就是原因。

【讨论】：

看准了！同步服务器时钟解决了这个问题。非常感谢理查德！
这帮助很大，谢谢！我们已将时钟拨回以修复其中一台服务器上的临时问题，但它从未得到更新。如果时钟不同步，CQL 客户端/驱动程序真的应该发出很大的警告。

【解决方案2】：

除了 Richard 提到的时间同步之外，我能想到的一个原因是 ANY 或 ONE 的一致性，而不是 QUORUM 或 ALL。但是，使用 QUORUM 或 ALL 并且有太多节点关闭，您会在读取和写入时超时。

但是，即使一致性为 ONE，数据最终也应该变得一致。没有具体说明它需要多长时间才能保持一致，但在我看来，这确实很快。

【讨论】：