Iam运行带有1个数据中心，2个机架和11个节点的cassandra 3.11.4集群。我的键空间和表都设置为复制2。我使用Prometheus-Grafana-Combo来监视集群。
观察：在使用Write-Consistency Level ALL（即2个节点）的（大规模）插入过程中，受影响的表/节点缓慢不同步（一个节点上最差的情况：在6小时内从100％变为83％）。我的期望是，只有在我使用ANY（或小于复制因子的任何东西）时，这种情况才会发生。
我真的很想了解这种行为。
还有趣的是：如果我敢使用写一致性ANY，我将完全理解-即使所有节点都处于联机状态，Cassandra似乎也没有尝试写入所有节点。在任何情况下（任何或全部），如果必须执行增量维修。
答案 0 :(得分：1)
首先，您的期望是正确的：无论一致性级别是什么（ALL或ONE或ANY或任何东西），写入时都应尽一切努力写入 all 副本。仅当向客户端报告“成功”时，不同的写一致性级别才有所不同：ALL等待直到完成所有写操作，而ONE等待仅一个写操作（而其他在后台执行）。因此，除非您的节点之一发生故障或严重过载，否则任何节点上都不应丢失任何写入操作，并且应将不一致性保持为零。 “提示移交”功能使不一致的可能性更小（如果一个节点暂时关闭，其他节点会为其保存丢失的写操作，然后稍后重播）。
我认为您唯一的问题是您误解了“维修百分比”统计数据的含义。 增量维修使用了“维修百分比”指标。在增量修复中，磁盘上的数据会在“已修复”的数据（已通过修复过程的数据）和“未修复”的数据之间进行拆分-仍不能通过修复的新数据。这并不意味着新数据在节点之间不一致或不同-只是还没有人检查！要将此新数据标记为“已修复”，您需要运行（增量）修复-它会意识到节点之间的数据没有不同，并将其标记为“已修复”。