我正在确认我的 Cassandra 备份和恢复程序是健全的，我没有遗漏任何东西。您能否确认或告诉我是否有错误/遗漏？
备份 :
我通过“nodetool snapshot keyspace_name -t current_timestamp”每天运行我关心的 key 空间的完整备份。拍摄快照后，我将数据复制到专用于备份的已安装磁盘，然后执行“nodetool clearsnapshot $keyspace_name -t $current_timestamp”我还运行每小时增量备份 - 执行“nodetool flush keyspace_name”，然后将文件从每个 key 空间的备份目录移动到备份挂载点 恢复 :
到目前为止，我发现进行恢复(并测试/确认)的唯一有效方法是在集群中的所有 Cassandra 节点上执行此操作:
停止 Cassandra 清除 commitlog *.log 文件 清除我要恢复的表中的 *.db 文件 将快照/完整备份文件复制到该目录 复制我需要的任何增量文件(我没有用多个增量进行测试，但我假设我必须按从最旧到最新的顺序覆盖文件)启动 Cassandra 在其中一个节点上，运行“nodetool repair keyspace_name”所以我的问题是:
上面的备份和恢复策略看起来有效吗？是否有任何步骤不准确或遗漏了什么？ 有没有办法在不停止每个节点上的 Cassandra 的情况下做到这一点？例如，有没有办法恢复ONE节点上的数据，然后以某种方式使其“具有权威性”？我尝试了这个，并且正如预期的那样，由于恢复的数据较旧，其他节点(较新)上的数据在修复期间同步时会覆盖。 谢谢!
有两种方法可以在不重启 C* 的情况下恢复 Cassandra 备份:
将文件复制到位，然后运行“nodetool refresh”。这有一个警告，即行仍然比墓碑更旧。因此，如果您尝试恢复已删除的数据，它不会执行您想要的操作。它也仅适用于本地服务器(之后您需要修复)使用“sstableloader”。这会将数据加载到所有节点。您需要确保拥有完整副本中的 sstables，这可能意味着从多个节点加载 sstables。额外的好处是，即使集群大小发生了变化，这也有效。我不确定这里的排序是否重要(也就是说，我不知道行时间戳是通过加载保留还是在加载期间重新定义)