使用 Striim 设计数据库迁移和复制架构

本文档介绍如何使用 Striim 设计数据库迁移和复制架构。本文档重点介绍与数据库迁移和持续复制相关的架构概念,适用于数据库架构师和数据库工程师,以及计划将数据源迁移或复制到 Google Cloud 的数据所有者。

数据库迁移和复制简介

许多企业使用基于云的服务和技术来构建业务应用,以追求云优先应用策略。企业通过缩短服务的上市时间以及快速响应客户需求和市场状况的变化来进行竞争。能够从端到端充分利用云计算的业务应用对于持续的业务增长至关重要。

旧版的任务关键型应用为云端迁移带来了一些挑战,包括迁移应用层、迁移底层数据库以及在迁移过程中保证用户对应用的访问不中断。

许多迁移产品和服务可帮助您迁移业务应用层级,但迁移为业务应用提供服务的底层数据库通常是最困难的任务。

在实践中,将数据库迁移到云端有几种不同的形式。下图展示了最基本的用例,即将本地数据库迁移到云端数据库(在此示例中为 Cloud Spanner)。

从源数据库到 Cloud Spanner 的基本迁移的架构。

下图展示了一个更复杂的用例,即迁移多个数据库并对应用进行现代化改造

使用数据库迁移系统的复杂迁移的架构,涉及多个源数据库和目标数据库。

在此设置中,两个源数据库迁移到两个目标数据库。其中一个源数据库由一个应用访问,该应用以现代化改造后的形式(在 Google Kubernetes Engine 上实现)访问相应的目标数据库。第二个源数据库也有客户端(图中未显示)。

虽然在上图中数据库迁移系统安装在 Google Cloud 上,但迁移系统也可以安装在其他位置。例如,出于安全原因,迁移系统可能需要在与源数据库相同的位置运行。

直接原样迁移和在线数据库迁移

概括来讲,数据库迁移的两种方法是直接原样迁移和在线迁移。

在直接原样迁移中,您通常需要导出或备份源数据库,将导出或备份的文件迁移到云端,然后将文件导入并恢复到在云端运行的目标数据库实例。新的目标数据库准备就绪后,业务应用将在云端运行并访问数据。

直接原样迁移方法的缺点是业务应用和数据库都需要停机。这种方法要求您进行仔细规划,以便在活动程度较低的时段进行迁移。此方法还假设您可以在迁移过程中停止业务应用,并在云端恢复数据库后重启应用。数据库恢复后进行的任何应用测试都会增加停机时间。此外,直接原样迁移方法会创建数据库的中间副本,您需要保护、迁移、存储并最终删除该副本。这会增加费用和管理复杂性。虽然直接原样迁移可能适用于某些应用,但大多数业务关键型应用的要求无法承受这些费用。出于这些原因,在线数据库迁移是更好的方法。

在线迁移方法旨在最大限度地降低对数据库性能和业务应用的用户的影响。利用在线方法,您可以将数据库持续迁移到云端并使源数据库和目标数据库在数月(甚至数年)的时间内保持完全同步,与此同时,您可以针对新的云端数据库优化和测试业务应用。

数据库迁移与数据库复制

数据库的云端迁移完成后,源数据库将停用,这是因为此时云端数据库是生产实例。

在某些用例中,原始数据库实例可能会继续运行,并在 Google Cloud 上进行下游处理。在本例中,源数据库会复制到 Google Cloud。例如,您可能有一个应用需要访问一个数据库,而该数据库依赖的技术无法迁移到 Google Cloud。同时,Google Cloud 技术用于分析等功能,例如复制到 BigQuery。另一个例子是,包含个人身份信息 (PII) 的数据库必须位于本地环境中,而使用经过混淆处理的 PII 信息的下游处理则在 Google Cloud 中进行。

在这些用例中,必须持续将原始数据库复制到操作或分析目标(例如 Spanner 或 BigQuery)。源数据库不会关停,因为数据库迁移正在进行。

异构数据库的在线数据库迁移和复制通常较为复杂,涉及手动编码和集成各种服务,时间可能长达数月甚至数年。一种现代且高效的在线数据库迁移方法是使用数据库迁移和集成系统,例如 Striim

下图展示了 Striim 数据集成和智能平台的基本部署架构,其中包含一个来源数据库和一个目标数据库。

使用 Striim 进行基本迁移的架构。

使用 Striim 迁移和复制数据库

Striim 是提供数据库迁移技术的 Google 技术合作伙伴,它使用拖放式界面在异构数据库之间设置持续数据迁移,从而简化了在线迁移。针对迁移到 Google Cloud 的任务,Striim 提供无干扰的流式提取、转换和加载 (ETL) 平台,与其他解决方案相比,这个平台部署更快,迭代更轻松。

