本文比较了不同的异地冗余备份解决方案,并解释了为什么云服务是最佳选择。
异地冗余是一种灾难恢复实践,可在地理分布的数据中心备份数据。这种方法可以防止发生事故并保证业务连续性。对于数据库系统来说,异地冗余主要有两种方式:冷(离线)备份和热(在线)备份。冷备份使用更广泛,因为它更便宜并且对在线性能的影响更小。
然而,构建一个经济高效、可扩展的冷备份解决方案并不容易。在可扩展性、运营和成本方面可能存在挑战。在本文中,我将针对这些挑战提供一个解决方案:使用云存储服务的异地冗余备份。
异地容灾冷备挑战
首先,让我们看看最常用的冷备份解决方案的局限性。
数据库内置备份 功能
数据库通常附带冷备份功能。他们要么提供将数据转储到本地存储或将数据上传到远程存储服务的工具。对于数据库,异地冗余备份与单一目标备份没有太大区别。您只需添加更多的远程存储目的地。

但是,在备份期间转储数据会占用大量带宽。您指定的目的地越多,消耗的带宽就越多。这可能会显着影响数据库性能。在最坏的情况下,转储数据可能会耗尽大部分带宽,并且数据库会停止响应查询。因此,使用内置数据库功能的地理冗余可能不是可扩展的解决方案。
数据库异地冗余 + 消息队列
使用消息队列 (MQ) 可以解决此带宽问题。MQ 是一种用于异步进程间通信的机制,被广泛接受为一种节省带宽的解决方案——尤其是当并发数据限制您的网络时。您可以在数据库实例和远程存储之间放置一个 MQ 服务。
MQ 让您可以将数据分发到多个目的地,以实现大规模的异地冗余备份。对数据库性能的影响将与单目标备份相同。如果 MQ 达到其性能瓶颈,您可以向链中添加更多实例。

使用 MQ 的数据库异地冗余。
MQ 解决方案听起来不错,但还有其他问题需要解决。让我们看一下使用 MQ 解决方案进行异地冗余的步骤:
- 将目标数据分解为消息队列负载。
- 将数据提供给 MQ 实例。
- 从 MQ 实例读取数据。
- 将负载组合成逻辑备份数据。
- 将数据发送到远程存储服务。
如您所见,您必须开发上下游数据适配组件并托管 MQ 实例。这会增加您的运营和维护成本,并且需要额外的领域专业知识。
有更简单、更便宜的解决方案吗?
基于上述解决方案及其面临的挑战,我们的要求很明确:我们需要一个可扩展、简单且成本较低的异地冗余解决方案。这自然会引导我们使用云服务,它具有更低的总拥有成本、更简单的架构和更容易的维护。一种选择是完全托管的 MQ 服务。它可以通过云上的可扩展服务将您从 MQ 处理过程中解放出来,但这只是问题的一部分。您仍然需要开发上下游适配组件。其实我们需要的是一个Storage as a Service,或者更准确的说,Cross Region Replication as a Service(CRRaaS)解决方案。使用 CRRaaS,您可以将数据存储在一个区域并自动将其复制到其他区域。

比较 流行的 C loud 解决方案:S3 和 GCS
让我们来看看云供应商使用最广泛的对象存储服务:亚马逊简单存储服务(S3)和 谷歌云存储(GCS)。他们都有跨区域复制的选项。此外,大多数数据库都支持将数据备份到托管存储服务,因此您不需要任何数据适配组件。在本节中,我们将比较 S3 和 GCS,看看它们是否可以满足我们的异地冗余备份目标。
S3
S3 复制服务包括跨区域复制。您可以在启用 版本控制的两个存储桶之间定义复制规则。Amazon S3 异地冗余复制如下所示:

一个 Amazon Web Service (AWS) 帐户最多只能支持 1,000 个存储桶。因此,当过多的数据库实例需要异地冗余备份时,您必须在数据库实例之间定义共享桶。此外,S3 允许您在存储桶上设置生命周期配置以保留数据以控制成本。

Amazon S3 上的共享存储桶。
全球控制系统
GCS 不是让用户定义存储桶之间的复制规则,而是提供三种 存储桶位置类型:单区域、双区域和多区域。您可以选择双区域或多区域存储桶来获得跨区域复制。

但是,您只能将双区域存储桶扩展到两个备份目的地。要实现跨两个以上目的地的地理冗余,您必须选择多区域存储桶。
比较
S3和GCS从CRRaaS的角度来看都符合我们的要求,并且各有其独特的属性。此表比较了两种解决方案。
| 地理冗余选项 | S3复制 | GCS 双区域 | GCS 多区域 |
| 服务水平协议 | 15分钟内99.99% | 15 分钟内 99.9%(turbo 复制模式) | 60分钟内99.9% |
| 操作负担 | 监控复制性能 管理复制和生命周期规则 | 监控复制性能 | 监控复制性能 |
| 可扩展性/容错性 | 轻松扩展到任意数量的区域 可以抵抗 N-1 个区域的故障 | 数据分布在两个固定区域 可以抵抗一个区域故障 | 数据分布在同一大陆的两个或多个区域 可以抵抗多个区域的故障 |
| 访问延迟 | 如果您从同一区域访问数据,则延迟低 | 如果您从同一区域访问数据,则延迟低 | 不可预测,因为数据可能不会存储在所有区域,这对用户来说是不可见的。 |
S3 和 GCS 是托管存储服务,因此开发人员不必托管复制基础设施。在您做出选择之前,需要考虑以下几点:
- 服务质量。S3 支持可在不到 15 分钟内复制 99.99% 的新数据对象的服务水平协议 (SLA)。但是GCS对于多区域模式只保证在60分钟内同步99.9%的新写入对象。如果您的系统需要高恢复点目标 (RPO),S3 应该是您的选择。
- 易于操作。GCS 使用起来更直观,选择桶位置类型也很简单。其多区域存储桶大大简化了异地冗余操作。使用Amazon S3,需要配置复制和生命周期规则,操作比较复杂。
- 容错定制。S3 允许您选择要复制的目标区域的数量和位置。相比之下,GCS 提供的是固定选项,容错能力对用户来说是不可见的。如果你的系统对故障恢复能力要求高且可控,你应该考虑S3。对于不需要该级别功能的系统,双区域存储桶就足够了。
- 访问延迟。S3 和 GCS 双区域存储桶都具有可预见的低延迟,因为用户知道哪个区域具有完整的数据副本。但是对于GCS多区域bucket是不可预测的,因为它不保证一个大陆的所有区域都能访问到完整的数据副本。
如果系统需要相对较高的 RPO、可预测的延迟和单区域故障的容错能力,那么 GCS 双区域存储桶可能是一个不错的选择。如果您更喜欢简单性和更高的区域故障可恢复性,GCS 多区域存储桶也是一个不错的选择。但是,如果您对 RPO、容错和访问延迟有非常高的要求——并且您希望更好地控制它们——请使用 S3。
概括
与传统系统相比,使用云服务为数据库开发异地冗余冷备份要容易得多。但是,Amazon S3 或 GCS 等 CRRaaS 解决方案并不能解决您的所有问题。您仍然必须将您的系统与云平台集成。如果您想要一个完整的包,那么您可能需要考虑数据库即服务选项。
原文标题:Simplify Database Geo-Redundancy Backup With Cloud Storage Services
原文作者:Yuanrui Cai
原文链接:https://dzone.com/articles/simplify-database-geo-redundancy-backup-with-cloud




