本文档介绍了将数据库迁移到 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 转储文件执行一些迁移阶段。您必须直接连接到正在运行的源 PostgreSQL 数据库才能完成迁移。
下表根据迁移阶段以及您是使用转储文件还是直接从源数据库连接来推荐迁移工具：
| 迁移阶段 | 转储文件 | 直接连接到源数据库 |
|---|---|---|
| 评估 | 将 SMT 与 pg_dump 搭配使用。 |
使用 DMA。 |
| 架构转换 | 将 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。
- 通过检查基本流程来验证正确性。
- 对应用执行负载测试，验证性能是否符合预期。如需获取有关识别和优化最耗时的查询的帮助，请参阅使用查询数据分析检测查询性能问题。具体而言，以下因素可能会导致查询性能不佳：
- 查询效率不高：如需了解如何编写高效查询，请参阅 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，则您可以迁移到 Spanner，但会出现停机时间。我们建议使用 Dataflow 或 Spanner 迁移工具。
建议仅对测试环境或能够处理几小时停机时间的应用进行会导致停机的迁移。在有数据库处于运行状态的情况下，如果迁移会导致停机，则可能会导致数据丢失。
如需执行停机迁移，请大致按照以下步骤操作：
- 生成源数据库中数据的转储文件。
- 将转储文件以 MySQL、PostgreSQL、Avro 或 CSV 转储格式上传到 Cloud Storage。
- 使用 Dataflow 或 Spanner 迁移工具将转储文件加载到 Spanner 中。
生成多个小型转储文件可以加快写入 Spanner 的速度，因为 Spanner 可以并行读取多个转储文件。
从源数据库生成转储文件时，为了生成一致的数据快照，请注意以下事项：
- 为防止数据在生成转储文件期间发生更改，请在执行转储之前对源数据库应用读取锁。
- 使用已停用复制的源数据库中的读取副本生成转储文件。
批量迁移的建议格式
将数据批量迁移到 Spanner 时，首选格式是 Avro。如果您使用的是 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 等数据流写回源数据库。
反向复制需要执行以下操作：
- 处理数据类型或内容的更改。
- 还原迁移期间执行的所有转换。
- 将数据推送到适当的目标位置，同时考虑源端的分片方案。