迁移概览

本文档介绍了将数据库迁移到 Spanner 的过程。我们会根据您的源数据库和其他因素,介绍迁移的各个阶段以及我们为每个阶段推荐的工具。推荐的工具包括 Google Cloud 产品以及第三方商业工具和开源工具。这些工具共同帮助您加速迁移并降低风险。

任何 Spanner 迁移都涉及以下核心阶段:

  1. 评估迁移的复杂性。
  2. 迁移架构。
  3. 迁移您的应用。
  4. 测试并调整性能。
  5. 迁移数据。
  6. 验证迁移。
  7. 配置割接和故障切换机制。

下图展示了此过程:

迁移过程示意图,显示了评估、架构和应用迁移、测试和优化、数据迁移、验证和割接。

在这些阶段,您的迁移计划可能会有很大变化,具体取决于数据库来源和大小、停机时间要求、应用代码复杂性、分片架构、自定义函数或转换,以及故障切换和复制策略等因素。

我们为 Amazon DynamoDB、MySQL、Oracle 数据库和 PostgreSQL 提供迁移指南。如果要从其中某个数据库进行迁移,还请遵循相关指南:

如果要从其他数据库进行迁移,则可能需要本指南未涵盖的进一步自定义和工具。

迁移工具

我们建议您根据源数据库和其他因素,在迁移的各个阶段使用以下工具。某些工具仅支持特定的源数据库。对于该流程的某些步骤,由于没有可用的工具,因此您需要手动完成这些步骤。

  • Spanner 迁移工具是一种开源工具,可以执行基本评估以及架构和数据迁移。
  • 数据验证工具 (DVT) 是由 Google 构建并由开源社区支持的标准化数据验证方法。您可以将 DVT 集成到现有的 Google Cloud 产品中。
  • Datastream 是一项 Google Cloud 服务,可让您从源数据库读取变更数据捕获 (CDC) 事件和批量数据。
  • Dataflow 是一项 Google Cloud 服务,可帮助您使用模板更高效地将大量数据写入 Spanner。这些模板不会生成转储文件;转储文件需要由源数据库工具或第三方工具生成。

下表总结了我们针对一些常见源数据库的每个迁移阶段推荐的主要工具。您可以通过自定义内容从其他数据库进行迁移。

源数据库 评估范围 迁移架构 迁移应用 迁移数据 验证数据迁移 配置割接和故障割接
MySQL 手动 Spanner 迁移工具 手动 Spanner 迁移工具 DVT 手动
PostgreSQL 手动 Spanner 迁移工具 手动 Spanner 迁移工具 DVT 手动
其他数据库 手动 Spanner 迁移工具 手动 手动 DVT 手动

评估迁移的复杂性

如需评估迁移的范围和复杂性并规划方法,您需要收集源数据库的相关数据,包括以下内容:

  • 查询句式
  • 依赖于数据库功能(例如存储过程和触发器)的应用逻辑数量
  • 硬件要求
  • 总拥有成本 (TCO)

迁移架构

在将架构迁移到 Spanner 架构之前,请评估架构之间的兼容性,并针对 Spanner 优化架构。例如,您可能希望更改键、删除或添加索引,或添加或移除现有表中的列。如需优化 Spanner 的架构,请参阅架构设计最佳实践建议的主键迁移策略

Spanner 迁移工具是 Google 开发者创建的由社区维护的开源工具,可以根据您的源数据库架构自动构建 Spanner 架构。您可以使用 Spanner 迁移工具架构助理来自定义架构。

Spanner 迁移工具会从以下某个位置注入架构和数据:

  • 来自本地位置或 Cloud Storage 的转储文件(MySQL、PostgreSQL、CSV)
  • 直接从源数据库(MySQL、PostgreSQL)

Spanner 迁移工具执行以下功能,以执行架构评估、建议和迁移:

  • 数据类型兼容性评估和建议
  • 主键修改和建议
  • 二级索引修改和建议
  • 交错修改表格和建议
  • Spanner 架构设计建议
  • 架构版本控制
  • 协作修改架构

如需详细了解如何使用 Spanner 迁移工具进行架构迁移,请参阅 Spanner 迁移工具 README.md 文件

您还可以使用 Spanner 迁移工具进行数据迁移

迁移应用

