即使逐步淘汰了原有备份与负责处理相关任务的脚本，大家仍会发现各类下一代应用程序及数据库在备份与恢复方面的表现令人沮丧。然而最近GitLab由于误删导致主数据库数据丢失的事故证明，即使技术水平极高的组织机构也很难顺利处理这一难题。
【清一色.com快译】云原生应用时代下，对备份体系进行调整无疑已经成为一种必然。然而，即使逐步淘汰了原有备份与负责处理相关任务的脚本，大家仍会发现各类下一代应用程序及数据库（包括Apache Cassandra、MongoDB、Amazon DynamoDB、微软DocumentDB、Apache HBase等等）在备份与恢复方面的表现令人沮丧。为什么会这样？
简而言之：在任何拥有最终一致性特征的非关系数据库架构当中，我们几乎都不可能捕捉到具备一致性状态的备份副本。而以此为基础实现成功的数据恢复更是几近不可能。
究其原因，首先应考虑到分布式架构的基本性质。此类架构旨在扩展并抵御节点故障，尽可能降低停机机率。而在对分布式架构进行备份时，主要存在以下几项挑战：
- 数据被写入至某一可用节点。数据的***着陆点无法预测，因此无法在数据被写入节点的同时对其进行捕捉。
- 此后，数据被复制到至少一个其它节点当中，而后方进行验证。这确保了有效写入，同时亦立即为数据创建副本。
- 接下来将数据复制到更多节点中以实现可用性。这一步完成后，同一数据可快速连续进行更新。
- 意味着任意时段同一数据都至少拥有3到4套副本。
- 且各节点始终不存在即时一致性。
- 如果对各套副本进行分别备份，则效率明显极为低下。
- 而在任一节点发生故障时，其拓扑结构也将立即发生变化。
在理论上，出色的DevOps团队能够编写对应脚本，确保在80%到90%的时段内成功实现数据库备份（不过考虑到多节点故障、拓扑变更、数据库压缩等情况的存在，脚本编写难度极大）。
然而遗憾的是，备份本身只是这一议程当中较“容易”的部分。事实上，恢复才是问题的关键所在。成功的恢复机制要比大多数人想象中的复杂得多。其涉及以下具体流程：
- 重构正确拓扑。由于各个节点皆单独备份，因此数据库必须恢复到与备份时对等的拓扑状态（6节点对6节点，12节点对12节点），而其中必然涉及跨云环境、测试/开发与持续集成/持续交付等用例。
- 等待数据库进行修复与恢复。非关系数据库体系能够承受节点故障并保持正常运行，然而这种具备数据协调能力的架构在恢复方面则表现糟糕，特别是在配合低速存储驱动器的情况下。
- 重复数据删除引发多套不一致版本。备份副本可能拥有三套甚至更多处于不一致状态的全部数据副本，因此需要首先进行重复数据删除或者一致化处理。
- 数据历史并非始终可用。在大多数分布式架构当中，oplog都作为循环缓冲区存在，其会在运行当中不断覆盖自身内容。有时候，我们甚至无法恢复必要的日志数据以实现数据库协调。
- 并不具备可靠的方法以返回某时间点。即使使用oplog数据，我们仍然很难重建特定时间点数据。在最理想的情况下，大家只会获得一套时间点较近且相对精确的数据库副本。
在现实世界当中，即使数据能够得到恢复，整个周期也可能需要数天乃至数周。然而最近GitLab由于误删导致主数据库数据丢失的事故证明，即使技术水平极高的组织机构也很难顺利处理这一难题。而如果缺少可靠的备份与恢复流程，人为错误有可能与自然灾害一样对数据库产生致命影响。
【清一色译稿，合作站点转载请注明原文译者和出处为清一色.com】
©本文为清一色官方代发，观点仅代表作者本人，与清一色无关。清一色对文中陈述、观点判断保持中立，不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。本文不作为投资理财建议，请读者仅作参考，并请自行承担全部责任。文中部分文字/图片/视频/音频等来源于网络，如侵犯到著作权人的权利，请与我们联系（微信/QQ:1074760229）。转载请注明出处：清一色财经
微信扫码打赏 
支付宝扫码打赏 
