正确的 cassandra 密钥空间恢复过程

Question

我正在确认我的 Cassandra 备份和恢复过程是否正确，并且我没有遗漏任何内容。您能否确认一下，或者告诉我是否有错误/遗漏？

备份：

• 我每天通过“nodetool snapshot keyspace_name -t current_timestamp”对我关心的键空间进行完整备份。拍摄快照后，我将数据复制到已安装的磁盘上，专门用于备份，然后执行“nodetool clearsnapshot $keyspace_name -t $current_timestamp”
• 我还运行每小时增量备份 - 执行“nodetool flush keyspace_name”，然后将文件从每个键空间的备份目录移动到备份挂载点

恢复：

到目前为止，我发现进行恢复（并经过测试/确认）的唯一有效方法是在集群中的所有 Cassandra 节点上执行此操作：

1. 停止卡桑德拉
2. 清除提交日志 *.log 文件
3. 从我要恢复的表中清除 *.db 文件
4. 将快照/完整备份文件复制到该目录中
5. 复制我需要的任何增量文件（我没有测试过多个增量文件，但我假设我必须按照从最旧到最新的顺序覆盖文件）
6. 启动 Cassandra
7. 在其中一个节点上，运行“nodetool repair keyspace_name”

所以我的问题是：

1. 上述备份和恢复策略是否有效？是否有任何步骤不准确或缺少任何内容？
2. 有没有办法在不停止每个节点上的 Cassandra 的情况下做到这一点？例如，有没有办法恢复 ONE 节点上的数据，然后以某种方式使其“权威”？我试过了，正如预期的那样，由于恢复的数据较旧，其他节点（较新）上的数据在修复期间同步时会覆盖。

谢谢！

Answer 1

有两种方法可以在不重新启动 C* 的情况下恢复 Cassandra 备份：

1. 将文件复制到位，然后运行“nodetool refresh”。这有一个警告，行仍然比墓碑更老。因此，如果您尝试恢复已删除的数据，它不会做您想要的。它也仅适用于本地服务器（您需要在之后进行修复）
2. 使用“sstableloader”。这会将数据加载到所有节点。您需要确保拥有来自完整副本的 sstable，这可能意味着从多个节点加载 sstable。额外的好处，即使集群大小发生了变化，这也有效。我不确定这里的排序是否重要（也就是说，我不知道行时间戳是在加载过程中保留还是在加载过程中重新定义）