Cassandra快照恢复后重启或执行nodetool repair数据归零求助

可能原因 #

• 复制策略与副本因子不匹配：原集群A与目标集群B的键空间复制策略、副本因子（RF）不一致。例如集群A采用SimpleStrategy且RF=3，集群B却配置了不同的RF或策略，修复时集群会依据当前配置重新同步数据，空节点的数据会覆盖已恢复的快照数据。
• 快照文件权限错误：快照复制到集群B的数据目录后，文件/目录的所属用户/组并非Cassandra运行用户（通常为cassandra:cassandra），导致Cassandra进程无法读取快照数据，重启后这些无效数据会被自动清理。
• 表结构不一致：重建键空间和表时，与原集群的表结构存在差异（如主键定义、列类型、压缩/TTL配置、表属性等），快照数据无法被正确解析，Repair过程中会被判定为无效数据删除。
• 令牌范围分配不匹配：集群B的节点令牌范围与原集群A不同，恢复的快照数据不在当前节点的负责范围内，Repair时会清理不属于本地令牌的数据，同时其他节点也无对应有效数据，最终导致全集群数据丢失。
• 过早执行Repair操作：节点未完全加载快照数据就执行nodetool repair，此时集群中部分节点数据为空，Repair会以“最新”的空数据为基准，覆盖已恢复的快照数据。

解决建议 #

• 严格对齐复制策略与副本因子：从原集群执行DESCRIBE KEYSPACE <keyspace_name>导出键空间配置，在集群B直接执行该配置语句，确保复制策略、副本因子、数据中心配置与原集群完全一致。
• 修复快照文件权限：复制快照后，执行以下命令修改权限：

  chown -R cassandra:cassandra /var/lib/cassandra/data/<keyspace_name>/<table_name>-*
  

  确保Cassandra进程对快照数据拥有读写权限。
• 保证表结构完全一致：从原集群导出表的完整定义（DESCRIBE TABLE <keyspace_name>.<table_name>），在集群B执行该DDL语句重建表，避免手动创建导致的结构差异。
• 对齐集群令牌配置：若原集群使用自定义令牌，集群B节点需配置相同的令牌范围；若使用虚拟节点（vnodes），确保集群B的vnodes数量与原集群一致，恢复前同步令牌分配。
• 调整恢复流程：
  1. 停止集群B所有节点的Cassandra服务
  2. 在每个节点重建对应键空间和表
  3. 将对应节点的快照文件复制到数据目录，修复权限
  4. 逐个启动节点（禁止同时启动），启动后执行nodetool refresh加载快照数据
  5. 待所有节点启动完成，nodetool status显示全节点正常后，再执行nodetool repair --local先修复本地数据，之后进行全集群修复
• 先验证数据再执行Repair：启动节点后，通过cqlsh查询少量数据确认快照已加载，再执行Repair操作，避免过早触发数据同步覆盖。

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