数据库迁移需要不同的驱动程序和库,还需要针对 Spanner 不支持的功能进行补偿。为了实现类似功能并针对 Spanner 的优势进行优化,您可能需要更改代码、应用流程和架构。

以下是将应用迁移到 Spanner 所需的一些更改:

  • Spanner 不支持在数据库级别运行用户代码,因此您需要将存储在数据库级别的任何过程和触发器迁移到应用中。
  • 使用 Spanner 客户端库和对象关系映射器 (ORM)。如需了解详情,请参阅 API、客户端库和 ORM 驱动程序概览
  • 如果您需要转换查询,请手动翻译或使用其他第三方工具。
  • 记下分区 DML只读事务提交时间戳、读取时间戳以及它们可以如何优化应用性能。

您可能还需要更改交易处理。没有可用于执行此操作的工具,因此您需要手动完成此步骤。请注意以下几点:

  • 每次提交的变更限制为 40,000。表上的每个二级索引都是每行另外一项更改。如需使用变更修改数据,请参阅使用变更插入、更新和删除数据。如需修改大量数据,请使用分区 DML
  • 对于事务隔离级别,不需要处理,因为 Spanner 事务的隔离程度更高。
  • 由于 Spanner 可线性,因此默认情况下它会处理一致性和锁定。

测试和调整架构和应用性能

性能调整是一个迭代过程。在此过程中,您可以根据一部分数据评估 CPU 利用率和延迟时间等指标,调整架构和应用以提高性能,然后再次测试。

例如,在您的架构中,您可以添加或更改索引,或者更改主键。在您的应用中,您可以批量写入,也可以合并或修改查询。

特别是对于生产流量,性能调整对于帮助避免意外情况非常重要。设置越接近实时生产流量吞吐量和数据大小,性能调优越有效。

如需测试和调整架构和应用性能,请按以下步骤操作:

  1. 将部分数据上传到 Spanner 数据库。如需了解详情,请参阅迁移数据
  2. 将应用指向 Spanner。
  3. 通过检查基本流来验证正确性。
  4. 通过对您的应用执行负载测试,验证性能是否符合您的预期。如需有关识别和优化最昂贵查询的帮助,请参阅使用 Query Insights 检测查询性能问题。具体而言,以下因素可能会导致查询性能不佳:
    1. 低效查询:如需了解如何编写高效查询,请参阅 SQL 最佳实践
    2. 高 CPU 利用率:如需了解详情,请参阅调查高 CPU 利用率
    3. 锁定:如需减少因事务锁定而导致的瓶颈,请参阅识别可能导致高延迟的事务
    4. 架构设计效率低下:如果架构设计得不好,查询优化就不是很有用。
    5. 热点:Spanner 中的热点限制写入吞吐量,尤其是对于高 QPS 应用。如需找出热点或反模式,请查看 Google Cloud 控制台中的 Key Visualizer 统计信息。如需详细了解如何避免热点,请参阅选择主键以免出现热点
  5. 如果修改了架构或索引,请重复正确性和性能测试,直到获得令人满意的结果。

如需详细了解如何微调数据库性能,请与 Spanner 支持团队联系。

迁移数据

优化 Spanner 架构并迁移应用后,将数据移至生产规模的空 Spanner 数据库,然后切换到 Spanner 数据库。

根据您的源数据库,您或许可以在最短停机时间内迁移数据库,或者可能需要较长的停机时间。

如需实现最短停机时间的迁移和长时间停机的迁移,我们建议使用 DataflowSpanner 迁移工具

下表显示了停机时间最短的迁移与停机时间更长的迁移之间的差异,包括支持的来源、格式、大小和吞吐量。

尽量减少迁移时间 使用停机时间进行迁移
支持的来源 MySQL、PostgreSQL 任何可导出为 CSV 或 Avro 的数据库。
支持的数据格式 直接交流。请参阅直接连接到 MySQL 数据库 MySQL、PostgreSQL、CSV、Avro
支持的数据库大小 无限制 无限制
最大吞吐量 每小时 45 GB 每小时 200 GB

停机时间最少的迁移

Spanner 支持从 MySQL、PostgreSQL 和 Oracle 数据库进行最短停机时间的迁移。最短停机时间的迁移由两部分组成:

  • 数据库中所有数据的一致快照
  • 自创建快照以来的变更流(插入和更新),称为变更数据捕获 (CDC)

