从 AWS 迁移到 Google Cloud：从 Amazon RDS 和 Amazon Aurora for PostgreSQL 迁移到 Cloud SQL 和 AlloyDB for PostgreSQL

Last reviewed 2024-09-12 UTC

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

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

本文档重点介绍同构数据库迁移，即来源数据库和目标数据库采用相同数据库技术的迁移。在本迁移指南中，来源数据库是 Amazon RDS 或 Amazon Aurora for PostgreSQL，目标数据库是 Cloud SQL for PostgreSQL 或 AlloyDB for PostgreSQL。

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

如需迁移到 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. 验证迁移计划。

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

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

构建 Amazon RDS 或 Amazon Aurora 实例的清单

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

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

基准测试有助于您更好地了解要迁移的工作负载，并有助于为迁移目标环境定义正确的架构。收集有关性能的信息非常重要，有助于估算 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 for PostgreSQL 实例的访问权限，并限制 VPC 内的数据。

  • 为实例打补丁并对其进行配置。您现有的部署工具可能需要更新。例如，您可能在 Amazon 参数组或 Amazon 选项组中使用自定义配置设置。您可能需要调整预配工具，以使用 Cloud Storage 或 Secret Manager 读取此类自定义配置列表。

  • 管理监控和提醒基础架构。您的 Amazon 来源数据库实例的指标类别可在迁移过程中提供可观测性。指标类别可能包括 Amazon CloudWatch、性能数据分析、增强型监控和操作系统进程列表。

完成评估

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

规划和构建基础

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

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

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

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

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

如果您计划使用 Database Migration Service 进行迁移，请参阅 Cloud SQL for PostgreSQL 的网络方法，了解适用于迁移场景的网络配置。

监控和提醒

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

将 Amazon RDS 和 Amazon Aurora for PostgreSQL 实例迁移到 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL

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

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

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

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

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

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

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

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

  8. 执行迁移。

  9. 执行生产环境切换。

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

  11. 执行调优和优化。

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

选择迁移策略

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

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

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

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

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

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

流程图，可帮助您选择迁移策略。

上图显示了以下决策点：

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

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

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

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

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

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

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

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

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

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

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

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

选择迁移工具

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

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

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

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

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

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

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

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

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

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

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

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

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

对于一次性迁移到 Cloud SQL for PostgreSQL 或 AlloyDB for PostgreSQL 的情况，我们建议您使用数据库引擎备份，从来源实例中导出数据，并将这些数据导入目标实例。Database Migration Service 不支持一次性迁移作业。

内置数据库引擎备份

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

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

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

  • 备份很容易出错，尤其是手动执行时。
  • 如果没有正确管理快照，数据可能会不安全。
  • 备份缺乏适当的监控功能。
  • 在迁移多个数据库时，需要花费精力来扩展备份。

您可以使用 PostgreSQL 内置的备份实用程序 pg_dump 和 pg_dumpall 来迁移 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL。不过，pg_dump 和 pg_dumapall 实用程序存在以下常规限制：

  • 应使用内置备份实用程序来迁移大小不超过 500 GB 的数据库。转储和恢复大型数据库可能需要很长时间，并且可能需要大量的磁盘空间和内存。
  • pg_dump 实用程序不包含用户和角色。如需迁移这些用户账号和角色，您可以使用 pg_dumpall 实用程序。
  • Cloud Storage 支持的单个对象大小上限为 5 兆字节 (TB)。如果您的数据库大于 5 TB，则导出到 Cloud Storage 的操作会失败。在这种情况下，您需要将导出文件细分为几个较小的部分。

如果您选择使用这些实用程序，请考虑以下限制和最佳实践：

  • 压缩数据以降低费用和传输时长。将 --jobs 选项与 pg_dump 命令结合使用，以同时运行指定数量的转储作业。
  • 将 -z 选项与 pg_dump 命令结合使用，以指定要使用的压缩级别。此选项的可接受值范围为 0 到 9。默认值为以 6 级压缩。值越高，转储文件的大小就越小，但客户端主机的资源消耗就越高。如果客户端主机有足够的资源，更高的压缩级别可以进一步减小转储文件的大小。
  • 创建 SQL 转储文件时使用正确的标志。
  • 验证导入的数据库。在恢复过程中，监控 pg_restore 实用程序的输出，查看是否有任何错误消息。查看 PostgreSQL 日志，了解恢复过程中是否存在任何警告或错误。运行基本查询和表格计数以验证数据库完整性。

