从 AWS 迁移到 Google Cloud：从 Amazon RDS for SQL Server 迁移到 Cloud SQL for SQL Server

Last reviewed 2024-06-28 UTC

Google Cloud 提供了工具、产品、指导和专业服务，可帮助您从 Amazon Relational Database Service (RDS) 迁移到 Cloud SQL for SQL Server。

本文档适合希望规划、实施和验证数据库迁移项目的云和数据库管理员。它还适用于正在评估迁移机会并希望了解迁移示例的决策者。

本文档重点介绍同构数据库迁移，即来源数据库和目标数据库采用相同数据库技术的迁移。来源是 Amazon RDS for SQL Server，目标是 Cloud SQL for SQL Server。

本文档是关于从 AWS 迁移到 Google Cloud 的系列文章中的一篇，该系列文章包括以下文档：

• 开始
• 从 Amazon EC2 迁移到 Compute Engine
• 从 Amazon S3 迁移到 Cloud Storage
• 从 Amazon EKS 迁移到 GKE
• 从 Amazon RDS 和 Amazon Aurora for MySQL 迁移到 Cloud SQL for MySQL
• 从 Amazon RDS 和 Amazon Aurora for PostgreSQL 迁移到 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL
• 从 Amazon RDS for SQL Server 迁移到 Cloud SQL for SQL Server（本文档）
• 从 AWS Lambda 迁移到 Cloud Run

如需迁移到 Google Cloud，建议您遵循迁移到 Google Cloud：使用入门中所述的迁移框架。

下图说明了迁移过程的路径。

您可能需要通过一系列迭代从来源环境迁移到 Google Cloud，例如，您可能会先迁移一部分工作负载，然后再迁移其他工作负载。对于每个单独的迁移迭代，您都需要遵循一般迁移框架的各个阶段：

1. 评估和发现工作负载和数据。
2. 在 Google Cloud 上规划和构建基础。
3. 将工作负载和数据迁移到 Google Cloud。
4. 优化您的 Google Cloud 环境。

如需详细了解此框架的各个阶段，请参阅迁移到 Google Cloud：使用入门。

如需设计有效的迁移计划，建议您验证计划的每个步骤，并确保您具有回滚策略。为了帮助验证您的迁移计划，请参阅迁移到 Google Cloud：验证迁移计划的最佳做法。

评估来源环境

在评估阶段，您需要确定从来源环境迁移到 Google Cloud 的要求和依赖项。

评估阶段对于成功迁移而言至关重要。您需要深入了解需要迁移的工作负载，它们的要求和依赖项以及您当前的环境。您需要清楚自己的起点，这样才能成功地计划和执行 Google Cloud 迁移。

评估阶段包括以下任务：

1. 构建一个完整的工作负载清单。
2. 根据工作负载的属性和依赖项对工作负载进行分类。
3. 为您的团队开展 Google Cloud 培训和指导
4. 在 Google Cloud 上构建实验和概念验证。
5. 计算目标环境的总拥有成本 (TCO)。
6. 为工作负载选择迁移策略。
7. 选择迁移工具。
8. 定义迁移计划和时间表。
9. 验证迁移计划。

如需详细了解评估阶段和这些任务，请参阅迁移到 Google Cloud：评估和发现工作负载。以下部分基于该文档中的信息。

数据库评估阶段可帮助您选择与来源数据库匹配的目标 Cloud SQL 数据库实例的大小和规格，以满足类似的性能需求。请特别注意磁盘大小、吞吐量、IOPS 和 vCPU 数量。由于目标数据库实例大小设置不正确，迁移可能会遇到困难或失败。不正确的大小可能会导致较长的迁移时间、数据库性能问题、数据库错误和应用性能问题。在决定使用 Cloud SQL 实例时，请注意磁盘性能取决于磁盘大小和 vCPU 数量。

以下部分依赖于迁移到 Google Cloud：评估和发现您的工作负载，并整合该文档中的信息。

构建 Amazon RDS 实例的清单

如需定义迁移范围，您可以创建清单并收集有关 Amazon RDS 实例的信息。理想情况下，此流程应采用自动化方式，因为手动方法容易出错，并且可能会导致错误的假设。

Amazon RDS 和 Cloud SQL 可能不具有类似的功能、实例规范或操作。某些功能可能会以不同的方式实现或无法使用。差异领域可能涉及基础架构、存储、身份验证和安全性、复制、备份、高可用性、资源容量模型和特定数据库引擎功能集成以及扩展。数据库参数设置的默认值也会因数据库引擎类型、实例大小和架构而异。

基准测试有助于您更好地了解要迁移的工作负载，并有助于为迁移目标环境定义正确的架构。收集有关性能的信息非常重要，有助于估算 Google Cloud 目标环境的性能需求。基准测试概念和工具在迁移过程的执行测试和验证阶段中有详细介绍，但它们也适用于清单构建阶段。

评估工具

如需对当前基础架构进行初步概览评估，我们建议您使用 Google Cloud Migration Center 以及其他专门的数据库评估工具，例如 migVisor 和 Database Migration Assessment Tool (DMA)。

借助 Migration Center，您可以对应用和数据库环境进行全面评估，包括将数据库迁移到 Google Cloud 的技术适用性。您会收到每个来源数据库的大小和配置建议，并为服务器和数据库创建总拥有成本 (TCO) 报告。

如需详细了解如何使用 Migration Center 评估您的 AWS 环境，请参阅从其他云服务商导入数据。

除了 Migration Center 之外，您还可以使用专用工具 migVisor。migVisor 支持各种数据库引擎，特别适合异构迁移。如需了解 migVisor，请参阅 migVisor 概览。

migVisor 可以识别可能导致迁移失败的制品和不兼容的专有数据库功能，并可以指明解决方法。migVisor 还可以推荐目标 Google Cloud 解决方案，包括初始调整大小和架构。

migVisor 数据库评估输出提供以下功能：

• 全面发现和分析当前数据库部署。
• 根据数据库使用的专有功能，提供迁移复杂性的详细报告。
• 财务报告，详细说明了迁移后节省的费用、迁移费用和新的运维预算。
• 分阶段迁移计划，以最大限度地减少对业务的影响来迁移数据库和相关应用。

如需查看评估输出的一些示例，请参阅 migVisor - Cloud 迁移评估工具。

请注意，migVisor 会暂时提高数据库服务器的利用率。通常，这种额外负载不到 3%，并且可以在非高峰时段运行。

migVisor 评估输出有助于构建 RDS 实例的完整清单。该报告包含通用属性（数据库引擎版本、CPU 以及内存大小），以及数据库拓扑、备份政策、参数设置和正在使用的特殊自定义设置的详细信息。

如果您更喜欢使用开源工具，可以将数据收集器脚本与上述工具搭配使用或使用数据收集器脚本代替上述工具。这些脚本可帮助您收集详细信息（有关工作负载、功能、数据库对象和数据库代码），并构建数据库清单。此外，脚本通常还会提供详细的数据库迁移评估，包括迁移工作量估算。

我们建议使用由 Google 工程师构建的开源工具 DMA。它提供完整且准确的数据库评估，包括正在使用的功能、数据库逻辑和数据库对象（包括架构、表、视图、函数、触发器和存储过程）。

如需使用 DMA，请从 Git 代码库下载数据库引擎的收集脚本，然后按照说明操作。将输出文件发送到 Google Cloud 进行分析。Google Cloud 会创建并提供数据库评估读数，然后提供迁移过程中的后续步骤。

确定并记录迁移范围，以及可接受的停机时间

在此阶段，您需要记录对迁移策略和工具有影响的重要信息。现在，您可以回答以下问题：

• 您的数据库是否超过 5 TB？
• 您的数据库中是否有任何大型表？是否大于 16 TB？
• 数据库位于何处（区域和可用区），它们与应用的距离有多近？
• 数据更改的频率如何？
• 您的数据一致性模型是什么？
• 目标数据库有哪些选项？
• 来源数据库和目标数据库的兼容性如何？
• 数据是否需要位于某些物理位置？
• 是否有可压缩和归档的数据，或者是否有根本不需要迁移的数据？