通过无干扰的捕获变更数据 (CDC),Striim 可以在不降低源事务型数据库速度的情况下提取实时数据,从而实现零停机时间和最小风险的云数据库迁移。当数据在传输中,Striim 可以使用一个全面的流式分析引擎,通过 SQL 查询过滤、转换、汇总和丰富数据。

通过持续在本地和 Google Cloud 数据库之间复制数据,Striim 支持在线复制,从而使任务关键型应用可以继续运行,无需停机。通过内置的持续交付验证、高可用性和故障转移功能,Striim 还可最大限度地降低数据丢失的风险。

数据库迁移和复制的用例

在线数据库迁移和持续复制可以应用于一些行业特定问题以及技术性(与行业无关)问题。例如,行业特定用途可能是使用云端数据服务和实时数据的金融服务。更偏技术性的用例可能是报告数据库的迁移或运营数据库的分阶段迁移。通过提供可在正确的时间以正确的格式传送数据的持续数据流水线,Striim 能够支持这些用例。

本部分讨论如何使用 Striim 针对一个行业特定的用例和两个技术用例迁移数据库。

金融技术

金融技术公司需要快速且准确的数据。例如,银行客户希望立即查看账户中的交易和余额。借款方和贷款方想要节省贷款发放的时间。金融技术公司可以使用 Striim 来满足诸如此类的许多业务需求。

考虑一个可加快贷款发放速度的自动化员工和收入验证服务。在此用例中,Striim 将来自各个本地来源的实时数据集成到 Google Cloud 中。这一自动化流程可减少工作验证流程中的延迟。下图展示了此用例的架构。

使用 Striim 将数据流式传输到 Google Cloud 的金融技术用例。

此架构利用了 Striim 的实时流式数据集成。Striim 不断从各种外部来源和内部来源收集数据,例如,从 ADP 等处理方收集工资数据,从其他提供商收集员工数据和人口统计数据。然后,Striim 将数据提供给各种 Google Cloud 服务。Striim 使用基于日志的 CDC 从关系数据库中持续提取数据,访问 Oracle® GoldenGate 跟踪记录文件(如适用),甚至从平面文件提取数据。Striim 将汇总和转换后的数据持续提供给 Cloud Storage,为针对云端构建的业务应用和服务提供支持。

分流报告

对于某些技术用例,事务型工作负载和分析工作负载是有区别的。由于源事务型数据库上的性能损失和返回分析查询的延迟时间不断增加,在事务型数据库上运行分析查询是不明智的。

为应对这种差异,您可能需要持续向 Google Cloud 提供一部分事务数据,以便在 BigQuery 中运行进一步的分析和报告。下图展示了一个示例架构。

在事务型数据库和分析数据库之间拆分工作负载的架构。

Striim 能够对流式数据流水线中的数据进行转换和规范化,因此 Striim 可以将选定的部分源事务数据整合到分析平台中,同时将剩余数据持续迁移到一个或多个 Google Cloud 数据目标。

分阶段迁移

大型企业拥有庞大的本地数据库,其中保存着数年的宝贵数据。将这些数据库迁移到云端是一项可能需要花费数年时间的大规模工作。但保留旧数据库也有代价,例如,错失 Cloud BigQuery、Cloud Spanner 和 Pub/Sub 等新的云数据库技术带来的机会。

如需在维护旧版系统和利用最新的云数据库技术之间取得平衡,您可以使用 Striim 通过分阶段的方法将一部分数据迁移到 Google Cloud 数据库,同时仍保持源生产数据库的运行。从小规模数据开始迁移,这样您的开发者还可以在新的云数据库中测试应用层,而不会影响本地生产数据库。

在确保应用层兼容后,您可以缓慢地增加迁移的数据量,直到完成整个数据库的迁移。通过这种迁移,您能够管理风险并在迁移生产系统时将停机时间降至最低。

部署架构

本部分中的部署架构展示了数据库迁移和复制的各种用例涉及的各种数据库、应用和云服务。

基本部署架构

下图展示了一个简单的部署架构:源数据库系统迁移到云端数据库系统 Cloud Spanner。本文档中一直使用此架构,它可用于持续复制和完整或分阶段迁移。

使用 Striim 进行基本迁移的架构。

在此架构中,源数据库系统迁移到云端数据库系统,在本例中为 Cloud Spanner。数据库迁移系统 Striim 连接到这两个系统,并将数据从源数据库迁移到目标数据库系统。

中等复杂度的部署架构

下图展示了涉及两个源数据库系统的架构。此架构比上面的架构更加复杂,可用于数据库迁移和数据库复制。

从本地和云端源数据库迁移到事务型和分析目标数据库。

