我们有一个 13 个节点的 Cassandra 集群（版本 3.10），RP 为 2，读/写一致性为 1。 这意味着集群不是完全一致的，而是最终一致的。我们选择这种设置是为了提高性能，我们可以容忍几秒钟的不一致。
这些表设置为禁用读取修复的 TWCS，我们不会对它们进行全面修复
但是，我们发现某些数据条目只复制了一次，而不是两次，这意味着当查询未更新的节点时，它无法检索到数据。
我的第一个问题是这怎么会发生？ Cassandra 不应该复制所有数据吗？
现在如果我们选择进行修复，它会创建重叠的墓碑，因此它们在时间到时不会被删除。我知道 unchecked_tombstone_compaction 属性忽略了重叠，但我觉得这是一个不好的方法。有什么想法吗？
【问题讨论】：
标签： cassandra
因此，您显然已经对您的客户 CL 做出了一些深思熟虑的选择。您选择了潜在地牺牲一致性来换取速度。您已经实现了目标，但您假设数据总是会到达它所属的集群中的所有其他节点。正如您所发现的，对此没有任何保证。怎么会这样？我确定有多种原因，其中一些包括：网络/问题、硬件过载（I/O、CPU 等 - 这可能导致突变下降）、cassandra/dse 因任何原因不可用等。
如果您的任何节点都没有“离线”至少几个小时（无论是 dse 还是主机不可用），我猜您的节点正在丢弃突变，我会检查两件事： 1) 节点工具 tpstats 2）查看您的 cassandra 日志 对于 DSE：cat /var/log/cassandra/system.log | grep -i 突变 | grep -i drop（以及 debug.log）
我猜您可能正在删除突变，并且 cassandra 日志和 tpstats 会记录这一点（tpstats 只会显示自上次 cassandra/dse 重新启动以来的情况）。如果您要删除突变，则必须尝试了解原因 - 通常是某种负载压力导致它。
我已经安排了 1 秒的 vmstat 输出，该输出通过日志轮换连续地假脱机到日志，因此如果我们的节点开始“行为不端”，我可以返回并检查一些事情。它可以提供帮助。
这就是我要开始的地方。无论哪种方式，您使用读/写 CL=1 的决定都让您处于这个位置。您可能需要重新考虑这种方法。
【讨论】：
Consistency level=1 有时会产生问题，原因有很多，例如由于突变或集群/节点过载或高 CPU 或高 I/O 或网络问题导致数据无法正确复制到集群，所以在这种情况下，您可能会出现数据不一致，但是如果启用了读取修复，则有时会处理此问题。您可以进行手动修复以确保集群的一致性，但您也可以获得一些僵尸数据。
我认为，为避免此类问题，您应该至少考虑使用 CL 进行写入，或者您应该在 GC_grace_period（默认为 10 天）内对集群中的所有表运行手动修复。 此外，您可以使用增量修复，以便 Cassandra 在后台运行修复大块数据。更多详情请参考以下链接
http://cassandra.apache.org/doc/latest/operating/repair.html 或 https://docs.datastax.com/en/archived/cassandra/3.0/cassandra/tools/toolsRepair.html
【讨论】：