要定义迁移范围，请确定要保留哪些数据以及要迁移哪些数据。迁移所有数据库可能需要花费大量时间和精力。部分数据可能会保留在来源数据库备份中。例如，可能不需要旧的记录表或归档数据。或者，您也可以决定在迁移过程完成后再迁移数据，具体取决于您的策略和工具。

建立数据迁移基准，以帮助您比较和评估结果和影响。这些基准是表示数据在迁移前后的状态的参考点，可帮助您做出决策。对来源环境进行衡量非常重要，这有助于您评估数据迁移的成功情况。此类测量包括：

• 数据的大小和结构。
• 数据的完整性和一致性。
• 最重要的业务交易和流程的时长和性能。

确定您可以承受的停机时间。停机时间对业务有何影响？是否存在数据库活动较少的时间段，在此期间，受停机时间影响的用户较少？如果是，此类时段有多长时间，何时发生？考虑设置部分只写停机时间，同时仍提供只读请求。

评估您的部署和管理流程

构建清单后，请评估数据库的运维和部署流程，以确定需要如何调整这些流程以促进迁移。这些流程对于您如何准备和维护生产环境至关重要。

请考虑如何完成以下任务：

• 为实例定义并强制执行安全政策：例如，您可能需要替换 Amazon 安全组。您可以使用 Google IAM 角色、VPC 防火墙规则和 VPC Service Controls 来控制对 Cloud SQL 实例的访问权限，并限制 VPC 内的数据。如果您打算将 Windows 身份验证与 Cloud SQL for SQL Server 搭配使用，则需要部署 托管式 Microsoft AD 并连接到现有的 Active Directory 基础架构。
• 为实例打补丁并对其进行配置：您现有的部署工具可能需要更新。例如，您可能在 Amazon 参数组或 Amazon 选项组中使用自定义配置设置。您可能需要调整预配工具，以使用 Google Cloud Storage 或 Secret Manager 读取此类自定义配置列表。
• 管理监控和提醒基础架构：您的 Amazon 来源数据库实例的指标类别可在迁移过程中提供可观测性。指标类别可能包括 Amazon CloudWatch、性能数据分析、增强型监控和操作系统进程列表。

完成评估

从 Amazon RDS 环境构建清单后，请完成评估阶段的其余活动，如迁移到 Google Cloud：评估和发现您的工作负载中所述。

规划和构建基础

在规划和构建阶段，您需要预配和配置基础架构以执行以下操作：

• 在 Google Cloud 环境中支持您的工作负载。
• 连接来源环境和 Google Cloud 环境以完成迁移。

规划和构建阶段由以下任务组成：

1. 构建资源层次结构。
2. 配置 Google Cloud 的 Identity and Access Management (IAM)。
3. 设置结算功能。
4. 设置网络连接。
5. 强化安全性。
6. 设置日志记录、监控和提醒。

如需详细了解这些任务，请参阅迁移到 Google Cloud：规划和构建基础。

监控和提醒

使用 Google Cloud Monitoring，其中包含多个 Google Cloud 产品的预定义信息中心，涉及 Cloud SQL 监控信息中心。或者，您可以考虑使用与 Google Cloud 集成的第三方监控解决方案，例如 Datadog 和 Splunk。如需了解详情，请参阅关于数据库可观测性。

将 Amazon RDS for SQL Server 实例迁移到 Cloud SQL for SQL Server

如需迁移实例，请执行以下操作：

1. 选择迁移策略：持续复制或预定维护。

2. 根据您选择的策略和要求选择迁移工具。

3. 为每个数据库迁移定义迁移计划和时间表，包括准备和执行任务。

4. 定义必须完成的准备任务，以确保迁移工具能够正常运行。

5. 定义执行任务，其中包括实现迁移的工作活动。

6. 为每个执行任务定义后备场景。

7. 执行测试和验证，这可以在单独的预演环境中完成。

8. 执行迁移。

9. 执行生产环境切换。

10. 清理来源环境并配置目标实例。

11. 执行调优和优化。

以下各部分介绍了每个阶段。

选择迁移策略

在此步骤中，您已获得足够的信息，可以评估并选择最适合每个数据库的用例的以下迁移策略之一：

• 预定维护（也称为一次性迁移）：如果您可以承受停机时间，此方法是理想之选。此选项的费用和复杂性相对较低，因为您的工作负载和服务不需要进行大量重构。但是，如果迁移在尚未完成之前失败，您必须重新启动该过程，这会延长停机时间。

• 持续复制（也称为 Trickle 迁移）：对于关键任务数据库，此选项可降低数据丢失风险，并实现几乎为零的停机时间。工作被拆分为多个部分，因此如果发生失败，回滚和重复操作所需的时间会更短。不过，设置起来更复杂，需要进行更多规划和花费更多时间。还需要付出额外的努力来重构连接到数据库实例的应用。请考虑以下变体之一：

  • 使用 Y（写入和读取）方法，这是一种并行迁移形式，在迁移期间在来源实例和目标实例中复制数据。
  • 使用数据访问微服务，从而减少 Y（写入和读取）方法所需的重构工作。

如需详细了解数据迁移策略，请参阅评估数据迁移方法。

下图是一个流程图，其中包含您在确定单个数据库的迁移策略时可能会遇到的示例问题：

上图显示了以下决策点：

• 您能承受任何停机时间吗？

  • 如果没有，请采用持续复制迁移策略。
  • 如果是，请继续回答下一个决策点。

• 迁移数据时，您是否可以承受切换期所代表的停机时间？切换窗口表示备份数据库、将其传输到 Cloud SQL、恢复数据库以及切换应用所需的时间。

  • 如果没有，请采用持续复制迁移策略。
  • 如果是，请采用预定维护迁移策略。

不同数据库的策略可能不同，即使它们位于同一实例中也是如此。混合使用多种策略可以取得最佳效果。例如，您可以使用预定维护方法迁移小型数据库和不常用的数据库，但对于停机时间代价较高的关键任务数据库，则应使用持续性复制。

通常，在初始来源实例和目标实例之间切换后，迁移就视为已完成。所有复制（如果使用）都会停止，所有读取和写入操作都会在目标实例上完成。在两个实例同步时进行切换，意味着不会丢失数据且停机时间最短。

如需详细了解数据迁移策略和部署，请参阅数据库迁移分类。

最大限度地减少停机时间和迁移相关的影响

不提供应用停机时间的迁移配置需要更复杂的设置。在设置复杂性和在流量较低的营业时间安排的停机时间之间找到适当的平衡。

每种迁移策略都有其权衡之处，并且与迁移过程相关的某些影响。例如，复制过程会在来源实例上增加一些额外负载，并且您的应用可能会受到复制延迟的影响。应用（和客户）可能需要在应用停机期间等待，至少在使用新数据库之前等待复制延迟时间。在实践中，以下因素可能会增加停机时间：

• 数据库查询可能需要几秒钟才能完成。在迁移时，运行中的查询可能会被中止。
• 如果数据库较大或具有大量缓冲区内存，缓存可能需要一些时间才能填满。
• 在来源中停止并在 Google Cloud 中重新启动的应用可能会出现轻微的延迟，直到与 Google Cloud 数据库实例建立连接为止。
• 必须将应用的网络路由重新路由。具体用时因 DNS 条目的设置方式而异。更新 DNS 记录时，请在迁移前降低 TTL。

以下常见做法有助于最大限度地减少停机时间和影响：

• 找到停机时间对工作负载影响最小的时间段。例如，在正常工作时间以外、周末或其他预定维护期内。
• 确定工作负载的哪些部分可以在不同阶段进行迁移和生产切换。您的应用可能具有不同的组件，这些组件可以隔离、调整和迁移，而不会产生任何影响。例如，前端、CRM 模块、后端服务和报告平台。此类模块可以拥有自己的数据库，并可在迁移过程中提前或延后安排迁移。
• 如果您可以承受目标数据库的延迟时间，请考虑实现渐进式迁移。使用增量、批量数据传输，并调整部分工作负载以处理目标实例上的过时数据。
• 考虑重构您的应用，以支持尽可能减少迁移影响。例如，您可以调整应用以同时写入来源数据库和目标数据库，从而实现应用级复制。

