目前我正在研究如何在Cassandra中完成备份/恢复。我们在AWS中设置了一个三节点集群。我知道使用nodetool快照工具我们可以拍摄快照，但这有点麻烦。
我的想法是： 利用EBS快照，因为它们更耐用且易于设置，但我在EBS中看到的一个问题是备份不一致。因此，我的计划是在获取EBS快照之前运行脚本，该快照只运行flush命令以清除所有可记录数据并将其复制到磁盘（SSTable），然后使用刷新的sstables准备硬链接。 一旦完成，启动EBS快照，我们就可以解决如果我们只使用EBS snapshost而可能遇到的不一致问题。
如果您发现此方法存在任何问题或分享您的建议，请与我们联系。
答案 0 :(得分：0)
不可变，SSTables在备份时确实提供了很多帮助。
对于群集中一切正常的情况，您的ideia听起来不错。实际上，Cassandra是一致性可配置的（如果我说最终一致，有些人可能会被冒犯，呵呵），并且由于系统本身在给定时间可能不完全一致，你不能说你的备份也是如此。但是，另一方面，Cassandra（和NoSQL模型）的优点之一是它往往恢复得很好，在大多数情况下对于Cassandra都是如此（与关系数据库完全相反，关系数据库对数据丢失非常敏感）。如果您至少完全保留了SSTables文件，那么您最不可能得到大量无用的数据。
请注意，EBS快照是块级的。因此，当您拥有一个文件系统时，它也可能是一个问题。幸运的是，现在任何现代文件系统都具有日志功能并且相当可靠，因此不应该成为问题，但将数据放在单独的分区中是一种很好的做法，因此其他人在完整后立即写入其中的机会很可能冲洗较小。
当您最终需要恢复群集时，可能会丢失一些副本，要求您运行 nodetool repair ，如果您以前做过什么，那会有点痛苦并且需要很长时间才能完成数据量。 （但是，建议定期运行 repair ，特别是如果你删除了很多。）
要考虑的另一件事是提示切换（写入行所有者丢失，但由其他节点保留，直到所有者回来）。我不知道你刷新时会发生什么，但我猜他们只是保留在内存和提交日志中。
而且，当然，在你认为将来会有效之前，请进行完全恢复。
我对Cassandra没有丰富的经验，但我所听说的备份解决方案是在另一个地区或数据中心的整个群集副本，而不是像快照这样的冷备份。它可能比您尝试的原始磁盘快照更昂贵但更可靠。
答案 1 :(得分：0)
我不确定节点的备份如何帮助，因为在C *数据中已经备份了副本节点。
如果一个节点已经死亡且必须更换，新节点将从其他节点了解其需要拥有的数据并从其他节点获取数据，因此您可能不需要从磁盘备份进行恢复。 / p>
以下复制方案会有所帮助吗？ 使用两个数据中心（DC：A，3个节点）（DC：B，一个节点），RF为（A：2＆amp; B：1）。允许客户端与DC：A中的节点进行交互，其读/写一致性为Local_QUORUM。这里因为2中的仲裁所有读取和写入都会成功，您将在DC：B上复制数据。现在你可以备份DC：B