1

我有一个 3 节点集群，replicate_factor 也是 3。一致性级别是写入仲裁、读取仲裁。交通有三大步骤

  • 创造：
    • 行键：xxxx
    • 列：状态=新，请求=“xxxxx”
  • 更新：
    • 行键：xxxx
    • 列：状态=正在执行，请求=“xxxxx”
  • 删除：
    • 行键：xxxx

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

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

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

我不知道由于GC或compaction，其他两个节点上的删除记录似乎不起作用，如果使用cassandra客户端列出数据（也是一致性仲裁），删除的行再次显示列值。由于恢复节点再次重放历史。

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

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

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

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

4

1 回答 1

1

检查日志和配置后，我发现它是由两个原因引起的。

  1. GC 宽限秒

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

  2. 二级索引

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

    所以二级索引似乎不受一致性配置的限制。

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

于 2013-10-15T05:14:07.403 回答