选择迁移工具

选择合适的迁移工具是成功完成迁移的最重要因素。确定迁移策略后，请查看并确定迁移工具。

您可以使用许多工具，每个工具都针对特定迁移应用场景进行了优化。应用场景可能包括：

• 迁移策略（预定的维护或持续复制）。
• 来源数据库引擎和目标数据库引擎以及引擎版本。
• 来源实例和目标实例所在的环境。
• 数据库大小。数据库越大，迁移初始备份所需的时间就越长。
• 数据库更改的频率。
• 是否可以使用托管式服务进行迁移。

如需确保无缝迁移和切换，您可以使用应用部署模式、基础架构编排和自定义迁移应用。不过，名为“托管式迁移服务”的专用工具可以简化将数据、应用甚至整个基础架构从一个环境迁移到另一个环境的过程。它们从来源数据库运行数据提取，将数据安全地传输到目标数据库，并可酌情在传输过程中修改数据。借助这些功能，它们可以封装复杂的迁移逻辑并提供迁移监控功能。

托管式迁移服务具有以下优势：

• 最大限度地缩短停机时间：服务会在可用时使用数据库引擎的内置复制功能，并执行副本升级。

• 确保数据完整性和安全性：数据会安全可靠地从来源数据库传输到目标数据库。

• 提供一致的迁移体验：借助数据库迁移可执行文件，您可以管理和监控不同的迁移技术和模式，并将其整合到一致的通用界面中。

• 提供弹性强且经过验证的迁移模型：数据库迁移虽然不常见，但却是关键事件。为了避免初学者犯错以及现有解决方案出现问题，您可以使用经验丰富的专家提供的工具，而不是构建自定义解决方案。

• 优化费用：与为自定义迁移解决方案预配额外的服务器和资源相比，托管式迁移服务更具成本效益。

后续各部分介绍了迁移工具建议，这些建议取决于所选的迁移策略。

用于执行预定维护迁移的工具

以下子部分介绍了可用于一次性迁移的工具及其局限性和最佳实践。

内置数据库引擎备份

如果可以接受较长停机时间，并且来源数据库相对静态，您可以使用数据库引擎的内置备份和恢复功能。

设置和同步需要付出一些努力，尤其是对于大量数据库，但数据库引擎备份通常随时可用且易于使用。这种方法适用于任何大小的数据库，并且通常比其他工具更适合大型实例。

数据库引擎备份存在以下常规限制：

• 备份很容易出错，尤其是手动执行时。
• 如果没有正确管理备份，数据将不安全。
• 备份缺乏适当的监控功能。

如果您选择此方法，请考虑以下限制和最佳实践：

• 对于大于 5 TB 的数据库备份，请使用条带备份（多个文件的备份）。
• 使用条带式备份时，您一次只能备份或从不超过 10 个备份文件中恢复。
• 您必须将数据备份到与源数据库实例位于同一 Amazon 区域的 Amazon S3 存储桶。
• 备份不包含 SQL Server 登录、权限和服务器角色，因为它们位于实例级别。如需将此类数据从源实例转移到目标实例，请使用 PowerShell 脚本或 DBAtools 等工具。

如需详细了解限制和最佳实践，请参阅使用 Cloud SQL for SQL Server 导入和导出数据的最佳实践以及 Cloud SQL for SQL Server 已知问题。

其他预定维护迁移方法

使用其他方法，可能会让您在预定维护迁移过程中拥有更大的控制权和灵活性。

例如，通过使用平面文件导出和导入数据（或使用自定义脚本），您可以执行以下操作：

• 在迁移期间对数据执行转换、检查或其他操作。例如，对源数据进行验证、汇总或标准化和反规范化。
• 选择要迁移的结构以及要保留的结构。 您可以决定仅从平面文件中提取部分表格以进行导入。
• 选择根据网域、来源、年龄或其他自定义条件滤除数据。例如，您可以在迁移前排除达到年龄阈值的数据，并将其存储在文件或源数据库的最终备份中。
• 重构数据库结构，并将所产生的停机时间与迁移停机时间同步。
• 将多个实例或数据库合并到单个实例或数据库中，以降低运维成本并解决可伸缩性问题。例如，您可能希望将方法从为每个客户提供一个实例、数据库或架构更改为使用单个经过多租户优化的数据库结构。

其他方法包括：

• 使用 CSV 或 JSON 文件：在此方法中，您将数据库的数据提取到文件中，然后将文件导入目标实例。

  • 虽然速度通常较慢，但此方法可帮助您迁移部分表（或给定表中的数据）。
  • 许多工具都支持 CSV 和 JSON 格式。
  • 如果您自动执行该流程，则可以选择改用批量持续复制迁移。

• 使用 Microsoft 的 SQL Server 导入和导出向导：此工具使用 SQL Server Integration Services (SSIS)，可让您从各种来源（例如其他数据库引擎或平面文件）导入数据。

• 使用 SQL Server 生成和发布脚本向导和 bcp 实用程序：此工具是 Microsoft SQL Server Management Studio 的一部分。

  • 通过这种方法，您可以为整个数据库架构或其中的部分内容创建脚本。
  • 借助 bcp 实用程序，您可以对数据编写脚本，并将其导出到文件。

• 如果您的源使用 Amazon RDS 标准版，请使用快照复制：

  • 通过这种方法，您可以将 RDS 实例的 SQL Server 备份恢复到 Compute Engine 上的另一个独立 SQL Server 实例。然后，使用快照复制功能迁移到 Cloud SQL for SQL Server。
  • 快照生成会保留对源表的锁定，这可能会影响您的工作负载。
  • 快照复制可能会给您的 Amazon RDS 服务器带来额外的负载。
  • 不过，您可以选择要迁移或复制的对象，从而实现灵活性。
  • 如需了解详情，请参阅使用快照复制功能将数据从 SQL Server 2017 迁移到 Cloud SQL for SQL Server。

适用于持续复制迁移的工具

下图是一个流程图，其中包含一些问题，可帮助您在使用连续复制迁移策略时为单个数据库选择迁移工具：

上图显示了以下决策点：

• 您是否希望使用托管式迁移服务？

  • 如果是，请继续执行下一步决策。如果您可以接受最短的停机时间，并且不需要数据转换或实时同步，我们建议您使用 Database Migration Service。否则，请探索第三方选项。
  • 如果没有，请继续执行下一步。如果数据库引擎内置复制功能受支持，我们建议使用内置复制。如果不是，我们建议您探索其他迁移选项。

• 您能否接受尽可能缩短停机时间，并且在迁移过程中无需进行数据转换或实时同步？

  • 如果是，我们建议您使用 Database Migration Service。
  • 如果不是，请探索第三方选项。

• 是否支持数据库引擎专用内置复制？

  • 如果是，我们建议您使用内置复制。
  • 如果不是，我们建议您探索其他迁移选项。

以下各部分介绍了可用于持续复制迁移的工具及其局限性和最佳实践。

使用 Database Migration Service 进行持续复制迁移

当源数据库为 Amazon RDS 时，Database Migration Service 支持将数据库以同构方式迁移到 Cloud SQL for SQL Server。

Database Migration Service 是一款经济实惠且简单易用的工具。对于存在以下情况的情况，我们建议使用 Database Migration Service：

• 您能承受极少的停机时间。
• 您不需要实时同步。
• 您无需在迁移期间执行数据转换。

如果您选择此工具，请考虑以下限制和最佳实践：

• 停机时间取决于事务日志备份的频率。
• 备份不包含 SQL Server 登录、权限或服务器角色，因为它们位于实例级别。使用脚本从源实例中导出它们，然后使用 PowerShell 脚本或 DBAtools 等工具将它们转移到目标实例。

如需查看完整的限制列表，请参阅已知限制。

数据库引擎内置复制

Cloud SQL 支持 SQL Server 复制。不过，标准版 Amazon RDS for SQL Server 只能是订阅方。无法使用 Amazon RDS 标准版的内置复制功能。只有 Amazon RDS Custom for SQL Server 可以设置为内置发布商。

