Apache Cassandra 3.11.x 键空间快照灾备恢复异常问题咨询

现有恢复流程存在4个核心错误，是触发异常的根本原因：

• sstableloader使用逻辑错误。sstableloader是集群级数据导入工具，会自动根据目标集群的分区规则、副本策略将SSTable分发到所有对应副本节点，无需仅在持有快照的节点执行，也不需要提前将快照文件拷贝到目标节点。仅在2个节点重复执行sstableloader是触发数据重复的核心诱因。
• 未校验键空间配置一致性。若新集群键空间的副本数、复制策略、机架配置与原集群不一致，无论用sstableloader还是nodetool refresh都会出现数据异常。
• repair执行时机和方式错误。全量数据加载完成后仅需执行1次集群级全量repair即可，逐节点执行repair会触发不必要的多副本数据对比合并，容易引入版本冲突导致数据重复。
• nodetool refresh操作逻辑错误。refresh要求将对应表的所有SSTable文件直接存放到目标节点对应键空间/表的data目录下，且需要保证文件权限、所有者与Cassandra运行用户一致，同时SSTable版本需要和目标集群兼容，否则会识别失败。

数据重复问题解决 #

1. 先确认重复数据的冲突规则：Cassandra按写入时间戳writetime判定最新版本，可执行SELECT writetime(字段名) FROM 表名 WHERE 主键 = 重复数据主键确认重复数据的时间戳差异。
2. 冲突数据清理：如果是副本同步异常导致的重复，执行一次全集群范围的nodetool repair -full即可自动合并冲突版本；如果是重复加载导致的多版本冗余，执行nodetool compact 键空间名 表名触发大合并即可清理重复数据。
3. 恢复流程校正：
   • 搭建3节点新集群，确保集群名、机架配置、Cassandra版本与原集群完全一致
   • 通过快照中的schema.cql创建完全一致的键空间和表结构，手动校验键空间的复制策略、副本数与原集群100%匹配
   • 在任意一台持有快照文件的节点上，针对每个键空间/表执行一次sstableloader即可，无需多节点重复执行
   • 所有数据加载完成后，执行一次全集群全量repair，确认数据一致性

nodetool refresh加载失败问题解决 #

1. 基础配置校验：
   • 确认所有SSTable文件直接拷贝到目标节点的/var/lib/cassandra/data/键空间名/表名-随机后缀/目录下，不要嵌套子目录
   • 执行chown -R cassandra:cassandra /var/lib/cassandra/data/键空间名/表名-随机后缀/修正文件权限和所有者
   • 确认原快照的Cassandra版本与新集群版本兼容，3.11.x大版本的SSTable可以在同大版本集群直接加载，跨大版本需要先在原集群执行nodetool upgradesstables 键空间名 表名升级SSTable格式
2. 异常排查：执行refresh操作后，查看/var/log/cassandra/system.log日志，排查是否存在文件损坏、版本不兼容的报错，按报错提示针对性处理即可。

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