Cassandra跨集群备份恢复后数据不一致问题排查求助

这种Cassandra跨集群快照恢复后数据量差异的问题我之前处理过好几次，结合你只恢复单节点快照到测试集群的操作，核心问题大概率和Cassandra的分布式存储特性有关。下面给你拆解可能的原因和具体的排查方向：

可能的核心问题 #

• 单节点快照仅包含该节点负责的副本数据
  Cassandra是分布式存储系统，数据会根据副本策略（比如RF=3）分散存储在多个节点上。你只对生产集群的1个节点做了快照，这个快照里只有该节点持有的那部分副本数据，并不是整个集群的全量数据。比如当副本因子为3时，单节点大概存储整个集群1/3左右的数据，再扣除生产期间1-2%的变动，刚好和你提到的测试集群数据少25%的情况吻合——这应该是最主要的原因。

• 快照未捕获全部持久化数据
  虽然生产数据变动很小，但如果执行nodetool snapshot前没有先对目标节点执行nodetool flush <keyspace>，该节点的memtable中未持久化的数据不会被包含在快照里。不过这个因素导致的数据缺失量通常不会达到25%，但也需要排除。

• 测试集群的配置与生产不匹配
  如果测试集群的num_tokens设置、keyspace副本策略（RF）和生产不一致，会导致token范围分配不同。即使恢复了单节点快照，测试集群也无法识别或访问其他节点应该负责的数据范围，进而出现数据量差异。

• Refresh操作未正确执行
  执行nodetool refresh时如果没有指定具体的keyspace或表，可能只刷新了部分数据；另外如果测试节点的目录结构和生产不一致，快照文件可能没有被正确加载。

具体排查方向 #

• 验证单节点快照的数据覆盖比例
  在生产集群的快照节点上，执行nodetool status查看每个keyspace的副本分布，再对比该节点上data/<keyspace>/<table>目录下的SSTable大小总和，计算其占整个集群对应表的存储比例。如果比例接近1/RF（比如RF=3时约33%），就能确认是快照范围导致的数据缺失。

• 检查快照的完整性
  前往生产节点的快照目录（默认路径为data/<keyspace>/<table>/snapshots/<你的快照名>），对比该目录下的SSTable文件和data/<keyspace>/<table>下的所有SSTable文件，确认快照包含了全部当前持久化的SSTable。如果有缺失，重新执行nodetool flush <keyspace>后再生成快照。

• 对齐测试集群与生产的核心配置

  1. 检查测试集群cassandra.yaml中的num_tokens是否和生产完全一致；
  2. 用DESCRIBE KEYSPACE <keyspace>命令对比生产和测试的keyspace副本策略、一致性级别等配置，确保完全匹配。

• 按照正确流程验证全量恢复
  跨集群快照恢复需要对生产集群的每个节点分别生成快照，然后将每个节点的快照恢复到测试集群中对应的节点（按token范围匹配）。如果测试集群是全新集群，需要先构建和生产相同token范围的节点集群，再逐个恢复对应节点的快照——这才是获取全量数据的正确方式。

• 精细化校验数据一致性
  不要只看总记录数，选择几个核心业务表：

  • 小表可以直接用SELECT COUNT(*) FROM <keyspace>.<table>对比生产和测试；
  • 大表建议抽样查询，或用nodetool cfstats <keyspace>.<table>查看Number of keys (estimate)，确认测试节点的数值和生产对应节点的数值一致，以此验证单节点快照恢复的完整性。

内容的提问来源于stack exchange，提问作者Sanjay