如需查看 Amazon RDS 上支持和不支持的功能的列表，请参阅 Amazon RDS for Microsoft SQL Server。

其他持续复制迁移方法

其他持续复制迁移方法包括：

• 重构应用以执行 Y（写入和读取），或使用数据访问微服务。

  • 持续复制由您的应用执行。
  • 迁移工作重点在于重构或开发连接到数据库实例的工具。
  • 然后，逐步重构和部署读者应用，以使用目标实例。

• 实现定期查询源实例中数据、仅过滤出新数据并将数据写入 CSV、JSON 或 Parquet 文件的函数。

  • 这些文件存储在 Google Cloud Storage 存储桶中。
  • 您可以使用 Cloud Run 函数将文件立即写入目标数据库实例。
  • 变更数据捕获 (CDC) 功能可帮助您实现近乎实时的复制迁移。
  • 您可以使用 AWS Database Migration Service (AWS DMS)将 CDC 以 Parquet 格式流式传输到 Amazon S3 数据湖。
  • 您可以使用自定义实现来读取文件并将其内容写入 Cloud SQL。

用于持续复制迁移的第三方工具

在某些情况下，最好针对大多数数据库引擎使用一个第三方工具。例如，如果您希望使用托管式迁移服务，并且需要确保目标数据库始终与来源数据库近乎实时同步，或者在迁移过程中需要进行更复杂的转换（如数据清理、重组和调整），则可以使用这种方法。

如果您决定使用第三方工具，请选择以下建议之一，该建议可用于大多数数据库引擎。

Striim 是一个端到端的内存中平台，可用于实时收集、过滤、转换、丰富、汇总、分析和传送数据：

• 优点：

  • 处理大量数据和复杂的迁移。
  • SQL Server 的内置变更数据捕获。
  • 预配置的连接模板和无代码流水线。
  • 能够处理在高事务负载下运行的关键任务型大型数据库。
  • 仅传送一次

• 缺点：

  • 非开源。
  • 成本可能很高，尤其是对于长时间的迁移。
  • 数据定义语言 (DDL) 操作传播的一些限制。如需了解详情，请参阅支持的 DDL 操作和架构演变说明和限制。

如需详细了解 Striim，请参阅在 Google Cloud 中运行 Striim。

Debezium 是一个用于 CDC 的开源分布式平台，可将数据更改流式传输到外部订阅方：

• 优点：

  • 开源。
  • 强大的社区支持。
  • 性价比高。
  • 对行、表或数据库进行精细控制。
  • 专门用于从数据库事务日志中实时捕获更改。

• 缺点：

  • 需要具备 Kafka 和 ZooKeeper 方面的特定经验。
  • 数据更改至少传送一次，这意味着您需要处理重复数据。
  • 使用 Grafana 和 Prometheus 进行手动监控设置。
  • 不支持增量批量复制。

如需详细了解 Debezium 迁移，请参阅使用 Debezium 实现近乎实时数据复制。

Fivetran 是一个自动化数据传输平台，用于将数据从云端数据平台中传出并在云端数据平台之间传输。

• 优点：

  • 预配置的连接模板和无代码流水线。
  • 将来源数据库中的任何架构更改传播到目标数据库。
  • 仅传送一次数据更改，这意味着您无需处理重复数据。

• 缺点：

  • 非开源。
  • 对复杂数据转换的支持有限。

定义迁移计划和时间表

为了成功完成数据库迁移和生产环境切换，我们建议您准备一份定义明确、全面的迁移计划。为了帮助您减少对业务的影响，我们建议您创建一个包含所有必要工作项的列表。

定义迁移范围会显示您在数据库迁移过程之前、期间和之后必须执行的工作任务。例如，如果您决定不从数据库迁移某些表，则可能需要执行迁移前或迁移后任务来实现此过滤。您还需要确保数据库迁移不会影响现有的服务等级协议 (SLA) 和业务连续性计划。

我们建议您的迁移规划文档包含以下文档：

• 技术设计文档 (TDD)
• RACI 矩阵
• 时间表（例如倒计时计划）

数据库迁移是一个迭代过程，第一次迁移通常比后续迁移速度更慢。通常，经过精心规划的迁移不会出现问题，但未经规划的问题仍可能出现。我们建议您始终制定回滚计划。最佳实践是遵循迁移到 Google Cloud：验证迁移计划的最佳实践中的指南。

TDD

TDD 会记录为项目做出的所有技术决策。在 TDD 中添加以下内容：

• 业务要求和重要性
• 恢复时间目标 (RTO)
• 恢复点目标 (RPO)
• 数据库迁移详情
• 迁移工作估算
• 迁移验证建议

RACI 矩阵

某些迁移项目需要 RACI 矩阵，这是一种常见的项目管理文档，用于定义哪些个人或群组负责迁移项目中的任务和交付成果。

时间轴

为每个需要迁移的数据库准备时间表。包含必须执行的所有工作任务，以及定义的开始日期和预计结束日期。

对于每个迁移环境，我们建议您创建倒计时计划。倒计时计划的结构类似于倒计时时间表，其中列出了完成迁移项目所需的所有任务，以及负责的团队和预计时长。

时间表不仅应考虑迁移前准备任务的执行，还应考虑数据传输后进行的验证、审核或测试任务。

迁移任务的持续时间通常取决于数据库大小，但还需要考虑其他方面，例如业务逻辑复杂性、应用用量和团队可用性。

倒计时计划可能如下所示：

日期	阶段	类别	Tasks	角色	倒计时	状态
2023 年 11 月 1 日	迁移前	评估	创建评估报告	发现团队	-21	完成
2023 年 11 月 7 日	迁移前	目标准备	根据设计文档的说明设计目标环境	迁移团队	-14	完成
2023 年 11 月 15 日	迁移前	公司治理	迁移日期和倒计时审批	领导团队	-6	完成
2023 年 11 月 18 日	迁移	设置 DMS	构建连接配置文件	云迁移工程师	-3	完成
2023 年 11 月 19 日	迁移	设置 DMS	构建和启动迁移作业	云迁移工程师	-2	尚未开始
2023 年 11 月 19 日	迁移	监控 DMS	监控来源实例中的 DMS 作业和 DDL 更改	云迁移工程师	-2	尚未开始
2023 年 11 月 21 日	迁移	切换 DMS	提升 DMS 副本	云迁移工程师	0	尚未开始
2023 年 11 月 21 日	迁移	迁移验证	数据库迁移验证	迁移团队	0	尚未开始
2023 年 11 月 21 日	迁移	应用测试	运行功能和性能测试	迁移团队	0	尚未开始
2023 年 11 月 22 日	迁移	公司治理	迁移验证结果为“执行”或“不执行”	迁移团队	1	尚未开始
2023 年 11 月 23 日	迁移后	验证监控	配置监控	基础架构团队	2	尚未开始
2023 年 11 月 25 日	迁移后	安全	移除 DMS 用户账号	安全团队	4	尚未开始

多个数据库迁移

如果您要迁移多个数据库，则迁移计划应包含所有迁移任务。

我们建议您先迁移较小的数据库（最好是非关键数据库），以此开始迁移过程。这种方法可以帮助您积累知识，并对迁移过程和工具充满信心。您还可以在整个迁移计划的早期阶段检测到该过程中的任何缺陷。

如果您要迁移多个数据库，则可以并行执行迁移。例如，为了加快迁移过程，您可以选择同时迁移一组小型、静态或不太关键的数据库，如以下图所示。

在图中显示的示例中，数据库 1-4 是一组同时迁移的小型数据库。

定义准备任务

准备工作是指您需要完成的所有活动，以满足迁移前提条件。如果您未完成准备任务，迁移将无法进行，或者迁移结果会导致已迁移的数据库无法使用。

准备工作可分为以下几类：

• Amazon RDS 实例准备工作和前提条件
• 来源数据库准备工作和前提条件
• Cloud SQL 设置
• 迁移专用设置

Amazon RDS 实例准备工作和前提条件

请考虑以下常见的设置和前提条件任务：