如需进一步了解限制和最佳实践，请参阅以下资源：

其他预定维护迁移方法

使用内置备份实用程序以外的其他方法，可能会让您在预定维护迁移过程中拥有更大的控制权和灵活性。借助这些其他类型的方法，您可以在迁移数据时对数据执行转换、检查或其他操作。您可以将多个实例或数据库合并到单个实例或数据库中。合并实例有助于降低运维成本并解决可扩缩性问题。

备份实用程序的一种替代方法是使用平面文件来导出和导入数据。如需详细了解如何导入平面文件，请参阅使用 CSV 文件导出和导入 Cloud SQL for PostgreSQL。

另一种替代方法是使用托管式导入设置从外部 PostgreSQL 数据库复制数据。使用托管式导入时，系统会将初始数据从外部数据库加载到 Cloud SQL for PostgreSQL 实例中。此初始加载使用从外部服务器（RDS 或 Aurora 实例）中提取数据并将其直接导入 Cloud SQL for PostgreSQL 实例的服务。如需了解详情，请参阅使用托管式导入设置从外部数据库复制。

进行一次性数据迁移的另一种方法是将表从来源 PostgreSQL 数据库导出到 CSV 或 SQL 文件。然后，您可以将 CSV 或 SQL 文件导入 Cloud SQL for PostgreSQL 或 AlloyDB for PostgreSQL。如需导出来源实例的日期，您可以使用 PostgreSQL 的 aws_s3 扩展程序。或者，您也可以使用 Amazon Database Migration Service 和 S3 存储桶作为目标。如需详细了解此方法，请参阅以下资源：

您还可以手动将数据导入 AlloyDB for PostgreSQL 实例。支持的格式如下：

  • CSV：使用此文件格式时，此格式的每个文件都包含数据库中一个表的内容。您可以使用 psql 命令行程序将数据加载到 CSV 文件中。如需了解详情，请参阅导入 CSV 文件。
  • DMP：此文件格式包含整个 PostgreSQL 数据库的归档文件。您可以使用 pg_restore 实用程序从此文件导入数据。如需了解详情，请参阅导入 DMP 文件。
  • SQL：此文件格式包含 PostgreSQL 数据库的文本重构。此文件中的数据是使用 psql 命令行进行处理。如需了解详情，请参阅导入 SQL 文件。

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

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

流程图，帮助您选择用于持续复制迁移的工具。

上图显示了以下决策点：

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

    • 如果是，那么在复制步骤执行期间，您是否可以承受几秒钟的写入停机时间？

      • 如果是，请使用 Database Migration Service。
      • 如果不是，请探索其他迁移选项。

    • 如果没有，您必须评估数据库引擎内置复制功能是否受支持：

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

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

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

Database Migration Service 提供了一种专门的作业类型，用于持续迁移。这些持续迁移作业支持高保真迁移到 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL。

使用 Database Migration Service 迁移到 Cloud SQL for PostgreSQL 或 AlloyDB for PostgreSQL 时，每个目标实例都有一些前提条件和限制：

数据库引擎内置复制

数据库引擎内置复制是持续迁移的 Database Migration Service 替代方案。

数据库复制表示将数据从一个称为主数据库的数据库复制和分发到其他称为副本的数据库的过程。其目的是提高数据可访问性，并提高数据库系统的容错性和可靠性。虽然数据库迁移不是数据库复制的主要目的，但它可以作为实现此目标的工具而成功使用。数据库复制通常是一个持续的过程，在主数据库中插入、更新或删除数据时会实时发生。数据库复制可以作为一次性操作执行，也可以作为一系列批量操作执行。