虽然最短停机时间的迁移有助于保护您的数据,但该过程会带来一些挑战,其中包括:

  • 在迁移快照时存储 CDC 数据。
  • 在捕获传入的 CDC 流时,将 CDC 数据写入 Spanner。
  • 确保将 CDC 数据迁移到 Spanner 的速度比传入 CDC 流更快。

为了管理停机时间最少的迁移,Spanner 迁移工具会为您编排以下过程:

  1. 设置一个 Cloud Storage 存储桶,以便在快照迁移过程中将 CDC 事件存储在源数据库上。
  2. 设置一个 Datastream 作业,将批量加载 CDC 数据并持续将增量 CDC 数据流式传输到 Cloud Storage 存储桶。您可以在 Spanner 迁移工具中设置来源连接配置文件。
  3. 设置 Dataflow 作业,以将 CDC 事件迁移到 Spanner。

当 Dataflow 复制完大部分数据时,它会停止向源数据库写入数据,并等待数据完成迁移。这会导致 Spanner 与源数据库同步的期间出现短暂的停机。之后,应用可以切换到 Spanner。

下图展示了此过程:

该图展示了最短停机时间的迁移过程。

有停机时间的迁移

对于 MySQL、PostgreSQL 或 Oracle 数据库以外的数据库,如果数据库可以导出到 CSV 或 Avro,则可以迁移到 Spanner,并提供停机时间。我们建议使用 DataflowSpanner 迁移工具

仅建议测试环境或可以处理数小时停机时间的应用进行有停机时间的迁移。在实时数据库中,迁移有停机时间可能会导致数据丢失。

如需执行停机迁移,请按照以下简要步骤操作:

  1. 从源数据库生成数据的转储文件。
  2. 以 MySQL、PostgreSQL、Avro 或 CSV 转储格式将转储文件上传到 Cloud Storage。
  3. 使用 Dataflow 或 Spanner 迁移工具将转储文件加载到 Spanner 中。

生成多个小型转储文件可让您更快地向 Spanner 写入数据,因为 Spanner 可以并行读取多个转储文件。

从源数据库生成转储文件时,如需生成一致的数据快照,请注意以下几点:

  • 为防止数据在转储文件生成期间发生变化,请在执行转储之前对源数据库应用读取锁。
  • 使用源数据库中的读取副本生成转储文件,并停用复制功能。

Avro 是批量迁移到 Spanner 的首选格式。如果您使用的是 Avro,请考虑以下事项:

如果您使用的是 CSV,请考虑以下事项:

  • 如需生成数据的 CSV 转储,请使用来源支持的 CSV 生成功能。如果数据包含换行符,请使用自定义行分隔符。
  • 如需导入 CSV 数据,请使用 Dataflow 导入作业。您可以创建自己的 Dataflow 导入模板,也可以使用 Google Cloud 导入模板。如需了解详情,请参阅 Dataflow 数据流水线模板

如果您使用的是 MySQL 或 PostgreSQL,则可以使用 Spanner 迁移工具。

如需了解如何使用自定义脚本将数据加载到 Spanner 中,请参阅批量加载的性能准则

验证数据迁移

数据验证是比较源表和目标表中的数据以确保它们匹配的过程。

数据验证工具 (DVT) 是一种开源工具,可以连接到数据存储区并在来源与 Spanner 之间执行检查。我们建议您在迁移过程中用它执行基本验证,例如:

  • 检查所有表是否均已创建,以及所有架构映射是否都正确无误。
  • 匹配每个表的行数。
  • 提取随机行以验证正确性。
  • 验证您的列(countsumavgminmaxgroup by)。
  • 在行级别比较所有循环冗余校验或哈希函数。

如需执行更具体的验证,请在迁移期间构建自定义检查。

配置割接和故障切换机制

迁移通常既耗时又复杂。构建回退机制,以免在迁移过程中发生错误时产生重大影响,从而在最短停机时间内切换回源数据库。

当前建议使用变更数据流执行反向复制,并通过 Pub/Sub 或 Cloud Storage 等数据流写回源数据库。

显示割接过程的示意图。

反向复制需要执行以下操作:

  • 处理数据类型或内容的变化。
  • 逆转迁移期间执行的任何转换。
  • 将数据推送到适当的目标位置,并考虑源上的分片方案。