• 根据迁移路径，您可能需要允许在 RDS 实例上进行远程连接。如果您的 RDS 实例在 VPC 中配置为专用，则 Amazon 和 Google Cloud 之间必须存在专用 RFC 1918 连接。

• 您可能需要配置一个新的安全组，以允许在所需端口上进行远程连接。

  • 默认情况下，在 AWS 中，数据库实例的网络访问功能处于关闭状态。
  • 您可以在安全组中指定允许从 IP 地址范围、端口或安全组进行访问的规则。与该安全群组关联的所有数据库实例都适用相同的规则。

• 对于持续复制（通过 CDC 流式传输更改），您必须使用启用了 CDC 的完整 RDS 实例，而不是只读副本。如需了解详情，请参阅将变更数据捕获与 SQL Server 搭配使用。

• 如果您使用的是第三方工具，通常需要先进行设置和配置，然后才能使用该工具。查看第三方工具的文档。

来源数据库准备工作和前提条件

• 确保源数据库在迁移操作期间有足够的缓冲区存储空间和内存。例如，如果您使用事务日志备份文件，请监控存储用量，并确保有额外的缓冲区存储空间。
• 记录数据库参数的设置，并在进行迁移测试和验证之前将其应用于目标实例。

• 对生产使用中的来源环境进行基准测量。请考虑以下事项：

  • 衡量数据的大小以及工作负载的性能。平均而言，重要查询或事务需要多长时间？高峰时段需要多长时间？
  • 记录基准测量结果以便日后进行比较，进而帮助您确定数据库迁移的保真度是否令人满意。确定您是否可以切换生产工作负载并停用来源环境，或者是否仍需要将其用于后备目的。

Cloud SQL 设置

请仔细选择目标 Cloud SQL 数据库实例的大小和规格，以与来源数据库匹配，以满足类似的性能需求。请特别注意磁盘大小、吞吐量、IOPS 和 vCPU 数量。不正确的大小可能会导致较长的迁移时间、数据库性能问题、数据库错误和应用性能问题。

确保目标设备适合您的应用。请务必注意，Amazon RDS 配置选项可能与 Cloud SQL 不同。如果 Cloud SQL 不符合您的要求，请考虑包括 Compute Engine 上的数据库在内的选项。

在创建 Cloud SQL 实例之前，您必须确认以下属性和要求，因为这些属性和要求日后无法更改，除非重新创建实例。

• 请谨慎选择目标 Cloud SQL 实例的项目和区域。无法在 Google Cloud 项目和区域之间迁移 Cloud SQL 实例，而不会传输数据。

• 迁移到 Cloud SQL 上的匹配主要版本。例如，如果您的源使用的是 SQL Server 15.0，请迁移到 Cloud SQL for SQL Server 15.0。如果版本不同，则兼容性级别设置应相同，以确保引擎功能相同。

• 如果您使用的是内置数据库引擎备份或 Database Migration Service，请单独复制用户信息。如需了解详情，请查看数据库引擎专用备份部分中的限制。

• 查看数据库引擎专用配置标志，并比较其来源实例值和目标实例值。请确保您了解它们的影响，以及它们是否需要相同。例如，我们建议您将源数据库中 sys.configurations 视图中的值与 Cloud SQL 实例中的值进行比较。请注意，并非所有标志都必须相同，并且 Cloud SQL 实例上也不允许进行所有标志更改。

如需详细了解 Cloud SQL 设置，请参阅以下内容：

• SQL Server 的一般最佳实践
• SQL Server 的实例配置选项
• 适用于 SQL Server 的数据库引擎专用标志

迁移专用设置

如果您使用文件导出和导入进行迁移，或者使用 Database Migration Service 迁移工具，则需要创建 Cloud Storage 存储桶。该存储桶用于存储数据库和事务日志备份文件。如需详细了解如何使用 Database Migration Service，请参阅将备份文件存储在 Cloud Storage 存储桶中。

如果您使用复制，则必须确保 Cloud SQL 副本数据库可以访问您的主数据库。您可以通过已记录的连接选项来实现此目的。

根据您的场景和重要性，您可能需要实现后备场景，这通常包括反转复制的方向。在这种情况下，您可能需要从 Cloud SQL 向来源 Amazon 实例添加额外的复制机制。

对于大多数第三方工具，您需要预配特定于迁移的资源。例如，对于 Striim，您需要先使用 Google Cloud Marketplace。然后，如需在 Striim 中设置迁移环境，您可以使用 Flow Designer 创建和更改应用，也可以选择现有模板。您还可以使用 Tungsten Query Language (TQL) 编程语言编写应用的代码。借助数据验证信息中心，您可以直观地了解 Striim 应用处理的数据。

迁移完成并经过验证后，您可以停用用于连接 Amazon 和 Google Cloud 环境的资源。

定义执行任务

执行任务会执行迁移工作本身。具体任务取决于您选择的迁移工具，如以下子部分所述。

内置数据库引擎备份

如需详细了解特定于数据库的备份以及相关说明，请参阅将数据从 BAK 文件导入 Cloud SQL for SQL Server 和从 RDS for SQL Server 导出数据。如需详细了解如何自动上传事务日志文件，请参阅为 Amazon RDS 安排事务日志文件上传。

Database Migration Service 迁移作业

在 Database Migration Service 中定义和配置迁移作业，以将数据从来源实例迁移到目标数据库。迁移作业通过用户定义的连接配置文件连接到来源数据库实例。

测试所有前提条件，确保作业可以成功运行。选择一个时间，让您的工作负载能够承受迁移和生产切换带来的短暂停机时间。

迁移过程通常涉及以下任务：

• 导出源数据库的完整备份，然后将其上传到 Cloud Storage 存储桶。
• 备份事务日志文件，然后将其上传到同一 Cloud Storage 存储桶。如需详细了解如何自动执行此流程，请参阅为 Amazon RDS 安排事务日志文件上传。
• 在 Database Migration Service 中，您可以监控事务日志备份的处理情况。
• 停止对来源数据库执行写入操作。
• 等待源和目标同步，即处理最终的事务日志备份。
• 停止正在进行的复制并提升迁移作业。提升迁移作业会断开目标 Cloud SQL 实例与源数据库实例之间的连接，然后将其提升为主实例。
• 部署指向新目标数据库的应用。

如需了解详细的迁移设置流程，请参阅将 SQL Server 数据库迁移到 Cloud SQL for SQL Server。

数据库引擎内置复制

如果您使用的是 Amazon RDS 标准版，则可能需要先迁移到 Amazon RDS 自定义版，然后再复制到 Cloud SQL。

Cloud SQL 支持 SQL Server 复制。如需详细了解如何从外部服务器复制数据，请参阅使用快照复制功能将数据从 SQL Server 2017 迁移到 Cloud SQL for SQL Server。

第三方工具

为您选择的第三方工具定义任何执行任务。例如，如果您决定使用 Striim，则需要在您的命名空间中创建应用，并配置 CDC 读取器以连接到 Amazon 实例。如需了解详情，请参阅 Striim 文档中的 SQL Server 设置。

定义后备场景

为每个迁移执行任务定义后备操作项，以防范迁移过程中可能出现意外问题。后备任务通常取决于所使用的迁移策略和工具。

后备可能需要付出巨大的努力。最佳做法是，在测试结果令人满意之前，不要执行生产环境切换。应对数据库迁移和后备场景进行适当的测试，以避免严重中断。

为所有迁移执行任务定义成功标准并设置时间限制。执行迁移模拟有助于收集有关每个任务预期时间的信息。例如，对于预定的维护迁移，您可以承受切换期所代表的停机时间。不过，请务必规划好下一步的操作，以防一次性迁移作业或备份恢复在途中失败。如果迁移任务未在预期时间内完成，您可能需要推迟迁移，具体取决于计划停机时间已过的时间。

后备计划通常是指在执行生产环境切换后，如果目标实例出现问题，则回滚迁移。如果您要实施后备计划，请务必记住，必须将其视为完整的数据库迁移（包括规划和测试）。

如果您选择不制定后备计划，请务必了解可能产生的后果。如果没有后备计划，可能会增加意外的工作量，并在迁移过程中造成不必要的中断。