大多数现代数据库引擎都实现了不同的数据库复制方式。一种类型的复制可以通过复制主服务器的预写日志或事务日志并将其发送到副本来实现。这种方法称为物理或二进制复制。其他复制类型的工作原理是分发主数据库收到的原始 SQL 语句，而不是复制文件系统级别的更改。这类复制类型称为逻辑复制。对于 PostgreSQL，还有一些第三方扩展（例如 pglogical）实现了依赖于预写式日志记录 (WAL) 的逻辑复制。

Cloud SQL 支持 PostgreSQL 复制。不过，也存在一些前提条件和限制。

以下是 Cloud SQL for PostgreSQL 的限制和前提条件：

  • 支持以下 Amazon 版本：

    • Amazon RDS 9.6.10 及更高版本、10.5 及更高版本、11.1 及更高版本、12、13、14
    • Amazon Aurora 10.11 及更高版本、11.6 及更高版本、12.4 及更高版本，以及 13.3 及更高版本

  • 必须配置外部服务器的防火墙以允许已为 VPC 网络的专用服务访问通道分配的内部 IP 范围。Cloud SQL for PostgreSQL 副本数据库使用 VPC 网络作为其专用网络。

  • 必须配置来源数据库的防火墙以允许已为 VPC 网络的私有服务连接分配的整个内部 IP 范围。Cloud SQL for PostgreSQL 目标实例会在 IpConfiguration 设置的 privateNetwork 字段中使用此 VPC 网络。

  • 在 Cloud SQL for PostgreSQL 实例上安装 pglogical 扩展程序时，请确保您已将 enable_pglogical 标志设置为 on（例如 cloudsql.enable_pglogical=on）。

  • 确保 shared_preload_libraries 参数在来源实例中包含 pglogical 扩展程序（例如 shared_preload_libraries=pg_stat_statements,pglogical）。将 rds.logical_replication 参数设置为 1。此设置会在逻辑级别启用预写日志。

    这些更改需要重启主实例。

如需详细了解如何使用 Cloud SQL for PostgreSQL 进行复制，请参阅复制（适用于 PostgreSQL）部分中的外部服务器核对清单，并参阅 Cloud SQL 官方文档中的为 PostgreSQL 设置逻辑复制和解码。

AlloyDB for PostgreSQL 支持通过 pglogical 扩展程序进行复制。如需为复制启用 pglogical 扩展程序，您可以使用 CREATE EXTENSION 命令。在使用该命令之前，您必须先在要使用该扩展程序的 AlloyDB for PostgreSQL 实例中将数据库标志 alloydb.enable_pglogical 和 alloydb.logical_decoding 设置为 on。设置这些标志需要重启实例。

其他持续复制迁移方法

您可以使用 Datastream 复制来源 PostgreSQL 实例的近实时更改。Datastream 使用变更数据捕获 (CDC) 和复制来复制并同步数据。然后，您可以使用 Datastream 从 Amazon RDS 和 Amazon Aurora 进行持续复制。您可以使用 Datastream 将 PostgreSQL 实例中的更改复制到 BigQuery 或 Cloud Storage。然后，您可以使用 Dataflow Flex 模板或 Dataproc 将这些复制的数据导入到 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL 实例中。

如需详细了解如何使用 Datastream 和 Dataflow，请参阅以下资源：

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

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

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

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

  • 优点：

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

  • 缺点：

如需详细了解 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 或 Amazon Aurora 实例的准备工作和前提条件
  • 来源数据库准备工作和前提条件
  • Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL 实例设置
  • 迁移专用设置

Amazon RDS 或 Amazon Aurora 实例准备和前提条件

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

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

  • 您可能需要配置一个新的安全组，以允许在所需端口上进行远程连接，并将该安全组应用于您的 Amazon RDS 或 Amazon Aurora 实例：

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

  • 如果您要从 Amazon RDS 迁移，请确保您有足够的可用磁盘空间来缓冲 Amazon RDS 实例上的全加载操作期间的前写日志。 如果您要从 Amazon RDS 迁移，请确保您有足够的可用磁盘在 Amazon RDS 实例上执行完全加载操作期间缓冲预写式日志。

  • 对于持续复制（通过 CDC 流式传输更改），您必须使用完整的 RDS 实例，而不是只读副本。

  • 如果您使用的是内置复制功能，则需要为 PostgreSQL 设置 Amazon RDS 或 Amazon Aurora 实例以进行复制。内置复制或使用内置复制功能的工具需要 PostgreSQL 的逻辑复制。

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

