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