我们为何很难对超大规模应用与分布式架构进行备份？

云原生应用时代下，对备份体系进行调整无疑已经成为一种必然。然而，即使逐步淘汰了原有备份与负责处理相关任务的脚本，大家仍会发现各类下一代应用程序及数据库（包括Apache Cassandra、MongoDB、Amazon DynamoDB、微软DocumentDB、Apache HBase等等）在备份与恢复方面的表现令人沮丧。为什么会这样？

成都创新互联公司2013年开创至今，是专业互联网技术服务公司，拥有项目成都做网站、网站建设、外贸营销网站建设网站策划，项目实施与项目整合能力。我们以让每一个梦想脱颖而出为使命，1280元调兵山做网站,已为上家服务,为调兵山各地企业和个人服务,联系电话:18980820575

简而言之：在任何拥有最终一致性特征的非关系数据库架构当中，我们几乎都不可能捕捉到具备一致性状态的备份副本。而以此为基础实现成功的数据恢复更是几近不可能。

究其原因，首先应考虑到分布式架构的基本性质。此类架构旨在扩展并抵御节点故障，尽可能降低停机机率。而在对分布式架构进行备份时，主要存在以下几项挑战：

• 数据被写入至某一可用节点。数据的***着陆点无法预测，因此无法在数据被写入节点的同时对其进行捕捉。
• 此后，数据被复制到至少一个其它节点当中，而后方进行验证。这确保了有效写入，同时亦立即为数据创建副本。
• 接下来将数据复制到更多节点中以实现可用性。这一步完成后，同一数据可快速连续进行更新。
• 意味着任意时段同一数据都至少拥有3到4套副本。
• 且各节点始终不存在即时一致性。
• 如果对各套副本进行分别备份，则效率明显极为低下。
• 而在任一节点发生故障时，其拓扑结构也将立即发生变化。

在理论上，出色的DevOps团队能够编写对应脚本，确保在80%到90%的时段内成功实现数据库备份（不过考虑到多节点故障、拓扑变更、数据库压缩等情况的存在，脚本编写难度极大）。

然而遗憾的是，备份本身只是这一议程当中较“容易”的部分。事实上，恢复才是问题的关键所在。成功的恢复机制要比大多数人想象中的复杂得多。其涉及以下具体流程：

• 重构正确拓扑。由于各个节点皆单独备份，因此数据库必须恢复到与备份时对等的拓扑状态（6节点对6节点，12节点对12节点），而其中必然涉及跨云环境、测试/开发与持续集成/持续交付等用例。
• 等待数据库进行修复与恢复。非关系数据库体系能够承受节点故障并保持正常运行，然而这种具备数据协调能力的架构在恢复方面则表现糟糕，特别是在配合低速存储驱动器的情况下。
• 重复数据删除引发多套不一致版本。备份副本可能拥有三套甚至更多处于不一致状态的全部数据副本，因此需要首先进行重复数据删除或者一致化处理。
• 数据历史并非始终可用。在大多数分布式架构当中，oplog都作为循环缓冲区存在，其会在运行当中不断覆盖自身内容。有时候，我们甚至无法恢复必要的日志数据以实现数据库协调。
• 并不具备可靠的方法以返回某时间点。即使使用oplog数据，我们仍然很难重建特定时间点数据。在最理想的情况下，大家只会获得一套时间点较近且相对精确的数据库副本。

在现实世界当中，即使数据能够得到恢复，整个周期也可能需要数天乃至数周。然而最近GitLab由于误删导致主数据库数据丢失的事故证明，即使技术水平极高的组织机构也很难顺利处理这一难题。而如果缺少可靠的备份与恢复流程，人为错误有可能与自然灾害一样对数据库产生致命影响。

【译稿，合作站点转载请注明原文译者和出处为.com】

分享题目：我们为何很难对超大规模应用与分布式架构进行备份？
地址分享：http://www.csdahua.cn/qtweb/news21/2471.html

网站建设、网络推广公司-快上网，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 快上网