返回 登录
0

如何在MongoDB上备份和恢复数据?

在大数据时代,企业的应用带来了大量的数据,它们可能具有结构化、半结构化或非结构化的性质。此外,应用程序开发周期短和可用性强都是他们要考虑的关键问题。考虑到这些应用程序的要求,在下一代应用程序中,企业必须超越传统的关系数据库(IaaS或基于云计算PaaS)。时下,类似MongoDB这样的NoSQL数据库已经被企业采用或者评估,用以建立下一代应用程序。通过自动分片、可调的读一致性以及内置备份,MongoDB允许动态模式,并且易于扩展。

MongoDB通过本地备份来满足可用性需求。然而在此之外,用于可伸缩时点恢复和备份的数据保护需求同样需要重点对待。是的,对于企业来说,健壮的数据保护必然离不开备份和多副本。没有时间点的备份,组织会由于人为错误、逻辑混乱和其他操作失败面临有丢失数据的风险。传统的备份解决方案是建立在关系数据库中,使用共享存储和ACID事务模型,来解决结构化应用程序的要求而建的。不幸的是,他们不足以解决应用程序和分布式的数据库的时间点备份要求。有几个备用的基于脚本的解决方案(例如地层等),企业正在使用填补数据来保护缩短差距,但这些解决方案充其量算是次优的。

手动脚本解决方案

这些解决方案利用本地MongoDB快照工具和脚本将数据传输到辅助存储。(通过 mongodump) 脚本自定义的每个 MongoDB 集群和需要业务作出了重大努力,以适应任何拓扑更改 (例如添加或删除节点到 MongoDB 数据库) 或扩大规模。此外,这些脚本不适应失败场景,比如失败的一个节点(一级或二级)或间歇性的网络问题。最后,恢复(“备份”)的最重要的价值是一个手动过程。因此,耗费时间(导致很高的应用程序停机时间),并包含脚本中的任何bug数据丢失风险。总的来说,这些解决方案工作在MongoDB环境中很小和一些允许在应用程序中丢失的数据。这些解决方案所面临的一些关键问题是:

  • 对分片配置的企业备份解决方案的不足;
  • 当快照被取时,数据库需要脱机;
  • 在节点故障和其他基础设施故障下,备份和恢复都失败了;
  • 恢复过程是手动的并且需要验证,从而增加恢复时间;
  • 收集级的恢复需要耗时的手动恢复;
  • 恢复与不同的测试/开发的拓扑(切分 → 分片)刷新是不可用的。

MongoDB支付备份和恢复(又名“MMS”)

MongoDB(公司)本身提供了一些备份MongoDB数据库的方法。企业可以选择从一个管理备份提供(MMS)运行在公共云,或如果他们支付MongoDB的客户,他们可能以部署本地备份服务为前提。除了成本过高,在公共云上管理备份服务存储的客户数据。对于部署 MongoDB 为前提,在 WAN 上备份数据传输可能无法为客户工作,并且海需要为客户保持他们对数据内部的敏感度。此外,还有重要的数据来限制每个碎片去使用这项服务。

使用MongoDB部署备份服务是有可能的,但部署和实施过于复杂。企业需要部署8台服务器,附加数据库(额外的许可证)和 6-9x存储容量。总的来说,部署备份服务是一个理论上的解决方案,带来了显著的CAPEX和OPEX投资:

  1. 部署多个数据库的复杂性;
  2. 额外的基础设施成本;
  3. 授权额外的MongoDB节点成本;
  4. 当节点失败时,带来备份失败的风险;
  5. 独立的MongoDB数据库备份基础设施。

实现企业客户的数据保护要求,进入了新兴的下一代分布式数据库的时代(键值、图形、文档库等),并且解决上述方案的局限性。Datos IO建造了产业界首次扩展数据保护软件产品,使该应用程序能部署到分布式和云数据库上,如MongoDB和Apache Cassandra。Datos IO解决方案是刚刚兴起的下一代应用程序,迎合了业主和DevOps的应用需求,并解决了部署和管理保护基础设施操作所带来的一切麻烦。最重要的是,它是一个可靠的和可扩展的解决方案,即使在使用节点失败的场景下,也会通过最小化恢复时间获得最优的性能。

原文:How to Back Up and Recover Data in MongoDB

评论