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