如需详细了解实例准备和前提条件，请参阅设置 PostgreSQL 的复制外部服务器。

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

  • 如果您选择使用 Database Migration Service，请先配置来源数据库，然后再连接到该数据库。如需了解详情，请参阅为 PostgreSQL 配置来源和将 PostgreSQL 来源配置为 AlloyDB for PostgreSQL。

  • 对于没有主键的表，在 Database Migration Service 迁移初始备份后，仅在 CDC 阶段将 INSERT 语句迁移到目标数据库。系统不会为这些表迁移 DELETE 和 UPDATE 语句。

  • 请注意，Database Migration Service 无法复制大型对象，因为 PostgreSQL 中的逻辑解码功能不支持对大型对象进行解码更改。

  • 如果您选择使用内置复制，请注意逻辑复制在数据定义语言 (DDL) 命令、序列和大型对象方面存在一定的限制。主键必须存在于要为其启用 CDC 且要进行大量更新的表中，或者必须添加到这些表中。

  • 某些第三方迁移工具要求所有大型对象列都可以为空。任何 NOT NULL 大型对象列都需要在迁移期间移除该约束条件。

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

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

Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL 实例设置

为了使目标实例达到与来源实例相似的性能水平，请选择目标 PostgreSQL 数据库实例的大小和规格以与来源实例相匹配。请特别注意磁盘大小和吞吐量、每秒输入/输出操作次数 (IOPS) 以及虚拟 CPU (vCPU) 数量。不正确的大小可能会导致较长的迁移时间、数据库性能问题、数据库错误和应用性能问题。在决定使用 Cloud SQL for PostgreSQL 或 AlloyDB for PostgreSQL 实例时，请注意磁盘性能取决于磁盘大小和 vCPU 数量。

在创建 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL 实例之前，您必须确认以下属性和要求。如果您想稍后更改这些属性和要求，则需要重新创建实例。

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

  • 迁移到 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL 上的匹配主要版本。例如，如果您在 Amazon RDS 或 Amazon Aurora 上使用 PostgreSQL 14.x，则应迁移到 Cloud SQL 或 AlloyDB for PostgreSQL for PostgreSQL 14.x 版。

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

  • 查看数据库引擎专用配置标志，并比较其来源实例值和目标实例值。请确保您了解它们的影响，以及它们是否需要相同。例如，在使用 PostgreSQL 时，我们建议您将来源数据库中 pg_settings 表中的值与 Cloud SQL 和 AlloyDB for PostgreSQL 实例中的值进行比较。根据需要更新目标数据库实例的标志设置，以复制来源设置。

  • 根据工作负载的性质，您可能需要启用特定扩展程序来支持您的数据库。如果您的工作负载需要这些扩展程序，请查看支持的 PostgreSQL 扩展程序以及如何在 Cloud SQL 和 AlloyDB for PostgreSQL 中启用这些扩展程序。

如需详细了解 Cloud SQL for PostgreSQL 设置，请参阅实例配置选项、数据库引擎专用标志和支持的扩展程序。

如需详细了解 AlloyDB for PostgreSQL 设置，请参阅支持的数据库标志和支持的扩展程序。

迁移专用设置

如果您可以承受停机时间，可以将 SQL 转储文件导入 Cloud SQL 和 AlloyDB for PostgreSQL。在这种情况下，您可能需要创建一个 Cloud Storage 存储桶来存储数据库转储。

如果您使用复制，则必须确保 Cloud SQL 和 AlloyDB for PostgreSQL 副本数据库可以访问您的主（来源）数据库。您可以使用已记录的连接选项来获得此访问权限。

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

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

