Google Cloud 提供了工具、产品、指导和专业服务,可帮助您从 Amazon Relational Database Service (RDS) 或 Amazon Aurora 迁移到 Cloud SQL for MySQL。
本文档适合希望规划、实施和验证数据库迁移项目的云和数据库管理员。它还适用于正在评估迁移机会并希望了解迁移示例的决策者。
本文档重点介绍同构数据库迁移,即来源数据库和目标数据库采用相同数据库技术的迁移。在本迁移指南中,来源数据库是 Amazon RDS 或 Amazon Aurora for MySQL,目标数据库是 Cloud SQL for MySQL。
本文档是关于从 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 ,例如,您可能会先迁移一部分工作负载,然后再迁移其他工作负载。对于每个单独的迁移迭代,您都需要遵循一般迁移框架的各个阶段:
- 评估和发现工作负载和数据。
- 在 Google Cloud上规划和构建基础。
- 将您的工作负载和数据迁移到 Google Cloud。
- 优化您的 Google Cloud 环境。
如需详细了解此框架的各个阶段,请参阅迁移到 Google Cloud:使用入门。
如需设计有效的迁移计划,建议您验证计划的每个步骤,并确保您具有回滚策略。为了帮助验证您的迁移计划,请参阅迁移到 Google Cloud:验证迁移计划的最佳实践。
评估来源环境
在评估阶段,您需要确定从来源环境迁移到 Google Cloud的要求和依赖项。
评估阶段对于成功迁移而言至关重要。您需要深入了解需要迁移的工作负载,它们的要求和依赖项以及您当前的环境。您需要清楚自己的起点,然后才能开始成功地计划和执行 Google Cloud迁移。
评估阶段包括以下任务:
- 构建一个完整的工作负载清单。
- 根据工作负载的属性和依赖项对工作负载进行分类。
- 为您的团队开展 Google Cloud培训和指导。
- 在 Google Cloud上构建实验和概念验证。
- 计算目标环境的总拥有成本 (TCO)。
- 为工作负载选择迁移策略。
- 选择迁移工具。
- 定义迁移计划和时间表。
- 验证迁移计划。
数据库评估阶段可帮助您选择与来源数据库匹配的目标 Cloud SQL 数据库实例的大小和规格,以满足类似的性能需求。请特别注意磁盘大小、吞吐量、IOPS 和 vCPU 数量。由于目标数据库实例大小设置不正确,迁移可能会遇到困难或失败。不正确的大小可能会导致较长的迁移时间、数据库性能问题、数据库错误和应用性能问题。在决定使用 Cloud SQL 实例时,请注意磁盘性能取决于磁盘大小和 vCPU 数量。
以下部分依赖于迁移到 Google Cloud:评估和发现您的工作负载,并整合该文档中的信息。
构建 Amazon RDS 或 Amazon Aurora 实例的清单
如需定义迁移范围,您可以创建清单并收集有关 Amazon RDS 或 Amazon Aurora 实例的信息。我们建议您使用专用工具来自动执行此流程,因为手动方法容易出错,并且可能会导致错误的假设。
Amazon RDS 或 Amazon Aurora 与 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 内的数据。
为实例打补丁并对其进行配置:您现有的部署工具可能需要更新。例如,您可能在 Amazon 参数组或 Amazon 选项组中使用自定义配置设置。您可能需要调整预配工具,以使用 Google Cloud Storage 或 Secret Manager 读取此类自定义配置列表。
管理监控和提醒基础架构:您的 Amazon 来源数据库实例的指标类别可在迁移过程中提供可观测性。指标类别可能包括 Amazon CloudWatch、性能数据分析、增强型监控和操作系统进程列表。
完成评估
从 Amazon RDS 或 Amazon Aurora 环境构建清单后,请完成评估阶段的其余活动,如迁移到 Google Cloud:评估和发现您的工作负载中所述。
规划和构建基础
在规划和构建阶段,您需要预配和配置基础架构以执行以下操作:
- 在 Google Cloud 环境中支持您的工作负载。
- 连接来源环境和 Google Cloud 环境以完成迁移。
规划和构建阶段由以下任务组成:
- 构建资源层次结构。
- 配置 Google Cloud的 Identity and Access Management (IAM)。
- 设置结算功能。
- 设置网络连接。
- 强化安全性。
- 设置日志记录、监控和提醒。
如需详细了解这些任务,请参阅迁移到 Google Cloud:规划和构建基础。
如果您计划使用 Database Migration Service 进行迁移,请参阅 MySQL 的网络方法,了解适用于迁移场景的网络配置。
监控和提醒
使用 Google Cloud Monitoring,其中包含多个 Google Cloud 产品的预定义信息中心,涉及 Cloud SQL 监控信息中心。或者,您可以考虑使用与Google Cloud集成的第三方监控解决方案,例如 Datadog 和 Splunk。如需了解详情,请参阅关于数据库可观测性。
将 Amazon RDS 和 Amazon Aurora for MySQL 实例迁移到 Cloud SQL for MySQL
如需迁移实例,请执行以下操作:
选择迁移策略:持续复制或预定维护。
根据您选择的策略和要求选择迁移工具。
为每个数据库迁移定义迁移计划和时间表,包括准备和执行任务。
定义必须完成的准备任务,以确保迁移工具能够正常运行。
定义执行任务,其中包括实现迁移的工作活动。
为每个执行任务定义后备场景。
执行测试和验证,这可以在单独的预演环境中完成。
执行迁移。
执行生产环境切换。
清理来源环境并配置目标实例。
执行调优和优化。
以下各部分介绍了每个阶段。
选择迁移策略
在此步骤中,您已获得足够的信息,可以评估并选择最适合每个数据库的用例的以下迁移策略之一:
- 预定维护(也称为一次性迁移):如果您可以承受停机时间,此方法是理想之选。此选项的费用和复杂性相对较低,因为您的工作负载和服务不需要进行大量重构。但是,如果迁移在尚未完成之前失败,您必须重新启动该过程,这会延长停机时间。
持续复制(也称为 Trickle 迁移):对于关键任务数据库,此选项可降低数据丢失风险,并实现几乎为零的停机时间。工作被拆分为多个部分,因此如果发生失败,回滚和重复操作所需的时间会更短。不过,设置起来更复杂,需要进行更多规划和花费更多时间。还需要付出额外的努力来重构连接到数据库实例的应用。请考虑以下变体之一:
- 使用 Y(写入和读取)方法,这是一种并行迁移形式,在迁移期间在来源实例和目标实例中复制数据。
- 使用数据访问微服务,从而减少 Y(写入和读取)方法所需的重构工作。
如需详细了解数据迁移策略,请参阅评估数据迁移方法。
下图是一个流程图,其中包含您在确定单个数据库的迁移策略时可能会遇到的示例问题:
上图显示了以下决策点:
您能承受任何停机时间吗?
- 如果没有,请采用持续复制迁移策略。
- 如果是,请继续回答下一个决策点。
迁移数据时,您是否可以承受切换期所代表的停机时间?切换窗口表示备份数据库、将其传输到 Cloud SQL、恢复数据库以及切换应用所需的时间。
- 如果没有,请采用持续复制迁移策略。
- 如果是,请采用预定维护迁移策略。
不同数据库的策略可能不同,即使它们位于同一实例中也是如此。混合使用多种策略可以取得最佳效果。例如,您可以使用预定维护方法迁移小型数据库和不常用的数据库,但对于停机时间代价较高的关键任务数据库,则应使用持续性复制。
通常,在初始来源实例和目标实例之间切换后,迁移就视为已完成。所有复制(如果使用)都会停止,所有读取和写入操作都会在目标实例上完成。在两个实例同步时进行切换,意味着不会丢失数据且停机时间最短。
如需详细了解数据迁移策略和部署,请参阅数据库迁移分类。
最大限度地减少停机时间和迁移相关的影响
不提供应用停机时间的迁移配置需要更复杂的设置。在设置复杂性和在流量较低的营业时间安排的停机时间之间找到适当的平衡。
每种迁移策略都有其权衡之处,并且与迁移过程相关的某些影响。例如,复制过程会在来源实例上增加一些额外负载,并且您的应用可能会受到复制延迟的影响。应用(和客户)可能需要在应用停机期间等待,至少在使用新数据库之前等待复制延迟时间。在实践中,以下因素可能会增加停机时间:
- 数据库查询可能需要几秒钟才能完成。在迁移时,运行中的查询可能会被中止。
- 如果数据库较大或具有大量缓冲区内存,缓存可能需要一些时间才能填满。
- 在来源中停止并在 Google Cloud中重新启动的应用可能会出现轻微的延迟,直到与 Google Cloud数据库实例建立连接为止。
- 必须将应用的网络路由重新路由。具体用时因 DNS 条目的设置方式而异。更新 DNS 记录时,请在迁移前降低 TTL。
以下常见做法有助于最大限度地减少停机时间和影响:
- 找到停机时间对工作负载影响最小的时间段。例如,在正常工作时间以外、周末或其他预定维护期内。
- 确定工作负载的哪些部分可以在不同阶段进行迁移和生产切换。您的应用可能具有不同的组件,这些组件可以隔离、调整和迁移,而不会产生任何影响。例如,前端、CRM 模块、后端服务和报告平台。此类模块可以拥有自己的数据库,并可在迁移过程中提前或延后安排迁移。
- 如果您可以承受目标数据库的延迟时间,请考虑实现渐进式迁移。使用增量、批量数据传输,并调整部分工作负载以处理目标实例上的过时数据。
- 考虑重构您的应用,以支持尽可能减少迁移影响。例如,您可以调整应用以同时写入来源数据库和目标数据库,从而实现应用级复制。
选择迁移工具
选择合适的迁移工具是成功完成迁移的最重要因素。确定迁移策略后,请查看并确定迁移工具。
您可以使用许多工具,每个工具都针对特定迁移应用场景进行了优化。应用场景可能包括:
- 迁移策略(预定的维护或持续复制)。
- 来源数据库引擎和目标数据库引擎以及引擎版本。
- 来源实例和目标实例所在的环境。
- 数据库大小。数据库越大,迁移初始备份所需的时间就越长。
- 数据库更改的频率。
- 是否可以使用托管式服务进行迁移。
如需确保无缝迁移和切换,您可以使用应用部署模式、基础架构编排和自定义迁移应用。不过,名为“托管式迁移服务”的专用工具可以简化将数据、应用甚至整个基础架构从一个环境迁移到另一个环境的过程。它们从来源数据库运行数据提取,将数据安全地传输到目标数据库,并可酌情在传输过程中修改数据。借助这些功能,它们可以封装复杂的迁移逻辑并提供迁移监控功能。
托管式迁移服务具有以下优势:
最大限度地缩短停机时间:服务会在可用时使用数据库引擎的内置复制功能,并执行副本升级。
确保数据完整性和安全性:数据会安全可靠地从来源数据库传输到目标数据库。
提供一致的迁移体验:借助数据库迁移可执行文件,您可以管理和监控不同的迁移技术和模式,并将其整合到一致的通用界面中。
提供弹性强且经过验证的迁移模型:数据库迁移虽然不常见,但却是关键事件。为了避免初学者犯错以及现有解决方案出现问题,您可以使用经验丰富的专家提供的工具,而不是构建自定义解决方案。
优化费用:与为自定义迁移解决方案预配额外的服务器和资源相比,托管式迁移服务更具成本效益。
后续各部分介绍了迁移工具建议,这些建议取决于所选的迁移策略。
用于执行预定维护迁移的工具
下图是一个流程图,其中包含一些问题,可帮助您在使用定期维护迁移策略时为单个数据库选择迁移工具:
上图显示了以下决策点:
- 您是否希望使用托管式迁移服务?
- 如果是,我们建议您使用 Database Migration Service。
- 如果没有,我们建议您使用数据库引擎内置备份进行迁移。
使用托管式迁移服务具有一些优势,本文档的选择迁移工具部分对此进行了介绍。
以下子部分介绍了可用于一次性迁移的工具及其局限性和最佳实践。
使用 Database Migration Service 进行预定维护迁移
Database Migration Service 会管理初始同步和持续的变更数据捕获 (CDC) 复制,并提供迁移操作的状态。
借助 Database Migration Service,您可以创建可管理和验证的迁移作业。我们建议您使用 Database Migration Service,因为它支持通过一次性迁移作业迁移到 Cloud SQL for MySQL。对于大型数据库,您可以在 Database Migration Service 中使用数据转储并行处理。
如需详细了解数据库迁移架构和 Database Migration Service,请参阅使用 Database Migration Service 将数据库迁移到 Cloud SQL for MySQL 和 MySQL 的迁移保真度。
如需详细了解 Database Migration Service 的限制和前提条件,请参阅以下内容:
- Database Migration Service 中的已知限制。
- Database Migration Service 中的配额和限制。
- 在 Database Migration Service 中配置源。
内置数据库引擎备份
如果可以接受较长停机时间,并且来源数据库相对静态,您可以使用数据库引擎的内置转储和加载(有时也称为备份和恢复)功能。
设置和同步需要付出一些努力,尤其是对于大量数据库,但数据库引擎备份通常随时可用且易于使用。
数据库引擎备份存在以下常规限制:
- 备份很容易出错,尤其是手动执行时。
- 如果没有正确管理备份,数据将不安全。
- 备份缺乏适当的监控功能。
- 如果使用此工具迁移多个数据库,则需要花费精力来扩容。
如果您选择此方法,请考虑以下限制和最佳实践:
- 如果您的数据库相对较小(小于 10 GB),我们建议您使用 mysqldump。没有固定限制,但 mysqldump 的理想数据库大小通常不超过 10 GB。
如果您导入的数据库大于 10 GB,则可能需要采用一些其他策略来最大限度减少数据库停机时间。其中一些策略如下:
- 分段导出架构和数据,而不使用辅助键。
- 利用时间戳。如果您的任何表使用时间戳列,您可以使用 mysqldump 命令的一项功能,指定
WHERE
子句以按时间戳列进行过滤。 - 考虑使用其他方法,例如使用 mydumper 和 myloader 工具。
数据库转储和备份通常不包含 MySQL 用户账号。准备迁移时,请查看源实例上的所有用户账号。例如,您可以针对每个用户运行 SHOW GRANTS
命令,以查看当前的一组权限,并了解是否有任何权限在 Cloud SQL 中受到限制。同样,Percona 提供的 pt-show-grants
工具也可以列出授权。
在迁移具有 DEFINER
属性的数据库对象时,Cloud SQL 中对用户权限的限制可能会影响迁移。例如,存储过程可能具有超级特权 definer 来运行 SQL 命令,例如更改 Cloud SQL 中不允许的全局变量。对于此类情况,您可能需要重写存储过程代码,或者将非表对象(如存储过程)作为单独的迁移步骤进行迁移。如需了解详情,请参阅导入和导出数据的最佳实践。
如需进一步了解限制和最佳实践,请参阅以下内容:
其他预定维护迁移方法
使用托管式导入来设置从外部 MySQL 数据库复制时,系统会将初始数据从外部数据库加载到 Cloud SQL 实例中。此方法使用从外部服务器(在本例中为 RDS 实例)中提取数据并将其直接导入 Cloud SQL 实例的服务。
对于大型数据库(几 TB),更快的方法是使用 mydumper 和 myloader 工具进行自定义导入初始加载。
您可以考虑将 MySQL 数据库中的表导出到 CSV 文件,然后将这些文件导入 Cloud SQL for MySQL。如需从 RDS 实例导出数据,您可以使用 AWS Database Migration Service (AWS DMS) 和 S3 存储桶作为目标。
如需了解详细信息和步骤,请参阅使用代管式导入设置从外部数据库复制。
适用于持续复制迁移的工具
下图是一个流程图,其中包含一些问题,可帮助您在使用连续复制迁移策略时为单个数据库选择迁移工具:
上图显示了以下决策点:
您是否希望使用托管式迁移服务?
如果是,那么您是否可以承受几秒钟的写入停机时间(具体取决于数据库中的表数量)?
- 如果是,请使用 Database Migration Service。
- 如果不是,请探索其他迁移选项。
如果没有,您必须评估数据库引擎内置复制功能是否受支持:
- 如果是,我们建议您使用内置复制。
- 如果不是,我们建议您探索其他迁移选项。
以下各部分介绍了可用于持续迁移的工具及其局限性和最佳实践。
使用 Database Migration Service 进行持续复制迁移
Database Migration Service 通过使用持续迁移作业类型,为持续迁移提供无缝支持。只有连续迁移作业可以提升为“已完成”,这会指示停止复制。
如果您选择此工具,请考虑以下限制和最佳实践:
- 避免在迁移过程中进行长时间运行的事务。在这种情况下,如果您不是从 AWS Aurora 迁移,我们建议您从读写副本迁移。
- 如需查看相关限制的完整列表,请参阅已知限制。
数据库引擎内置复制
数据库引擎内置复制是持续迁移的 Database Migration Service 替代方案。
数据库复制表示将数据从一个称为主数据库的数据库复制和分发到其他称为副本的数据库的过程。其目的是提高数据可访问性,并提高数据库系统的容错性和可靠性。虽然数据库迁移不是数据库复制的主要目的,但它可以作为实现此目标的工具而成功使用。数据库复制通常是一个持续的过程,在主数据库中插入、更新或删除数据时会实时发生。它可以作为一次性操作执行,也可以作为一系列批量操作执行。
大多数现代数据库引擎都实现了不同的数据库复制方式。一种类型的复制可以通过复制主服务器的预写日志或事务日志并将其发送到副本来实现。这种方法称为物理或二进制复制。其他复制类型的工作原理是分发主数据库收到的原始 SQL 语句,而不是复制文件系统级别的更改。
Cloud SQL 支持 MySQL 复制。不过,也存在一些前提条件和限制。
前提条件:
- 确保您在 Amazon RDS 或 Amazon Aurora 实例上使用的是 MySQL 5.5、5.6、5.7 或 8.0。
- 确保已启用二进制日志。
- 为了加快初始完整转储阶段的速度,请从 CPU 和内存大小的角度选择足够大的机器层级。
- 如果您需要加快 CDC 阶段的速度,可以尝试配置并行复制并启用高性能刷新。
- 如果 Cloud SQL 副本已启用内部 IP 地址(因为出站 IP 地址不是静态的),请将 Amazon RDS 或 Amazon Aurora 服务器的防火墙配置为允许为 VPC 网络的专用服务访问通道分配的内部 IP 地址范围,Cloud SQL 副本将使用该 VPC 网络作为其专用网络。如需了解详情,请参阅关于从外部服务器复制和配置专用服务访问。
限制:
- 如果您的数据库中只有一个大型表和许多二级索引,则初始完整转储可能需要更长时间。
- 如果外部服务器包含
DEFINER
子句(视图、事件、触发器或存储过程),则复制可能会失败,具体取决于这些语句的执行时间。详细了解 Cloud SQL 中的DEFINER
用法以及可能的解决方法。 - InnoDB 是 Cloud SQL 中唯一支持的数据库引擎。迁移 MyISAM 可能会导致数据不一致且需要验证数据。请参阅将表从 MyISAM 转换为 InnoDB。
其他持续复制迁移方法
其他持续复制迁移方法包括:
-
- 持续复制由您的应用执行。
- 迁移工作重点在于重构或开发连接到数据库实例的工具。
- 然后,逐步重构和部署读者应用,以使用目标实例。
使用 Datastream 复制 MySQL 实例的近实时更改。
- Datastream 是一项无服务器 CDC 和复制服务,可与 Amazon RDS 或 Amazon Aurora 搭配使用,以复制和同步数据。
- 使用 Datastream 将 MySQL 实例中的更改复制到 BigQuery 或 Cloud Storage,然后使用 Dataflow 或 Dataproc 将数据导入 Cloud SQL 实例。
如需详细了解如何使用 Datastream 进行复制,请参阅以下内容:
- 在 Datastream 中配置 Amazon RDS for MySQL 数据库
- 在 Datastream 中配置 Amazon Aurora MySQL 数据库
- 使用 Datastream 实时流式传输数据更改
用于持续复制迁移的第三方工具
在某些情况下,最好针对大多数数据库引擎使用一个第三方工具。例如,如果您希望使用托管式迁移服务,并且需要确保目标数据库始终与来源数据库近乎实时同步,或者在迁移过程中需要进行更复杂的转换(如数据清理、重组和调整),则可以使用这种方法。
如果您决定使用第三方工具,请选择以下建议之一,该建议可用于大多数数据库引擎。
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 或 Amazon Aurora 实例准备工作和前提条件
- 来源数据库准备工作和前提条件
- Cloud SQL 设置
- 迁移专用设置
Amazon RDS 或 Amazon Aurora 实例准备和前提条件
请考虑以下常见的设置和前提条件任务:
- 根据迁移路径,您可能需要允许在 RDS 实例上进行远程连接。如果您的 RDS 实例在 VPC 中配置为专用,则 Amazon 和 Google Cloud之间必须存在专用 RFC 1918 连接。
您可能需要配置一个新的安全组,以允许在所需端口上进行远程连接。
- 默认情况下,在 AWS 中,数据库实例的网络访问功能处于关闭状态。
- 您可以在安全组中指定允许从 IP 地址范围、端口或安全组进行访问的规则。与该安全群组关联的所有数据库实例都适用相同的规则。
请确保您有足够的可用磁盘空间来缓冲 Amazon RDS 实例上的全加载操作期间的 WAL 日志。
为了获得最佳迁移结果,请考虑从读取副本迁移,除非您要从 Amazon Aurora 迁移。此外,我们建议您在数据库活动较少的时间段内开始迁移过程。
MySQL 限制主机名不得超过 60 个字符。Amazon RDS 数据库主机名通常超过 60 个字符。如果要迁移的数据库存在这种情况,请配置 DNS 重定向以创建
CNAME
记录,将您的域名与 RDS 数据库实例的域名相关联。如果您使用的是内置复制功能,则需要为 Amazon RDS 或 Amazon Aurora 实例设置复制。内置复制或使用内置复制功能的工具需要将 MySQL 的二进制日志记录功能设置为
ROW
。如果您使用的是第三方工具,通常需要先进行设置和配置,然后才能使用该工具。查看第三方工具的文档。
如需详细了解实例准备和前提条件,请参阅设置 MySQL 的复制外部服务器。
来源数据库准备工作和前提条件
- 如果您选择使用 Database Migration Service,则需要先配置来源数据库,然后再连接到该数据库。在实现迁移作业之前,请先查看迁移作业。如需了解详情,请参阅为 MySQL 配置源。
- 您可能需要更改某些功能,具体取决于您的数据库引擎。例如,Cloud SQL for MySQL 仅支持 InnoDB 数据库引擎。您需要将 MyISAM 表更改为 InnoDB。
- 某些第三方迁移工具要求所有
LOB
列都可以为空。任何LOB
列都需要在迁移期间移除该约束条件。NOT NULL
对生产使用中的来源环境进行基准测量。请考虑以下事项:
- 衡量数据的大小以及工作负载的性能。平均而言,重要查询或事务需要多长时间?高峰时段需要多长时间?
- 记录基准测量结果以便日后进行比较,进而帮助您确定数据库迁移的保真度是否令人满意。确定您是否可以切换生产工作负载并停用来源环境,或者是否仍需要将其用于后备目的。
Cloud SQL 设置
请仔细选择目标 Cloud SQL for MySQL 数据库实例的大小和规格,以与来源数据库匹配,以满足类似的性能需求。请特别注意磁盘大小、吞吐量、IOPS 和 vCPU 数量。不正确的大小可能会导致较长的迁移时间、数据库性能问题、数据库错误和应用性能问题。
在创建 Cloud SQL 实例之前,您必须确认以下属性和要求,因为这些属性和要求日后无法更改,除非重新创建实例。
- 请谨慎选择目标 Cloud SQL 实例的项目和区域。无法在 Google Cloud 项目和区域之间迁移 Cloud SQL 实例,而不会传输数据。
- 迁移到 Cloud SQL 上的匹配主要版本。例如,如果您的源数据库在 Amazon RDS 或 Amazon Aurora 上使用 MySQL 8.0.34,则应迁移到 Cloud SQL for MySQL 8.0.34 版。
- 如果您使用的是内置数据库引擎备份或 Database Migration Service,请单独复制用户信息。Cloud SQL 使用 Google IAM 管理用户。如需了解详情,请查看内置数据库引擎备份部分中的限制。
- 查看数据库引擎配置标志,并比较其来源实例值和目标实例值。请确保您了解它们的影响,以及它们是否需要相同。例如,我们建议您在迁移前对源数据库运行
SHOW VARIABLES
命令,然后再对 Cloud SQL 数据库运行该命令。根据需要更新 Cloud SQL 数据库的标志设置,以复制来源设置。请注意,Cloud SQL 实例不允许使用所有 MySQL 标志。
如需详细了解 Cloud SQL 设置,请参阅以下内容:
迁移专用设置
如果您要将 SQL 转储文件导入 Cloud SQL,则可能需要创建一个 Cloud Storage 存储桶。该存储桶用于存储数据库转储内容。
如果您使用复制,则必须确保 Cloud SQL 副本数据库可以访问您的主数据库。您可以通过已记录的连接选项来获得此访问权限。
根据您的场景和重要性,您可能需要实现后备场景,这通常包括反转复制的方向。在这种情况下,您可能需要从 Cloud SQL 向来源 Amazon 实例添加额外的复制机制。
对于大多数第三方工具,您需要预配特定于迁移的资源。例如,对于 Striim,您需要先使用 Google Cloud Marketplace。然后,如需在 Striim 中设置迁移环境,您可以使用 Flow Designer 创建和更改应用,也可以选择现有模板。您还可以使用 Tungsten Query Language (TQL) 编程语言编写应用的代码。借助数据验证信息中心,您可以直观地了解 Striim 应用处理的数据。
迁移完成并经过验证后,您可以停用用于连接 Amazon 和Google Cloud 环境的资源。
详情请参阅以下内容:
定义执行任务
执行任务会执行迁移工作本身。具体任务取决于您选择的迁移工具,如以下子部分所述。
内置数据库引擎备份
如需执行一次性迁移,请使用 mysqldump 实用程序创建备份,以将数据从 Amazon RDS 复制到本地客户端计算机。如需查看相关说明,请参阅将 SQL 转储文件导入 Cloud SQL for MySQL。
您可以查看 Cloud SQL 实例的导入和导出操作的状态。
Database Migration Service 迁移作业
在 Database Migration Service 中定义和配置迁移作业,以将数据从来源实例迁移到目标数据库。迁移作业通过用户定义的连接配置文件连接到来源数据库实例。
测试所有前提条件,确保作业可以成功运行。选择一个时间,让您的工作负载能够承受迁移和生产切换带来的短暂停机时间。
在 Database Migration Service 中,迁移从初始完整备份和加载开始,然后是从源数据库实例到目标数据库实例的持续更改流程。
Database Migration Service 需要几秒钟的时间来获取源 Amazon RDS 或 Amazon Aurora 实例中所有表的读取锁,以便以一致的方式执行初始完整转储。为了实现读锁,它可能需要 1 到 49 秒的写入停机时间。停机时间取决于数据库中表的数量,1 秒对应 100 个表,9 秒对应 10, 000 个表。
使用 Database Migration Service 进行迁移的过程以升级操作结束。升级数据库实例会将目标数据库与来自来源数据库的更改流断开连接,然后将现在的独立目标实例升级为主实例。此方法有时也称为生产环境切换。
如需详细了解 Database Migration Service 中的迁移作业,请参阅以下内容:
如需了解详细的迁移设置流程,请参阅使用 Database Migration Service 将数据库迁移到 Cloud SQL for MySQL。在 Database Migration Service 中,通过启动和运行迁移作业来执行迁移。
数据库引擎内置复制
您可以使用内置复制功能将数据从 Amazon RDS 复制到外部 Cloud SQL for MySQL 实例。
对于 MySQL,您首先需要创建一个可存储在 Cloud Storage 存储桶中的初始转储,然后将数据导入 Cloud SQL for MySQL。然后,您可以开始复制流程。
监控复制,并在适当的时间停止对源实例进行写入。再次检查复制状态,确保所有更改均已复制,然后将 Cloud SQL for MySQL 副本提升为独立实例以完成迁移。
如需详细了解如何从外部服务器(例如 Amazon RDS 或 Amazon Aurora for MySQL)设置内置复制,请参阅关于从外部服务器复制和配置 Cloud SQL 和外部服务器以进行复制。
如需了解详情和相关指南,请参阅以下内容:
第三方工具
为您选择的第三方工具定义任何执行任务。
本部分重点介绍 Striim 示例。Striim 使用从各种来源获取数据、处理数据,然后将数据传送到其他应用或目标的应用。
您可以使用 Web 客户端以图形方式创建应用,这些应用包含整理为一个或多个流的来源、目标和其他逻辑组件。
如需在 Striim 中设置迁移环境,您可以使用 Flow Designer 功能创建和更改应用,也可以从多个现有模板中进行选择。您还可以使用 TQL 编程语言编写应用。
您可以使用数据验证信息中心直观呈现 Striim 应用处理的数据。
如需快速开始在 Google Cloud中使用 Striim,请参阅在 Google Cloud中运行 Striim。如需详细了解 Striim 的基本概念,请参阅 Striim 概念。请务必阅读从初始加载切换到持续复制的最佳实践指南。
请考虑采用以下数据迁移最佳实践:
- 在每个计划步骤开始和结束时通知相关团队。
- 如果任何步骤用时超出预期,请将已用时间与为每个步骤分配的最大时间进行比较。发生这种情况时,向相关团队发布定期中间商更新。
- 如果时间跨度超过为计划中的每一步预留的最大时间量,请考虑回滚。
- 针对迁移和切换计划的每个步骤做出“执行或不执行”的决策。
- 考虑每一步的回滚操作或替代方案。
定义后备场景
为每个迁移执行任务定义后备操作项,以防范迁移过程中可能出现意外问题。后备任务通常取决于所使用的迁移策略和工具。
后备可能需要付出巨大的努力。最佳做法是,在测试结果令人满意之前,不要执行生产环境切换。应对数据库迁移和后备场景进行适当的测试,以避免严重中断。
为所有迁移执行任务定义成功标准并设置时间限制。执行迁移模拟有助于收集有关每个任务预期时间的信息。例如,对于预定的维护迁移,您可以承受切换期所代表的停机时间。不过,请务必规划好下一步的操作,以防一次性迁移作业或备份恢复在途中失败。如果迁移任务未在预期时间内完成,您可能需要推迟迁移,具体取决于计划停机时间已过的时间。
后备计划通常是指在执行生产环境切换后,如果目标实例出现问题,则回滚迁移。如果您要实施后备计划,请务必记住,必须将其视为完整的数据库迁移(包括规划和测试)。
如果您选择不制定后备计划,请务必了解可能产生的后果。如果没有后备计划,可能会增加意外的工作量,并在迁移过程中造成不必要的中断。
虽然后备是作为最后的办法来使用,并且大多数数据库迁移最终都不会使用后备策略,但我们建议您始终采用后备策略。
简单后备
在此后备策略中,您可以将应用切换回原始来源数据库实例。如果您在采用后备策略时可以承受停机时间,或者您不需要在新目标系统上提交事务,请采用此策略。
如果您确实需要目标数据库上的所有写入数据,并且可以承受一些停机时间,可以考虑停止对目标数据库实例的写入操作,执行内置备份并在来源实例上恢复备份,然后将应用重新连接到初始来源数据库实例。根据工作负载的性质和写入目标数据库实例的数据量,您可以稍后将其引入初始来源数据库系统,尤其是在工作负载不依赖于任何特定记录创建时间或任何时间顺序约束条件时。
反向复制
在此策略中,您需要将在生产切换后发生在新目标数据库上的写入操作复制回初始来源数据库。这样,您就可以让原始来源与新的目标数据库保持同步,并让写入操作在新目标数据库实例上进行。其主要缺点是,您必须先切换到目标数据库实例,然后才能测试复制流,因此无法进行端到端测试,并且在没有后备策略的情况下,复制流会有一个短暂的空档期。
如果您可以保留来源实例一段时间,并且使用连续复制迁移进行迁移,请选择此方法。
正向复制
此策略是反向复制的变体。您可以将新目标数据库上的写入操作复制到您选择的第三方数据库实例。您可以将应用指向此第三个数据库,该数据库会在服务器不可用时连接到服务器并运行只读查询。您可以根据需要使用任何复制机制。这种方法的优点是,它可以进行端到端测试。
如果您希望始终使用后备机制,或者在生产环境切换后不久必须舍弃初始来源数据库,请采用此方法。
重复写入
如果您选择 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 或 AlloyDB for PostgreSQL 实例
切换完成后,您可以删除来源数据库。我们建议您在清理来源实例之前执行以下重要操作:
为每个来源数据库创建最终备份。这些备份可为您提供来源数据库的最终状态。在某些情况下,备份可能还需要遵守某些数据法规。
收集来源实例的数据库参数设置。或者,检查这些数据是否与您在目录构建阶段收集的数据一致。调整目标实例参数,使其与来源实例中的参数一致。
从来源实例收集数据库统计信息,并将其与目标实例中的统计信息进行比较。如果统计信息不一致,则很难比较来源实例和目标实例的效果。
在后备场景中,您可能需要将 Cloud SQL 实例上的写入操作复制回原始来源数据库。设置类似于迁移过程,但会以相反的方向运行:初始来源数据库将成为新的目标数据库。
为了在切换后保持来源实例的最新状态,最佳做法是在目标 Cloud SQL 实例上执行的写入操作复制回来源数据库。如果您需要回滚,可以回退到旧的来源实例,从而将数据丢失降到最低。
除了清理来源环境之外,您还必须为 Cloud SQL 实例进行以下关键配置:
- 为主实例配置维护期,以控制执行中断性更新的时间。
- 在实例上配置存储空间,以便您至少有 20% 的可用空间来支持 Cloud SQL 可能执行的重要数据库维护操作。如需在可用磁盘空间低于 20% 时收到提醒,请为磁盘利用率指标创建基于指标的提醒政策。
在先前操作完成之前,请勿启动管理操作。
如需详细了解维护和最佳实践,请参阅关于 Cloud SQL 实例维护。
迁移后优化您的环境
优化是迁移的最后一个阶段。在此阶段中,您将对优化任务进行迭代,直到目标环境满足您的优化要求。每个迭代的步骤如下:
- 评估您的当前环境、团队和优化循环。
- 确定优化要求和目标。
- 优化您的环境和团队。
- 调整优化循环。
重复执行这个任务序列,直到达到您的优化目标。
如需详细了解如何优化 Google Cloud 环境,请参阅迁移到 Google Cloud:优化您的环境和 Google Cloud 架构框架:性能优化。
确定优化要求
查看针对您的 Google Cloud环境的以下优化要求,并选择最适合您工作负载的优化要求:
提高数据库的可靠性和可用性
借助 Cloud SQL,您可以实现与恢复时间目标 (RTO) 和恢复点目标 (RPO) 一致的高可用性和灾难恢复策略。为了提高可靠性和可用性,请考虑以下事项:
- 对于频繁读取的工作负载,请添加只读副本以从主实例分流流量。
- 对于关键任务工作负载,请使用高可用性配置、区域故障切换副本和可靠的灾难恢复配置。
- 对于不太关键的工作负载,自动备份和按需备份就足够了。
- 为防止意外移除实例,请使用实例删除保护。
- 请考虑使用 Cloud SQL 企业 Plus 版,以便享受更高的可用性、更长的日志保留期和近乎零停机时间的计划内维护。如需详细了解 Cloud SQL 企业 Plus 版,请参阅 Cloud SQL 版本简介和近乎零停机时间的计划内维护。
如需详细了解如何提高数据库的可靠性和可用性,请参阅以下内容:
提高数据库基础架构的性价比
为了产生积极的经济影响,您的工作负载必须高效地使用可用资源和服务。您可以考虑采取以下方案:
通过执行以下操作,为数据库提供所需的最小存储容量:
- 如需在数据增长时自动扩缩存储空间容量,请启用存储空间自动扩容。不过,请确保将实例配置为在高峰工作负载期间具有一定的缓冲空间。请注意,数据库工作负载往往会随着时间的推移而增加。
确定可能高估的资源:
- 调整 Cloud SQL 实例的大小可以降低基础架构成本,而不会对容量管理策略增加额外风险。
- Cloud Monitoring 提供预定义的信息中心,可帮助您确定许多组件(包括 Cloud SQL)的健康状况和容量利用率。 Google Cloud如需了解详情,请参阅创建和管理自定义信息中心。
找出不需要高可用性或灾难恢复配置的实例,并将其从基础架构中移除。
移除不再需要的表和对象。您可以将其存储在完整备份或归档 Cloud Storage 存储桶中。
评估适合您的使用场景且成本效益最高的存储类型(SSD 或 HDD)。
- 对于大多数使用场景而言,SSD 是最有效且最经济实惠的选择。
- 如果您的数据集很大(10 TB 或更大)、对延迟不敏感或不常访问,HDD 可能更合适。
- 如需了解详情,请参阅在 SSD 和 HDD 存储设备之间选择。
为具有可预测资源需求的工作负载购买承诺使用折扣。
使用 Active Assist 获取费用数据分析和建议。
如需了解详情和选项,请参阅以更少的资源做更多事情:推出通过 Active Assist 提供的 Cloud SQL 费用优化建议。
提高数据库基础架构的性能
与数据库相关的轻微性能问题通常可能会影响整个操作。如需保持和提高 Cloud SQL 实例的性能,请考虑遵循以下准则:
- 如果您有大量数据库表,这些表可能会影响实例性能和可用性,并导致实例脱离其服务等级协议 (SLA) 覆盖范围。
确保您的实例在内存或 CPU 方面不受限制。
- 对于需要高性能的工作负载,请确保您的实例至少有 60 GB 的内存。
- 如果数据库插入、更新或删除操作缓慢,请检查写入者和数据库的位置;长距离发送数据会导致延迟。
通过使用 Cloud Monitoring(或类似的数据库引擎内置功能)中的预定义查询数据分析信息中心,提升查询性能。确定最昂贵的命令并尝试对其进行优化。
防止数据库文件过大。 请以 MB 为单位设置
autogrow
,而不是使用百分比,并采用符合要求的增量。检查读取器和数据库位置。延迟对读取性能的影响大于对写入性能的影响。
考虑使用 Cloud SQL 企业 Plus 版,以便享受更高的机器配置限制和数据缓存。如需了解详情,请参阅 Cloud SQL 版本简介。
如需详细了解如何提升广告效果,请参阅“诊断问题”中的效果。
提高数据库可观测性功能
诊断和排查连接到数据库实例的应用中的问题可能具有挑战性且耗时。因此,所有团队成员都可以在一个集中位置查看数据库和实例级别发生的情况,这一点至关重要。您可以通过以下方式监控 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 常规建议如下:
- 如果您有大型实例,我们建议您尽可能将其拆分为较小的实例。
- 配置存储空间以支持重要的数据库维护。 请确保您至少有 20% 的可用空间以支持 Cloud SQL 可能执行的重要数据库维护操作。
- 数据库表过多可能会影响数据库升级时间。理想情况下,每个实例的表数应少于 1 万个。
- 为实例选择合适的大小,以考虑事务(二进制)日志保留量,尤其是对于写入活动较多的实例。
为了能够高效地处理您可能遇到的任何数据库性能问题,请遵循以下准则,直到问题得到解决:
扩展基础架构:增加资源(例如磁盘吞吐量、vCPU 和 RAM)。根据紧迫程度以及团队的可用性和经验,垂直扩缩实例可以解决大多数性能问题。之后,您可以在测试环境中进一步调查问题的根本原因,并考虑解决问题的方案。
执行并安排数据库维护操作:索引碎片整理、统计信息更新、真空分析和重新为频繁更新的表建立索引。检查是否以及何时上次执行了这些维护操作,尤其是对受影响的对象(表、索引)执行的操作。了解是否发生了与正常数据库活动不同的变化。例如,最近添加了新列或对表进行了大量更新。
执行数据库调优和优化:数据库中的表是否结构正确?列的数据类型是否正确?您的数据模型是否适合工作负载的类型?调查慢查询及其执行计划。它们是否使用了可用的索引?检查是否有索引扫描、锁定和等待其他资源。不妨考虑添加索引来支持您的关键查询。消除非关键索引和外键。不妨考虑重写复杂查询和联接。解决问题所需的时间取决于您的团队的经验和可用性,可能需要数小时到数天的时间。
横向扩容读取:考虑使用只读副本。如果纵向扩缩无法满足您的需求,并且数据库调优和优化措施也无济于事,请考虑横向扩缩。将应用的读取查询路由到只读副本可提高数据库工作负载的整体性能。不过,您可能需要付出额外的工作来更改应用以连接到只读副本。
数据库重构:考虑对数据库进行分区和编入索引。此操作所需的工作量远大于数据库调优和优化,并且可能涉及数据迁移,但可以作为长期解决方案。有时,数据模型设计不当可能会导致性能问题,而垂直扩容可以部分抵消这些问题。不过,合适的数据模型是长期解决方案。考虑对表进行分区。尽可能归档不再需要的数据。规范化数据库结构,但请注意,非规范化也能提高性能。
数据库分片:您可以通过对数据库进行分片来扩展写入。分片是一项复杂的操作,涉及以特定方式重新构建数据库和应用以及执行数据迁移。您可以使用特定的分区标准,将数据库实例拆分为多个较小的实例。这些条件可以基于客户或主题。通过此选项,您可以横向扩缩写入和读取。不过,这会增加数据库和应用工作负载的复杂性。这也可能会导致称为热点的不平衡分片,这会抵消分片带来的好处。- 对于 Cloud SQL for MySQL,请确保表具有主键或唯一键。Cloud SQL 使用基于行的复制,此复制最适用于具有主键或唯一键的表。
如需了解详情,请参阅 Cloud SQL for MySQL 的一般最佳实践和操作指南。
后续步骤
- 了解其他 AWS 到 Google Cloud 迁移过程。
- 了解如何将 AWS 和 Azure 服务与 Google Cloud进行比较。
- 了解何时寻求迁移帮助。
- 如需查看更多参考架构、图表和最佳实践,请浏览 Cloud 架构中心。
贡献者
作者:
- Alex Cârciu | 解决方案架构师
- Marco Ferrari | 云解决方案架构师
其他贡献者:
- Derek Downey | 开发者关系工程师
- Paweł Krentowski | 技术文档工程师
- Matthew Smith | 云战略工程师
- Somdyuti Paul | 数据管理专家
- Zach Seils | 网络专家