虽然后备是作为最后的办法来使用，并且大多数数据库迁移最终都不会使用后备策略，但我们建议您始终采用后备策略。

简单后备

在此后备策略中，您可以将应用切换回原始来源数据库实例。如果您在采用后备策略时可以承受停机时间，或者您不需要在新目标系统上提交事务，请采用此策略。

如果您确实需要目标数据库上的所有写入数据，并且可以承受一些停机时间，可以考虑停止对目标数据库实例的写入操作，执行内置备份并在来源实例上恢复备份，然后将应用重新连接到初始来源数据库实例。根据工作负载的性质和写入目标数据库实例的数据量，您可以稍后将其引入初始来源数据库系统，尤其是在工作负载不依赖于任何特定记录创建时间或任何时间顺序约束条件时。

反向复制

在此策略中，您需要将在生产切换后发生在新目标数据库上的写入操作复制回初始来源数据库。这样，您就可以让原始来源与新的目标数据库保持同步，并让写入操作在新目标数据库实例上进行。其主要缺点是，您必须先切换到目标数据库实例，然后才能测试复制流，因此无法进行端到端测试，并且在没有后备策略的情况下，复制流会有一个短暂的空档期。

如果您可以保留来源实例一段时间，并且使用连续复制迁移进行迁移，请选择此方法。

正向复制

此策略是反向复制的变体。您可以将新目标数据库上的写入操作复制到您选择的第三方数据库实例。您可以将应用指向此第三个数据库，该数据库会在服务器不可用时连接到服务器并运行只读查询。您可以根据需要使用任何复制机制。这种方法的优点是，它可以进行端到端测试。

如果您希望始终使用后备机制，或者在生产环境切换后不久必须舍弃初始来源数据库，请采用此方法。

重复写入

如果您选择 Y（写入和读取）或数据访问微服务迁移策略，则已设置此后备方案。此策略更为复杂，因为您需要重构应用或开发连接到数据库实例的工具。

您的应用会同时向初始来源数据库实例和目标数据库实例写入数据，这样您就可以逐步在生产环境中进行切换，直到只使用目标数据库实例为止。如果出现任何问题，您可以将应用重新连接到初始来源，而不会造成停机。如果您认为迁移没有问题，可以舍弃初始来源和重复写入机制。

如果您希望避免迁移停机时间，拥有可靠的后备机制，并且有时间和资源执行应用重构，我们建议您采用这种方法。

执行测试和验证

此步骤的目标是测试和验证以下内容：

• 数据库中的数据已成功迁移。
• 在现有应用切换为使用新的目标实例后，与这些应用集成。

定义关键成功因素，这些因素取决于您的迁移。以下是主观因素的示例：

• 要迁移的数据。对于某些工作负载，可能无需迁移所有数据。您可能不想迁移已汇总、冗余、归档或过时的数据。您可以将这些数据归档到 Cloud Storage 存储桶中，作为备份。
• 可接受的数据丢失百分比。这尤其适用于用于分析工作负载的数据，因为在这种情况下，丢失部分数据不会影响工作负载的总体趋势或性能。
• 数据质量和数量条件，您可以将其应用于来源环境，并在迁移后与目标环境进行比较。
• 效果条件。某些业务交易在目标环境中可能会变慢，但处理时间仍在预期范围内。

来源环境中的存储配置可能无法直接映射到 Google Cloud 环境目标。例如，通用 SSD (gp2 和 gp3) 卷的配置具有 IOPS 突发性能或预配 IOPS SSD。如需比较和正确调整目标实例的大小，请在评估和验证阶段对来源实例进行基准化测试。

在基准测试过程中，您需要对数据库实例应用类似于生产环境的操作序列。在此期间，您可以捕获和处理指标，以衡量和比较来源系统和目标系统的相对性能。

对于传统的基于服务器的配置，请使用在高负载期间观察到的相关测量值。对于 Aurora Serverless 等灵活的资源容量模型，您可以考虑查看历史指标数据，以了解您的扩缩需求。

以下工具可用于测试、验证和数据库基准化：

• HammerDB：开源数据库基准化和负载测试工具。它支持基于行业标准的复杂事务和分析工作负载，并支持多个数据库引擎（TPROC-C 和 TPROC-H）。HammerDB 有详细的文档和广泛的用户社区。您可以跨多个数据库引擎和存储配置共享和比较结果。如需了解详情，请参阅使用 HammerDB 对 SQL Server 执行负载测试和使用 HammerDB 对 Amazon RDS SQL Server 性能进行基准化测试。
• DBT2 基准化工具：专门针对 MySQL 进行基准化。一组数据库工作负载套件可模拟拥有仓库且涉及读写事务混合的公司的应用。如果您想使用现成的联机事务处理 (OLTP) 负载测试，请使用此工具。
• DbUnit：一个开源单元测试工具，用于测试 Java 中的关系型数据库互动。设置和使用都很简单，并且支持多种数据库引擎（MySQL、PostgreSQL、SQL Server 等）。不过，测试执行有时可能会很慢，具体取决于数据库的大小和复杂程度。如果您需要简单的工具，我们建议您使用此工具。
• DbFit：一个开源数据库测试框架，支持测试驱动型代码开发和自动化测试。它使用基本语法来创建测试用例，并提供数据驱动型测试、版本控制和测试结果报告功能。不过，与其他工具相比，它对复杂查询和事务的支持有限，也没有大型社区支持或详尽的文档。如果您的查询不复杂，并且您希望执行自动化测试并将其与持续集成和交付流程集成，我们建议您使用此工具。

如需运行端到端测试（包括测试迁移计划），请务必执行迁移试运行练习。模拟运行会执行全范围的数据库迁移，而无需切换任何生产工作负载，并且具有以下优势：

• 可让您确保所有对象和配置都已正确迁移。
• 帮助您定义和执行迁移测试用例。
• 提供有关实际迁移所需时间的深入分析，以便您可以校准时间表。
• 表示测试、验证和调整迁移计划的机会。有时，您无法提前规划所有事项，因此这有助于您发现任何空缺。

您可以对要迁移的一小部分数据库或整个数据库集执行数据测试。根据数据库总数以及用于实现迁移的工具，您可以决定采用基于风险的方法。使用此方法，您可以对通过同一工具迁移的部分数据库执行数据验证，尤其是当此工具是受管迁移服务时。

为了进行测试，您应该可以访问来源数据库和目标数据库，并执行以下任务：

• 比较来源架构和目标架构。检查所有表和可执行文件是否存在。检查行数并在数据库级别比较数据。
• 运行自定义数据验证脚本。
• 测试迁移后的数据是否也可在已改用目标数据库的应用中看到（迁移后的数据是通过应用读取的）。
• 通过测试各种用例，在已切换的应用和目标数据库之间执行集成测试。此测试包括通过应用读取数据和将数据写入目标数据库，以便工作负载能够完全支持迁移的数据以及新创建的数据。
• 测试最常用数据库查询的性能，以观察是否因配置错误或调整大小错误而导致性能下降。

理想情况下，所有这些迁移测试场景都是自动化的，并且可以在任何来源系统上重复。自动化测试用例套件经过调整，可针对已切换的应用进行测试。

如果您使用的是 Database Migration Service 作为迁移工具，请参阅验证迁移。

数据验证工具

如需执行数据验证，我们建议您使用数据验证工具 (DVT)。DVT 是一种开源 Python CLI 工具，由 Google 提供支持，可在不同环境中提供自动化和可重复的验证解决方案。

DVT 可提供自定义的多级验证函数，以便在表、列和行级别比较来源表和目标表，从而帮助简化数据验证流程。您还可以添加验证规则。

DVT 涵盖了许多 Google Cloud 数据源，包括 AlloyDB for PostgreSQL、BigQuery、Cloud SQL、Spanner、JSON 和 Cloud Storage 上的 CSV 文件。它还可以与 Cloud Run functions 和 Cloud Run 集成，以实现基于事件的触发和编排。

DVT 支持以下类型的验证：