该图显示了有两个源数据库系统的初始架构。一个源数据库是运行在公有云环境中,需要迁移的数据库系统 (S1)。第二个源数据库是在本地数据中心内运行的数据库系统 (S2),这个数据库继续在本地运行,但其数据及后续更改将被复制到 BigQuery 进行分析。部署了两个目标数据库系统:接收 S1(迁移)数据的 Cloud Spanner,以及接收来自 S2 的连续数据流的 BigQuery。

下图显示了数据库迁移完成后的部署架构。S1 已终止运行,相应的 Cloud Spanner 目标不再连接到 Striim。

完成迁移后的架构,其中事务型数据库与 Striim 断开连接。

此场景表明部署架构不一定是静态的。某些用例(如一次性数据库迁移)要求迁移系统连接到系统或服务,直到迁移完成。其他用例更为静态,例如数据库复制。此架构展示了单个架构如何处理多个用例。

复杂的部署架构

本部分介绍设计为回退的迁移。如果迁移后发生了错误,需要您返回源数据库进行处理,那么回退是必要的。回退设置可确保在进行反向迁移时,目标数据库中的更改会传回给源数据库。

此部署架构涉及复制和迁移,是本文档讨论的三个架构中最复杂的一个。

此架构还展示了 Striim 如何在集群环境中运行,以支持增加的吞吐量。以下架构中的集群由三个 Compute Engine 实例组成,以便提供足够的容量。每个 Compute Engine 实例都位于不同的地区,可针对地区性故障和实例故障提供高可用性。

在本例中,位于本地数据中心的两个源数据库会复制到云端。一个数据库复制到 Cloud Spanner,另一个复制到 BigQuery。此外,迁移会将数据从公共云中的数据库迁移到 Cloud SQL 实例。

下图展示了迁移完成之前的部署架构。

使用 Striim 迁移系统的多个源数据库和目标数据库的架构。

三个源数据库连接到 Striim,Striim 会将数据迁移并复制到三个目标数据库。本地数据中心中的两个源数据库会复制到 BigQuery 和 Cloud Spanner,云端的源数据库会迁移到 Cloud SQL。

迁移完成后,我们将数据流方向反转为从 Cloud SQL 到云端数据库,以便为可能的回退进行准备。为了确保目标数据库上的所有更改在源数据库上也可用,必须在原始迁移后设置反向迁移。

下图显示了为潜在的回退进行的配置变更。

使用 Striim 迁移系统回退到源数据库的架构。

将数据流的方向在原始源云数据库和 Cloud SQL 之间反转。迁移完成并且排除回退的需要后,迁移中的相关系统(包括 Cloud SQL 和本地数据中心的源数据库)将断开连接。

下图展示了此部署架构如何支持持续复制用例。

使用 Striim 从两个本地源数据库到多个目标数据库的持续复制架构。

本地数据中心中的两个源数据库持续复制到 BigQuery 和 Cloud Spanner。

如本讨论所示,此部署架构可支持各种复杂度的用例。您也可以动态更改配置,例如,当数据移动方向被反转时。

此架构还可进行扩容,以支持增加的负载或峰值。

部署架构的复杂度与迁移规范

在上述架构中,复杂程度包括两个维度:

  • 连接到 Striim 的数据库系统的数量
  • 用例完成后,部署架构随时间发生的变化

您也可以根据迁移规范衡量复杂度,而无需考虑部署架构。

例如,如果本地 MySQL 数据库迁移到云端的 MySQL 数据库,并且架构和数据相同,则迁移规范非常简单明了,因为规范是副本。但是,如果从 Oracle 数据库迁移到 Cloud Spanner 数据库,迁移复杂度会显著增加,因为源架构和目标架构不同,并且数据必须在迁移过程中进行转换。

下表提供了确定迁移规范复杂度的概要方法。将特性与迁移或复制复杂度指标一并列出。您可以使用标题为您的用例的列来评估您的要求。

功能 相似 不同 您的用例
源和目标数据库系统 低复杂度 高复杂度
源和目标数据库架构 低复杂度 高复杂度
源和目标数据库数据 低复杂度 高复杂度
数据分区(如果存在) 低复杂度 高复杂度
数据隔离或合并 高复杂度 高复杂度

迁移的复杂度是一段范围,具体取决于要实现的用例。对于您的用例,您可以根据用例特性低复杂度和高复杂度的比率来确定整体的复杂度。

在确定复杂度时,其他考虑因素也可能会有用,尤其是在高级用例中。例如:

  • 多个源数据库会合并到一个目标数据库中吗?
  • 来自多个源数据库的数据是否会被重新分布到一组目标数据库中(例如重新分片或重新分区)?
  • 迁移过程中数据是否会被丰富或精简,以在目标系统中提供精心挑选的数据集?

您添加到用例中的每项特性都会增加复杂度,而 Striim 这样的系统正是为支持这样的架构而建。

后续步骤