本文档介绍了将数据库迁移到 Spanner。我们将介绍迁移的各个阶段，以及我们为每个阶段推荐的工具（具体取决于您的源数据库和其他因素）。推荐的工具包括 Google Cloud 产品以及第三方商用和开源工具。结合使用这些工具， 迁移并降低风险
任何 Spanner 迁移都涉及以下核心阶段：
- 评估迁移的复杂性。
- 迁移您的架构。
- 加载示例数据。
- 迁移您的应用。
- 测试并优化您的广告效果。
- 迁移数据。
- 验证迁移。
- 配置切换和故障切换机制。
在这些阶段，您的迁移计划可能会有很大差异，具体取决于因素 例如数据库来源和大小、停机时间要求、应用代码 分片架构、自定义函数或转换以及故障切换 和复制策略
迁移工具
我们建议您使用以下工具来协助您完成测试的各个阶段 具体取决于源数据库和其他因素。仅限部分工具 支持某些源数据库。对于流程中的某些步骤 因此您需要手动完成这些步骤。
Spanner 迁移工具 (SMT) 是一款开源工具，可执行基本评估、架构转换和数据迁移。
数据库迁移评估 (DMA) 提供将 PostgreSQL 迁移到 Spanner 的基本评估。
Datastream 是一项 Google Cloud 服务，可让您从源数据库读取变更数据捕获 (CDC) 事件和批量数据，并将其写入指定的目的地。
Dataflow 是一项 Google Cloud 服务， 可帮助您更频繁地向 Spanner 写入大量数据 高效地使用模板
批量数据迁移是一个 Dataflow 模板，可让您将大型 MySQL 数据集直接迁移到 Spanner。
最短停机时间迁移使用 Datastream 和 Dataflow 进行迁移：
- 源数据库中的现有数据。
- 迁移过程中对源数据库进行的更改流。
数据验证工具 (DVT) 是由 Google 开发的一种标准化数据验证方法， 开源社区。您可以将 DVT 集成到现有的 Google Cloud 产品中。
MySQL 源数据库的迁移工具
如果您的源数据库是 MySQL，您可以执行一些初始迁移 使用 MySQL 转储文件的场景。您必须直接连接到 迁移到正在运行的源 MySQL 数据库，以完成生产迁移。
下表根据迁移阶段和 无论是使用转储文件，还是直接连接来源， 数据库：
| 迁移阶段 | 转储文件 | 直接连接到源数据库 |
|---|---|---|
| 评估 | 将 SMT 与 mysqldump 搭配使用。 |
将 SMT 与 mysqldump 搭配使用。 |
| 架构转换 | 将 SMT 与 mysqldump 搭配使用。 |
使用 SMT 配置和转换架构。 |
| 示例数据加载 |
|
执行批量迁移。 |
| 数据迁移 | 不适用 | 执行批量迁移，然后执行最短停机时间迁移。 |
| 数据验证 | 不适用 | 使用 DVT。 |
| 故障切换配置 | 不适用 | 使用 SMT 进行反向复制。 |
PostgreSQL 源数据库的迁移工具
如果源数据库使用 PostgreSQL，那么您可以执行一些 使用 PostgreSQL 转储文件了解迁移阶段。 您必须直接连接到 以完成迁移。
下表根据迁移阶段和 无论您是使用转储文件，还是直接从来源连接， 数据库：
| 迁移阶段 | 转储文件 | 直接连接到源数据库 |
|---|---|---|
| 评估 | 将 SMT 与 pg_dump 搭配使用。 |
使用特定媒体市场区域。 |
| 架构转换 | 将 SMT 与 pg_dump 搭配使用。 |
使用 SMT 配置和转换架构。 |
| 加载示例数据 |
|
执行停机时间最短的迁移。 |
| 数据迁移 | 不适用 | 执行最短停机时间迁移。 |
| 数据验证 | 不适用 | 使用 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 兼容的架构后，您可以准备好数据库以使用示例数据进行测试。您可以使用 BigQuery 反向 ETL 工作流加载示例数据。如需了解详情，请参阅 加载示例数据。
迁移您的应用
数据库迁移需要不同的驱动程序和库，还需要针对 Spanner 不支持的功能进行补偿。接收者 根据 Spanner 的优势进行优化 您可能需要更改代码、应用流程和架构。
以下是将应用迁移到 Spanner 所需的一些更改：
- Spanner 不支持在数据库级别运行用户代码，因此 您需要移动存储在数据库级的所有过程和触发器 应用
- 使用 Spanner 客户端库和对象关系映射器 (ORM)。如需了解详情，请参阅 API、客户端库和 ORM 驱动程序概览。
- 如果您需要转换查询，请手动转换它们 第三方工具
- 记下分区 DML、只读事务、提交时间戳和读取时间戳，以及它们如何优化应用性能。
您可能还需要更改交易处理方式。没有工具 ，因此您需要手动完成此步骤。保留 注意以下几点：
- 每次提交最多只能包含 40,000 项变更。表上的每个二级索引 每行一项额外的变更。如需使用变更修改数据，请参阅 使用变更插入、更新和删除数据。 要修改大量数据，请使用 分区 DML。
- 对于事务隔离级别，无需处理，因为 Spanner 事务更加隔离。
- 由于 Spanner 是可线性化的，因此它默认会处理一致性和锁定。
测试和调整架构和应用性能
性能调整是一个迭代过程，在此过程中，您需要评估 基于部分数据的 CPU 利用率和延迟时间，请调整您的架构 以提高性能，并再次进行测试。
例如，您可以在架构中添加或更改索引，或者将 主键。在应用中，您可以进行批量写入，也可以合并或修改查询。
特别是对于生产流量，性能调优非常重要，有助于避免意外情况。设置越接近，性能调整就越有效 实时生产流量吞吐量和数据大小。
如需测试和调整架构和应用性能，请按以下步骤操作：
- 将一部分数据上传到 Spanner 数据库。对于 详情，请参阅迁移数据。
- 将应用指向 Spanner。
- 通过检查基本流程来验证正确性。
- 通过执行负载测试来验证性能是否符合您的预期
应用帮助您确定和优化
成本高昂的查询，请参阅
使用 Query Insights 检测查询性能问题。
具体而言，以下因素可能会导致查询效果欠佳
效果：
- 低效查询：如需了解如何编写高效查询， 请参阅 SQL 最佳实践。
- 高 CPU 利用率：如需了解详情，请参阅调查高 CPU 利用率。
- 锁定：为了减少事务锁定引起的瓶颈， 请参阅 识别可能导致高延迟的事务。
- 架构设计效率低：如果架构设计得不恰当，则查询 优化的用处不大
- 热点：Spanner 中的热点会限制写入吞吐量， 尤其是高 QPS 应用。为了识别热点或 反模式，请查看密钥 视听视频 Google Cloud 控制台中的统计信息。如需详细了解 避免热点，请参见 选择一个主键以避免生成热点。
- 如果您修改架构或索引，请重复正确性和性能 直到达到令人满意的结果为止。
如需详细了解如何优化数据库性能，请与 Spanner 支持团队联系。
迁移数据
在优化 Spanner 架构并将 您需要将数据移入一个空的生产环境中 Spanner 数据库，然后切换到 Spanner 数据库。
您或许可以迁移数据库，具体取决于您的源数据库 以尽可能减少停机时间，或者可能需要长时间停机。
对于最短停机时间的迁移和停机时间较长的迁移，我们都建议使用 Dataflow 和 Spanner 迁移工具。
下表显示了最短停机时间迁移之间的区别 以及支持时间较长的迁移，包括支持的来源、格式、大小、 和吞吐量
| 尽可能减少迁移停机时间 | 在停机期间进行迁移 | |
|---|---|---|
| 支持的来源 | 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 迁移工具编排了以下几项 进程：
- 设置 Cloud Storage 存储桶，以便在快照迁移期间在源数据库中存储 CDC 事件。
- 设置一个 Datastream 作业，用于移动大量 CDC 数据并将增量 CDC 数据持续流式传输到 Cloud Storage 存储桶。您设置来源连接配置文件 Spanner 迁移工具中。
- 设置 Dataflow 作业以将 CDC 事件迁移到 Spanner。
当 Dataflow 复制了大部分数据后，会停止将数据写入 源数据库，并等待数据完成迁移。这会导致在 Spanner 赶上源数据库期间出现短暂的停机时间。之后，应用可以切换到 Spanner。
下图展示了此过程：
在停机的情况下进行迁移
对于 MySQL、PostgreSQL 或 Oracle 数据库以外的数据库，如果 导出到 CSV 或 Avro 停机时间。我们建议使用 Dataflow 或 Spanner 迁移工具。
建议仅针对测试环境或 处理数小时停机时间的应用。在有数据库在线的情况下，如果迁移会导致停机，则可能会导致数据丢失。
如需执行停机迁移，请按照以下简要步骤操作：
- 生成源数据库中的数据的转储文件。
- 将转储文件上传到 Cloud Storage，采用 MySQL、PostgreSQL、Avro 或 CSV 转储格式。
- 使用 Dataflow 将转储文件加载到 Spanner Spanner 迁移工具。
生成多个小型转储文件可加快写入速度 Spanner，因为 Spanner 可以读取多个转储文件 并行的。
从源数据库生成转储文件时，为了生成一致的数据快照，请注意以下事项：
- 为了防止数据在转储文件生成期间发生变化， 在执行转储之前，对源数据库应用读取锁定。
- 使用来自源数据库的读取副本生成转储文件， 已停用复制。
推荐的批量迁移格式
Avro 是批量迁移到 Spanner 的首选格式。如果 使用 Avro 时，请考虑以下几点：
- 要生成数据的 Avro 转储，请使用如下工具： DBeam。 如需详细了解如何导出到 Avro，请参阅 将数据从非 Spanner 数据库导出到 Avro 文件。
- 如需导入 Avro 数据，请使用 Dataflow 导入作业。有关 请参阅 将 Avro 文件从非 Spanner 数据库导入 Spanner 实例。
如果您使用的是 CSV，请考虑以下事项：
- 如需生成数据的 CSV 转储文件，请使用来源支持的 CSV 生成功能。如果数据包含换行符，请使用自定义行分隔符。
- 如需导入 CSV 数据，请使用 Dataflow 导入作业。您可以创建 您自己的 Dataflow 导入模板，也可以使用 Google Cloud 导入模板。如需了解详情，请参阅 Dataflow 数据流水线模板。
如果您使用的是 MySQL 或 PostgreSQL，则可以使用 Spanner 迁移工具。
如需了解如何使用自定义脚本将数据加载到 Spanner 中，请参阅 批量加载的性能指南。
验证数据迁移
数据验证是比较来自来源和 以确保它们匹配
数据验证工具 (DVT) 是一种开源工具，可以连接到数据存储区并执行检查， 来源和 Spanner 之间的流量。我们建议使用它 作为迁移的一部分进行的基本验证，例如：
- 检查是否创建了所有表，以及所有架构映射是否均已创建 正确 。
- 使每个表的行数一致。
- 提取随机行以验证正确性。
- 验证您的列（
count、sum、avg、min、max、group by）。 - 比较行级别的任何循环冗余校验或哈希函数。
如需执行更具体的验证，请在迁移期间构建自定义检查。
配置割接和故障切换机制
迁移通常既耗时又复杂。内置后备广告，以避免 迁移过程中可能出现的重大影响，让您可以将 以尽可能缩短停机时间。
目前的建议是使用更改数据流执行反向复制，并通过 Pub/Sub 或 Cloud Storage 等数据流写回源数据库。
反向复制需要执行以下操作：
- 处理数据类型或内容的变化。
- 撤消在迁移期间执行的所有转换。
- 将数据推送到适当的目标位置，同时考虑源端的分片方案。