• 架构级比较
• 列（包括“AVG”“COUNT”“SUM”“MIN”“MAX”“GROUP BY”和“STRING_AGG”）
• 行（包括字段比较中的哈希和完全匹配）
• 自定义查询结果比较

如需详细了解 DVT，请参阅 Git 代码库和使用 Google Cloud 的数据验证工具轻松完成数据验证。

执行迁移

迁移任务包括支持从一个系统转移到另一个系统的活动。

请考虑采用以下数据迁移最佳实践：

• 在计划步骤开始和结束时通知相关团队。
• 如果任何步骤用时超出预期，请将已用时间与为该步骤分配的最大时间进行比较。发生这种情况时，向相关团队发布定期中间商更新。
• 如果时间跨度超过为计划中的每一步预留的最大时间量，请考虑回滚。
• 针对迁移和切换计划的每个步骤做出“执行或不执行”的决策。
• 考虑每一步的回滚操作或替代方案。

按照定义的执行任务执行迁移，并参阅所选迁移工具的文档。

执行生产环境切换

具体生产环境切换流程可能会因您选择的迁移策略而异。如果您可以让工作负载停机，则迁移切换开始时，系统会停止对来源数据库的写入。

对于持续复制迁移，您通常需要在切换过程中执行以下高级步骤：

• 停止对来源数据库执行写入操作。
• 排空来源。
• 停止复制过程。
• 部署指向新目标数据库的应用。

使用所选迁移工具迁移数据后，您需要验证目标数据库中的数据。您确认来源数据库和目标数据库已同步，并且目标实例中的数据符合您选择的迁移成功标准。

数据验证通过您的条件后，您就可以执行应用级切换了。部署已重构的工作负载，以使用新的目标实例。您可以部署指向新目标数据库实例的应用版本。部署可以通过滚动更新、分阶段发布或使用蓝绿部署模式来执行。可能会导致应用出现一些停机时间。

请遵循以下最佳实践，以便在生产环境中进行切换：

• 在切换后，监控与目标数据库配合使用的应用。
• 定义监控时间段，以考虑是否需要实施后备计划。
• 请注意，如果您更改某些数据库标志，您的 Cloud SQL 或 AlloyDB for PostgreSQL 实例可能需要重启。
• 请注意，回滚迁移所需的工作量可能比解决目标环境中出现的问题所需的工作量更大。

清理来源环境并配置 Cloud SQL 实例

切换完成后，您可以删除来源数据库。我们建议您在清理来源实例之前执行以下重要操作：

• 为每个来源数据库创建最终备份。这些备份可为您提供来源数据库的最终状态。在某些情况下，备份可能还需要遵守某些数据法规。

• 收集来源实例的数据库参数设置。或者，检查这些数据是否与您在目录构建阶段收集的数据一致。调整目标实例参数，使其与来源实例中的参数一致。

• 从来源实例收集数据库统计信息，并将其与目标实例中的统计信息进行比较。如果统计信息不一致，则很难比较来源实例和目标实例的效果。

在后备场景中，您可能需要将 Cloud SQL 实例上的写入操作复制回原始来源数据库。设置类似于迁移过程，但会以相反的方向运行：初始来源数据库将成为新的目标数据库。

为了在切换后保持来源实例的最新状态，最佳做法是在目标 Cloud SQL 实例上执行的写入操作复制回来源数据库。如果您需要回滚，可以回退到旧的来源实例，从而将数据丢失降到最低。

除了清理来源环境之外，还必须对 Cloud SQL 实例执行以下关键配置：

• 为主实例配置维护期，以控制执行中断性更新的时间。
• 在实例上配置存储空间，以便您至少有 20% 的可用空间来支持 Cloud SQL 可能执行的重要数据库维护操作。如需在可用磁盘空间低于 20% 时收到提醒，请为磁盘利用率指标创建基于指标的提醒政策。

在先前操作完成之前，请勿启动管理操作。

详情请参阅以下内容：

• Cloud SQL 实例维护简介。
• SQL Server 引擎专用设置

迁移后优化您的环境

优化是迁移的最后一个阶段。在此阶段中，您将对优化任务进行迭代，直到目标环境满足您的优化要求。每个迭代的步骤如下：

1. 评估您的当前环境、团队和优化循环。
2. 确定优化要求和目标。
3. 优化您的环境和团队。
4. 调整优化循环。

重复执行这个任务序列，直到达到您的优化目标。

如需详细了解如何优化 Google Cloud 环境，请参阅迁移到 Google Cloud：优化您的环境和 Google Cloud 架构框架：性能优化。

确定优化要求

查看针对您的 Google Cloud 环境的以下优化要求，并选择最适合您工作负载的优化要求。

提高数据库的可靠性和可用性

借助 Cloud SQL，您可以实现与恢复时间目标 (RTO) 和恢复点目标 (RPO) 一致的高可用性和灾难恢复策略。为了提高可靠性和可用性，请考虑以下事项：

• 对于频繁读取的工作负载，请添加只读副本以从主实例分流流量。
• 对于关键任务工作负载，请使用高可用性配置、区域故障切换副本和可靠的灾难恢复配置。
• 对于不太关键的工作负载，自动备份和按需备份就足够了。
• 为防止意外移除实例，请使用实例删除保护。
• 为您的 Cloud SQL for SQL Server 实例启用时间点恢复 (PITR)。
• 使用维护计划自动执行 SQL 数据库备份。

提高数据库基础架构的性价比

为了产生积极的经济影响，您的工作负载必须高效地使用可用资源和服务。您可以考虑采取以下方案：

• 通过执行以下操作，为数据库提供所需的最小存储容量：

  • 如需在数据增长时自动扩缩存储空间容量，请启用存储空间自动扩容。不过，请确保将实例配置为在高峰工作负载期间具有一定的缓冲空间。请注意，数据库工作负载往往会随着时间的推移而增加。

• 确定可能高估的资源：

  • 调整 Cloud SQL 实例的大小可以降低基础架构成本，而不会对容量管理策略增加额外风险。
  • Cloud Monitoring 提供预定义的信息中心，可帮助您确定许多 Google Cloud 组件（包括 Cloud SQL）的健康状况和容量利用率。如需了解详情，请参阅创建和管理自定义信息中心。

• 找出不需要高可用性或灾难恢复配置的实例，并将其从基础架构中移除。

• 移除不再需要的表和对象。您可以将其存储在完整备份或归档 Cloud Storage 存储桶中。

• 评估适合您的使用场景且成本效益最高的存储类型（SSD 或 HDD）。

  • 对于大多数使用场景而言，SSD 是最有效且最经济实惠的选择。
  • 如果您的数据集很大（10 TB 或更大）、对延迟不敏感或不常访问，HDD 可能更合适。
  • 如需了解详情，请参阅在 SSD 和 HDD 存储设备之间选择。

• 为具有可预测资源需求的工作负载购买承诺使用折扣。

• 使用 Active Assist 获取费用数据分析和建议。

  如需了解详情和选项，请参阅以更少的资源做更多事情：推出通过 Active Assist 提供的 Cloud SQL 费用优化建议。

如需降低许可费用（尤其是 Cloud SQL for SQL Server 的许可费用），请考虑以下事项：

• 如果服务等级协议 (SLA)符合您的要求，请迁移到 SQL Server 标准版。
• 关闭并发多线程 (SMT)，并增加 25% 的核心数。额外的核心可能会弥补关闭 SMT 带来的任何性能影响。此策略有助于降低许可费用，但可能会影响实例的性能。我们建议您对实例执行负载测试，以确保服务等级协议 (SLA) 不会受到影响。
• 请考虑从 Cloud SQL for SQL Server 迁移到 Cloud SQL for PostgreSQL 或 AlloyDB for PostgreSQL，具体取决于您的工作负载。

提高数据库基础架构的性能

与数据库相关的轻微性能问题通常可能会影响整个操作。如需保持和提高 Cloud SQL 实例的性能，请考虑遵循以下准则：

• 如果您有大量数据库表，这些表可能会影响实例性能和可用性，并导致实例脱离其服务等级协议 (SLA) 覆盖范围。

