因此，如果您确定没有执行删除操作，则导致数据不一致的其他主要原因是：

• 将TTL与gc_grace_seconds设置得太低或设置为零。
• 就地更新，每个节点上的系统时钟不同步。
• 写入背压。
• 丢弃的提示。

使用TTL，您需要确保给tombstone一个复制的机会。这就是gc_grace_seconds默认为864000秒（10天）的原因。如果该值太低，tombstone被标记为删除得太快。因此，tombstone * 后面 * 的数据会重新出现。
在原地更新和时钟不同步的情况下，新写入的数据是有效的，并且被复制，但是WRITETIME比一个或多个节点的系统时钟落后太多。这意味着新写入的数据将不会生效，直到系统时间〉=数据的WRITETIME。
您还可能遇到这样一种情况：所涉及的DC受到大量写入的冲击，导致写入背压逐渐增大到写入被丢弃的程度。如果您看到一个或多个节点出现CPU或磁盘I/O峰值，则可能发生了这种情况。
最后一点，如果您的节点经常出现故障，那么它们的邻居节点将建立提示。这可能发生在网络连接/路由不好的情况下，使一些节点对其他节点“出现”故障。在任何情况下，这些提示都会在3小时后自动停止收集。此设置可以通过cassandra. yaml中的max_hint_window进行配置。
无论哪种情况，不一致的数据都不会自行发生，它通常是另一个问题的症状。

**TL DR;**检查：

• 使用TTL对表执行gc_grace_seconds。
• 检查所有节点上的系统时钟。
• 检查节点是否存在高CPU和/或高磁盘I/O。
• 检查通常建立提示的节点，并在日志中验证是否发送了提示。