Cassandra 的副作用暗示切换导致不一致

Question

我有一个 3 节点集群，replicate_factor 也是 3。一致性级别是写入仲裁、读取仲裁。 流量分为三个主要步骤

• 创建：
  • 行键：xxxx
  • 列：status=new, requests="xxxxx"
• 更新：
  • 行键：xxxx
  • 列：status=executing, requests="xxxxx"
• 删除：
  • 行键：xxxx

当一个节点宕机时，它可以按照一致性配置工作，最终状态是所有请求都完成并删除。

所以如果运行 cassandra 客户端来列出结果（也设置一致性仲裁）。显示为空（只剩下rowkey），正确。

但是如果我们启动死节点，提示切换模型会将数据写回该节点。所以有很多创建，更新，删除。

不知道是GC还是compaction，其他两个节点上的delete记录好像不行，如果用cassandra客户端列出数据（也是consistency quorum），被删除的行再次显示列值。由于恢复节点再次重放历史记录。

如果使用客户端多次检查数据，你会发现数据发生了变化，似乎暗示了handoff replay操作，删除的数据出现然后消失。

有没有办法让这个过程从外部不可见，直到提示的切换完成？

我想要的是最终状态同步，临时状态已经过时并且不正确，不应该从外部看到。

是因为行删除而不是列删除吗？还是压实？

Answer 1

查看日志和配置后，发现是两个原因造成的。

1. GC 宽限秒

   我使用hector客户端连接cassandra，每个列族的GCgrace seconds默认值是零！所以当提示切换重放临时值时，其他两个节点上的墓碑被压缩删除。然后客户端将获得临时值。

2. 二级索引

   即使解决了第一个问题，我仍然可以从 cassandra 客户端获得临时结果。我使用“get my_cf where column_one='value'”之类的命令来查询数据，然后再次显示临时值。但是当我再次使用原始键查询记录时，它就消失了。 而从客户端，我们总是使用行键来获取数据，这样我就没有得到临时值。

   看来二级索引不受一致性配置的限制。

   当我将 GC 宽限秒数更改为 10 天时。我们的问题解决了，但是在使用索引查询时仍然是一个奇怪的行为。