• 确保您的实例在内存或 CPU 方面不受限制。

  • 对于需要高性能的工作负载，请确保您的实例至少有 60 GB 的内存。
  • 如果数据库插入、更新或删除操作缓慢，请检查写入者和数据库的位置；长距离发送数据会导致延迟。

• 通过使用 Cloud Monitoring（或类似的数据库引擎内置功能）中的预定义查询数据分析信息中心，提升查询性能。确定最昂贵的命令并尝试对其进行优化。

• 防止数据库文件过大。 请以 MB 为单位设置 autogrow，而不是使用百分比，并采用符合要求的增量。

• 检查读取器和数据库位置。延迟对读取性能的影响大于对写入性能的影响。

• 防止数据和索引碎片化。根据数据更改频率，设置在 SQL Server 中重新构建索引的时间表。

• 更改 SQL Server 引擎专用设置，以使其适用于 Cloud SQL。

• 如需了解索引和统计信息维护，请参阅 SQL Server 维护解决方案。

• 定期更新 Cloud SQL for SQL Server 上的统计信息。

• 考虑对读取副本执行 ETL 操作，因为这些操作可能会影响实例的缓存。

如需详细了解如何提升性能，请参阅“诊断问题”中的性能部分，以及 Cloud SQL - SQL Server 性能分析和查询优化。

提高数据库可观测性功能

诊断和排查连接到数据库实例的应用中的问题可能具有挑战性且耗时。因此，所有团队成员都可以在一个集中位置查看数据库和实例级别发生的情况，这一点至关重要。您可以通过以下方式监控 Cloud SQL 实例：

• Cloud SQL 使用内置内存自定义代理来收集查询遥测。

  • 使用 Cloud Monitoring 收集关于您的服务和您使用的 Google Cloud 资源的衡量数据。Cloud Monitoring 包含多个 Google Cloud 产品的预定义信息中心，包括 Cloud SQL 监控信息中心。
  • 您可以创建自定义信息中心，以帮助您监控指标和设置提醒政策，以便您能够及时收到通知。
  • 或者，您可以考虑使用与 Google Cloud 集成的第三方监控解决方案，例如 Datadog 和 Splunk。

• Cloud Logging 会从常见应用组件收集日志记录数据。

• Cloud Trace 可从应用收集延迟数据和已执行的查询计划，以帮助您跟踪请求如何在您的应用中传播。

• 数据库中心提供 AI 辅助的集中式数据库舰队概览。您可以监控数据库的运行状况、可用性配置、数据保护、安全性和行业合规性。

• 查看和查询 Cloud SQL 实例的日志。

• 观察数据库的状态，以帮助您提升环境的性能并排查最终问题。

Cloud SQL 常规最佳实践和操作指南

应用 Cloud SQL 最佳实践来配置和调整数据库。

一些重要的 Cloud SQL 常规建议如下：

• 如果您有大型实例，我们建议您尽可能将其拆分为较小的实例。
• 配置存储空间以支持重要的数据库维护。 请确保您至少有 20% 的可用空间以支持 Cloud SQL 可能执行的重要数据库维护操作。
• 数据库表过多可能会影响数据库升级时间。理想情况下，每个实例的表数应少于 1 万个。
• 为实例选择合适的大小，以考虑事务（二进制）日志保留量，尤其是对于写入活动较多的实例。

为了能够高效地处理您可能遇到的任何数据库性能问题，请遵循以下准则，直到问题得到解决：

扩展基础架构：增加资源（例如磁盘吞吐量、vCPU 和 RAM）。根据紧迫程度以及团队的可用性和经验，垂直扩缩实例可以解决大多数性能问题。之后，您可以在测试环境中进一步调查问题的根本原因，并考虑解决问题的方案。

执行并安排数据库维护操作：索引碎片整理、统计信息更新、真空分析和重新为频繁更新的表建立索引。检查是否以及何时上次执行了这些维护操作，尤其是对受影响的对象（表、索引）执行的操作。了解是否发生了与正常数据库活动不同的变化。例如，最近添加了新列或对表进行了大量更新。

执行数据库调优和优化：数据库中的表是否结构正确？列的数据类型是否正确？您的数据模型是否适合工作负载的类型？调查慢查询及其执行计划。它们是否使用了可用的索引？检查是否有索引扫描、锁定和等待其他资源。不妨考虑添加索引来支持您的关键查询。消除非关键索引和外键。不妨考虑重写复杂查询和联接。解决问题所需的时间取决于您的团队的经验和可用性，可能需要数小时到数天的时间。

横向扩容读取：考虑使用只读副本。如果纵向扩缩无法满足您的需求，并且数据库调优和优化措施也无济于事，请考虑横向扩缩。将应用的读取查询路由到只读副本可提高数据库工作负载的整体性能。不过，您可能需要付出额外的工作来更改应用以连接到只读副本。

数据库重构：考虑对数据库进行分区和编入索引。此操作所需的工作量远大于数据库调优和优化，并且可能涉及数据迁移，但可以作为长期解决方案。有时，数据模型设计不当可能会导致性能问题，而垂直扩容可以部分抵消这些问题。不过，合适的数据模型是长期解决方案。考虑对表进行分区。尽可能归档不再需要的数据。规范化数据库结构，但请注意，非规范化也能提高性能。

数据库分片：您可以通过对数据库进行分片来扩展写入。分片是一项复杂的操作，涉及以特定方式重新构建数据库和应用以及执行数据迁移。您可以使用特定的分区标准，将数据库实例拆分为多个较小的实例。这些条件可以基于客户或主题。通过此选项，您可以横向扩缩写入和读取。不过，这会增加数据库和应用工作负载的复杂性。这也可能会导致称为热点的不平衡分片，这会抵消分片带来的好处。

具体而言，对于 Cloud SQL for SQL Server，请考虑以下最佳实践：

• 如需更新 SQL Server 设置以便在 Cloud SQL 中获得最佳性能，请参阅 SQL Server 设置。
• 在部署 SQL Server 之前确定 I/O 子系统的容量。

• 如果您有大型实例，请尽可能将其拆分为较小的实例：

  • 大小为 4 TB 或更大的磁盘可提供更高的吞吐量和 IOPS。
  • 较高的 vCPU 可提供更高的 IOPS 和吞吐量。使用更高的 vCPU 时，请监控数据库等待并行性，其等待时长可能也会增加。

• 如果在某些情况下性能下降，请关闭 SMT。例如，如果应用执行的线程成为瓶颈，而 CPU 架构无法有效处理此问题。

• 根据数据更改频率，设置重新整理或重新构建索引的时间表。

• 设置适当的填充因子以减少碎片化。监控 SQL Server 是否存在可能提升性能的缺失索引。

• 防止数据库文件过大。 请以 MB 为单位设置 autogrow，而不是使用百分比，并采用符合要求的增量。此外，在达到 autogrow 阈值之前主动管理数据库增长。

• 如需自动扩缩存储空间容量，请启用存储空间自动扩容功能。在数据库和实例空间不足时，Cloud SQL 可以增加存储空间。

• 确保您了解所处理数据的语言区域要求、排序顺序以及大小写和重音符号敏感性。为服务器、数据库、列或表达式选择排序规则时，您需要为数据分配某些特征。

• 递归哈希联接或哈希释放会导致服务器性能下降。如果您在跟踪记录中看到许多哈希警告事件，请更新要联接的列的统计信息。如需了解详情，请参阅哈希警告事件类。

如需了解详情，请参阅 Cloud SQL for SQL Server 的一般最佳实践和操作指南。

后续步骤

• 了解其他 AWS 到 Google Cloud 的迁移过程。
• 了解如何将 AWS 和 Azure 服务与 Google Cloud 进行比较。
• 了解何时寻求迁移帮助。
• 如需查看更多参考架构、图表和最佳实践，请浏览 Cloud 架构中心。

贡献者

作者：

• Alex Cârciu | 解决方案架构师
• Marco Ferrari | 云解决方案架构师

其他贡献者：

• Derek Downey | 开发者关系工程师
• Paweł Krentowski | 技术文档工程师
• Matthew Smith | 云战略工程师
• Somdyuti Paul | 数据管理专家
• Zach Seils | 网络专家