如果您要迁移到 AlloyDB for PostgreSQL，请考虑使用 Cloud SQL for PostgreSQL 实例作为后备场景的潜在目标。使用 pglogical 扩展程序设置对该 Cloud SQL 实例的逻辑复制。

如需了解详情，请参阅以下资源：

定义执行任务

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

内置数据库引擎备份

使用 pg_dump 实用程序创建备份。如需详细了解如何使用此实用程序导入和导出数据，请参阅以下资源：

Database Migration Service 迁移作业

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

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

在 Database Migration Service 中，迁移从初始架构转储和恢复（不包含索引和约束条件）开始，然后是数据复制操作。数据复制完成后，系统会恢复索引和约束条件。最后，系统会开始从来源数据库实例到目标数据库实例的持续复制更改。

Database Migration Service 使用 pglogical 扩展程序从来源数据库实例复制到目标数据库实例。在迁移开始时，此扩展程序会通过要求对来源 Amazon RDS 或 Amazon Aurora 实例中的所有表进行独占短期锁定来设置复制。因此，我们建议您在数据库最不繁忙时开始迁移，并在转储和复制阶段避免对来源数据库执行语句，因为 DDL 语句不会被复制。如果您必须执行 DDL 操作，请使用“pglogical”函数在来源实例上运行 DDL 语句，或者在迁移目标实例上手动运行相同的 DDL 语句，但必须在初始转储阶段完成后再进行。

使用 Database Migration Service 进行迁移的过程以升级操作结束。升级数据库实例会将目标数据库与来自来源数据库的更改流断开连接，然后将现在的独立目标实例升级为主实例。此方法也称为生产环境切换。

如需详细了解迁移设置过程，请参阅 PostgreSQL 和 PostgreSQL 到 AlloyDB for PostgreSQL 的快速入门指南。

数据库引擎内置复制

Cloud SQL 支持两种类型的逻辑复制：PostgreSQL 的内置逻辑复制和通过 pglogical 扩展程序进行的逻辑复制。对于 AlloyDB for PostgreSQL，我们建议使用 pglogical 扩展程序进行复制。每种类型的逻辑复制都有自己的功能和限制。

内置逻辑复制具有以下功能和限制：

  • 该功能适用于 PostgreSQL 10 及更高版本。
  • 所有更改和列都会被复制。发布内容是在表级别进行定义。
  • 数据仅从基表复制到基表。
  • 它不会执行序列复制。
  • 当有许多表没有主键时，这是推荐的复制类型。设置内置 PostgreSQL 逻辑复制。对于没有主键的表，请应用 REPLICA IDENTITY FULL 形式，以便内置复制功能使用整个行作为唯一标识符，而不是主键。

pglogical 逻辑复制具有以下功能和限制：

  • 它适用于所有 PostgreSQL 版本，并提供跨版本支持。
  • 行过滤可在来源上使用。
  • 它不会复制 UNLOGGED 和 TEMPORARY 表。
  • 表必须具有主键或唯一键，才能捕获 UPDATE 和 DELETE 更改。
  • 序列复制功能已推出。
  • 复制可能会延迟。
  • 如果存在多个发布者或复制数据与本地更改之间存在冲突，它会提供冲突检测和可配置的解决方案。

如需了解如何从外部服务器（例如 Amazon RDS 或 Amazon Aurora for PostgreSQL）设置内置 PostgreSQL 逻辑复制，请参阅以下资源：

第三方工具

为您选择的第三方工具定义任何执行任务。

本部分重点介绍 Striim 示例。Striim 使用从各种来源获取数据、处理数据，然后将数据传送到其他应用或目标的应用。

您可以使用一个或多个流程在自定义应用中组织这些迁移流程。如需编写自定义应用的代码，您可以选择使用图形化编程工具或 Tungsten Query Language (TQL) 编程语言。

如需详细了解如何使用 Striim，请参阅以下资源：

如果您决定使用 Striim 迁移数据，请参阅以下有关如何使用 Striim 将数据迁移到 Google Cloud 的指南：

定义后备场景

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

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

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

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

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

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

简单后备

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

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

反向复制

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

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

正向复制

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

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

重复写入

