EBS的Cassandra备份

Question

目前，我正在寻找如何在Cassandra中完成备份/还原。 我们在AWS中设置了一个三节点集群。 我知道使用nodetool快照工具可以拍摄快照，但是过程有些繁琐。

我的想法是：使用EBS快照，因为它们更耐用且易于设置，但是我发现EBS的一个问题是不一致备份。 因此，我的计划是在拍摄EBS快照之前运行一个脚本，该脚本将运行flush命令以清空所有内存表数据并将其复制到磁盘（SSTable）上，然后准备带有刷新后的sstable的硬链接。 完成之后，启动EBS快照，这是我们可以解决如果仅使用EBS snapshost可能遇到的不一致问题。

如果您发现此方法有任何问题或分享您的建议，请告诉我。

Answer 1

毫无疑问，SSTables在备份方面确实提供了很多帮助。

对于集群中一切正常的情况，您的想法听起来不错。 实际上，Cassandra是一致性可配置的（如果我说最终是一致的，那么可能有人在这里冒犯了，呵呵），而且由于系统本身在给定的时间可能不完全一致，因此您不能说备份也是如此。 但是，另一方面，Cassandra（和NoSQL模型）的优点之一是它恢复得很好，这在大多数情况下都是正确的（与关系数据库相对，后者对数据丢失非常敏感） ）。 如果您至少拥有完全保留的SSTables文件，则最终不会获得一堆无用的数据。

请注意，EBS快照是块级的。 因此，当您在其上具有文件系统时，这也可能是一个问题。 幸运的是，现在任何现代文件系统都具有日志记录并且非常可靠，因此这不成问题，但是将数据放在单独的分区中是一个好习惯，因此，在完全刷新后立即有其他人在其中写入数据的可能性很大。较小。

当您最终需要还原集群时，可能会丢失一些副本，从而要求您运行nodetool repair ，如果您之前做过，那会很痛苦，并且需要大量时间来处理大量数据。 （但是，无论如何，建议定期进行修复 ，特别是如果您删除很多内容。）

需要考虑的另一件事是暗示的切换 （缺少行所有者的写入，但其他节点将保留这些写入，直到所有者返回为止）。 我不知道在刷新时它们会发生什么，但是我想它们仅保留在内存中并且仅在提交日志中。

并且，当然，请完全还原，然后再假定将来会起作用。

我在Cassandra方面经验不多，但是我听说的有关备份解决方案的地方是另一个区域或数据中心中的整个群集副本，而不是快照之类的冷备份。 与您尝试执行的原始磁盘快照相比，它可能更昂贵，但也更可靠。

Answer 2

我不确定节点的备份有什么帮助，因为在C *中，数据已经备份在副本节点中。

如果某个节点已死并且必须更换，则新节点将从其需要拥有的其他节点中了解数据，并从其他节点获取数据，因此您可能不需要从磁盘备份中还原。

像下面这样的复制方案会有所帮助吗？ 使用两个数据中心（DC：A有3个节点）（DC：B有1个节点），RF为（A：2＆B：1）。 允许客户端与DC：A中的节点进行交互，且读/写一致性为Local_QUORUM。 在这里，由于2中达到定额，所有读取和写入都将成功，并且您将在DC：B上复制数据。 现在您可以备份DC：B