在上一篇文章中，我描述了将Cassandra数据库快照作为数据备份策略的一部分所带来的一些存储放大和管理开销挑战。在这篇文章中，我将描述为什么从Cassandra快照进行恢复既麻烦又有挑战性。下面是一个Cassandra备份和恢复场景，它是由开发人员意外删除大型生产数据库中的一个重要键空间引起的。意外的键空间删除发生在今天上午8点左右，在卡桑德拉集群上拍摄的最近的快照是在昨晚10点。该快照是数据恢复（或恢复）的基础，该数据恢复或恢复是由于此错误而需要执行的。更复杂的是，在昨晚的备份之后，由于添加了两个新节点，生产Cassandra集群的拓扑结构发生了变化。添加这些节点后，令牌分布发生了变化由于拓扑结构的变化，您不能再仅仅将文件从快照目录复制到原始存储目录并执行nodetool刷新来恢复数据。您将需要重新硬化数据，以说明两个新节点和令牌映射分布的更改。这可以通过在相应的Cassandra节点上手动运行SSTableLoader实用程序来加载昨晚快照中的数据。对于每个需要恢复的表，这是一个冗长且耗时的过程。如果用户更改了表或键空间的复制属性，例如更改复制因子或策略，Cassandra数据恢复过程中会出现另一个问题。对键空间复制的任何更改都需要根据更改的属性重新硬化数据，这涉及到运行nodetool repair（手动过程）。如果您有一个大型的Cassandra集群，那么任务的数量和复杂性就复杂了。必须在群集的每个节点上执行快照还原。如果有多个表需要恢复，则操作开销将成倍增加。此外，根据恢复点或恢复时间目标的要求，不同的表可能以不同的时间间隔进行快照。这使得找到适合恢复或恢复的快照成为一个非常复杂的过程卡桑德拉快照恢复是否可行？对。容易吗？不。我们花了相当多的时间在一致性设计上，我们相信这是正确的体系结构方法来保护Cassandra数据库和其他现代数据源。阅读关于此主题的早期博客文章或Cassandra备份和恢复的一致性解决方案。