如果您选择 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 作为迁移工具，请参阅 PostgreSQL 或 PostgreSQL 到 AlloyDB for PostgreSQL 版本的“验证迁移”主题。

数据验证工具

如需执行数据验证，我们建议您使用数据验证工具 (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 或 AlloyDB for PostgreSQL 实例

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

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

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

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

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

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

或者，您也可以使用另一个实例，并将更改复制到该实例。例如，如果 AlloyDB for PostgreSQL 是迁移目标，请考虑针对后备场景设置对 Cloud SQL for PostgreSQL 实例的复制。

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

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

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

如需详细了解 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL 实例的维护和最佳实践，请参阅以下资源：

如需详细了解维护和最佳实践，请参阅关于 Cloud SQL 实例维护。

迁移后优化您的环境

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

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

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

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

确定优化要求

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

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

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

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

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

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

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

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

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

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

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

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

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

从 Amazon RDS 和 Aurora for PostgreSQL 迁移到 Cloud SQL for PostgreSQL 时，请考虑以下准则：

  • 使用缓存来提高读取性能。从 pg_stat_database 视图检查各种统计信息。例如，blks_hit / (blks_hit + blks_read) 比率应高于 99%。如果此比率不超过 99%，请考虑增加实例 RAM 的大小。如需了解详情，请参阅 PostgreSQL 统计信息收集器。
  • 释放空间并防止索引性能不佳。根据数据变化的频率，您可以设置一个时间表，以便在 Cloud SQL for PostgreSQL 上运行 VACUUM 命令。
  • 使用 Cloud SQL 企业 Plus 版可提高机器配置限制和数据缓存。如需详细了解 Cloud SQL 企业 Plus 版，请参阅 Cloud SQL 版本简介。
  • 改用 AlloyDB for PostgreSQL。如果您切换，则可以获得完全的 PostgreSQL 兼容性、更好的事务处理以及处理数据库支持的快速事务分析工作负载。您还可以通过使用索引顾问功能来获取有关新索引的建议。

如需详细了解如何提高 Cloud SQL for PostgreSQL 数据库基础架构的性能，请参阅适用于 PostgreSQL 的 Cloud SQL 性能改进文档。

从 Amazon RDS 和 Aurora for PostgreSQL 迁移到 AlloyDB for PostgreSQL 时，请考虑遵循以下准则，以提高 AlloyDB for PostgreSQL 数据库实例的性能：

提高数据库可观测性功能

诊断和排查连接到数据库实例的应用中的问题可能具有挑战性且耗时。因此，所有团队成员都可以在一个集中位置查看数据库和实例级别发生的情况，这一点至关重要。您可以通过以下方式监控 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 和 AlloyDB for PostgreSQL 的常规最佳实践和操作指南

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

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

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

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

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

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

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

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

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

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

对于 Cloud SQL for PostgreSQL 和 AlloyDB for PostgreSQL，请考虑采用以下最佳实践：

  • 如需从主实例分流流量，请添加只读副本。您还可以使用负载均衡器（如 HAProxy）来管理发送到副本的流量。不过，请避免创建过多的副本，因为这会妨碍 VACUUM 操作。如需详细了解如何使用 HAProxy，请访问官方 HAProxy 网站。
  • 通过增加系统内存和 maintenance_work_mem 参数来优化 VACUUM 操作。增加系统内存意味着可以在每次迭代中批量处理更多的元组。
  • 由于较大的索引会占用大量时间进行索引扫描，因此请将 INDEX_CLEANUP 参数设置为 OFF，以便快速清理和冻结表数据。
  • 使用 AlloyDB for PostgreSQL 时，请使用 AlloyDB for PostgreSQL 系统数据分析信息中心信息中心和审核日志。AlloyDB for PostgreSQL System Insights 信息中心会显示您使用的资源的指标，并允许您监控这些资源。如需了解详情，请参阅 AlloyDB for PostgreSQL 文档中的监控实例主题中的指南。

如需了解详情，请参阅以下资源：

后续步骤

贡献者

作者：

其他创作贡献者：Somdyuti Paul | 数据管理专家