【问题标题】:Data Inconsistency in Cassandra Cluster after migration of data to a new cluster将数据迁移到新集群后,Cassandra 集群中的数据不一致
【发布时间】:2020-11-16 11:06:10
【问题描述】:

将数据移动到新集群后,我发现一些数据不一致。

旧集群总共有 9 个节点,每个节点上都有 2+ TB 的数据。 新集群与旧集群具有相同的节点集,并且配置相同。

这是我按顺序执行的:

  1. nodetool snapshot
  2. 将该快照复制到目标
  3. 在目标集群上创建了一个新的键空间。
  4. 使用sstableloader 实用程序加载。
  5. 重新启动所有节点。

成功完成传输后,我运行了几个查询来比较(旧集群与新集群),发现新集群并不一致,但我看到的数据正确分布在每个节点上(nodetool status)。 相同的查询为某些分区返回不同的结果集,我第一次得到零行,第二次得到 100 行,200 行,最终它对于少数分区变得一致,并且记录计数与旧集群匹配。
新集群中很少有分区没有数据,而旧集群有这些分区的数据。

我尝试使用CONSISTENCY ALLcqlsh 运行查询,但问题仍然存在。

我是否错过了之前和之后需要考虑的任何重要步骤?

是否有任何程序可以找出问题的根本原因?

我目前正在运行 "nodetool repair" ,但我怀疑这是否可以解决,因为我尝试使用 Consistency ALL。

非常感谢您的帮助!

【问题讨论】:

    标签: cassandra cassandra-3.0 cqlsh


    【解决方案1】:

    结果最终变得一致的事实表明副本不同步。

    您可以通过查看加载数据时的日志来验证这一点,尤其是对于丢弃的突变。您还可以检查nodetool netstats 的输出。如果您看到阻止读取修复,这是副本不同步的另一个确认。

    如果你还有其他分区可以测试,用CONSISTENCY ALL查询时,在cqlsh中启用TRACING ON。您将看到跟踪输出中是否存在摘要不匹配,这也应该触发读取修复。干杯!

    [编辑] 根据您下面的 cmets,听起来您可能没有使用 sstableloader 从源集群中的所有节点加载快照。如果您错过了将 SSTables 加载到目标集群,那么这就可以解释为什么数据丢失了。

    【讨论】:

    • 感谢您的回复,但这无助于找到我的问题的根本原因。当我在该分区的每个节点上使用 CONSISTENCY ALL 运行查询时,我得到零行,但源集群上存在该特定分区的数据。我更担心丢失数据,因为我知道不一致的数据最终会变得一致。
    • 理想情况下,查询必须有一些结果,但在每个节点上,该分区没有任何结果。 - 在这种情况下,罪魁祸首是什么?这与令牌有关吗?请分享您的想法!
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2016-02-08
    • 2015-03-25
    • 1970-01-01
    • 2017-07-18
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多