为什么使用 Write Consistency ALL 时，表会随着时间的推移而失去同步？

Question

我正在运行具有 1 个数据中心、2 个机架和 11 个节点的 cassandra 3.11.4 集群。我的键空间和表设置为复制 2。我使用 Prometheus-Grafana-Combo 来监控集群。

观察：在使用写入一致性级别 ALL（即 2 个节点）的（大规模）插入期间，受影响的表/节点会慢慢不同步（一个节点上的最坏情况：在 6 小时内从 100% 到 83%）。我的期望是，只有当我使用 ANY（或任何小于我的复制因子）时才会发生这种情况。

我真的很想了解这种行为。

还有什么有趣的：如果我敢于使用写一致性 ANY，我就会明白这一点——即使所有节点都在线，Cassandra 甚至似乎都没有尝试写入所有节点。在任何情况下（任何或所有）如果必须执行增量修复。

Answer 1

首先，您的期望是正确的：写入，无论一致性级别是什么（ALL 或 ONE 或 ANY 或其他），请尽一切努力写入 所有 副本。不同的写入一致性级别仅在向客户端报告“成功”时有所不同：ALL 等待所有写入完成，而 ONE 只等待一个（并且在后台执行其他写入）。因此，除非您的一个节点出现故障或严重超载，否则任何节点上都不应丢失任何写入，并且不一致性应该为零。 “提示切换”功能使不一致的可能性更小（如果一个节点暂时关闭，其他节点会为它保存它错过的写入，并在以后重播它们）。

我认为您唯一的问题是您误解了“percentrepaired”统计数据的含义。 增量修复使用“percentrepaired”指标。在增量修复中，磁盘上的数据分为“已修复”数据（已通过修复过程的数据）和“未修复”数据 - 仍未通过修复的新数据。这并不意味着新数据在节点之间不一致或不同 - 只是还没有人检查过！要将此新数据标记为“已修复”，您需要运行（增量）修复 - 它会发现节点之间的数据没有不同，并将其标记为“已修复”。