亚马逊AWS官方博客

升级至 Amazon Aurora MySQL 版本 3（兼容 MySQL 8.0）

Amazon Aurora MySQL 兼容版版本 3（兼容 MySQL 8.0）是 Amazon Aurora MySQL 支持的最新主要版本。使用 Amazon Aurora MySQL 版本 3，您可以获得与 MySQL 兼容的最新功能和性能改进。MySQL 8.0 引入了多项新功能，包括 JSON 函数、窗口函数、公用表表达式（CTE，Common Table Expression）和基于角色的权限。Amazon Aurora MySQL 3 还包括了对新功能的支持，例如 Amazon Aurora Serverless v2、Amazon Aurora 零 ETL、AWS Graviton3 支持、增强二进制日志 和 Amazon Aurora I/O 优化版。有关完整的功能列表，请参阅与 MySQL 8.0 兼容的 Aurora MySQL 版本 3。

Amazon Aurora MySQL 发布新的主要版本后，您可以选择升级数据库集群的方式和时间。主要引擎版本升级会引入一些更改，这些更改可能无法向后兼容现有的应用程序；因此，在升级数据库时，您务必要了解常见的挑战和最佳实践，以尽可能地获得优势。

在这篇博文中，我们将讨论一个框架，供您为升级做准备，查看标准支持终止时间表，然后深入探讨升级过程。首先介绍的是 Aurora 升级预检查、总体步骤以及可用于修改 Aurora MySQL 集群的各种选项。本文还介绍了在升级生产数据库集群之前，执行性能测试的最佳实践、实时监控所做更改的技巧以及其他关键注意事项。

为主要版本升级做准备

在计划主要版本升级时，您可以先制定一组测试和验证步骤，确保数据库和应用程序功能仍能够正常使用。在讨论主要版本升级的要求和成功标准时，将此主题划分为几个较小的目标会有所帮助。以下介绍了几个关键的重点领域，可用于为您的规划确立结构：

  • 兼容性 – 确保升级后客户端应用程序可以正确操作。确定要让应用程序继续正常运行，必须存在或者按照特定方法操作的平台、数据库和查询级功能。在生产环境中升级之前测试升级过程，确定是否存在任何兼容性问题。有关测试方法，请参阅在升级前测试 Aurora 新版本中的数据库集群。
  • 性能 – 升级生产数据库之前需要进行性能测试，包括应用程序能否保持足够的性能，以及验证是否能够实现预期的改进。在这篇博文中，我们讨论了测试查询性能的建议和工具，因为 MySQL 5.7 与 MySQL 8.0 之间的变化会带来一些差异。
  • 可用性 – 可用性分为两个主要方面。第一个是确保尽可能减少应用程序的停机时间，第二个是出现任何问题时的回退选项。根据您可以接受的停机时间以及所需的对升级过程的控制能力，您可以从本文中讨论的多个升级选项中进行选择。
  • 工作量 – 在准备进行主要版本升级时，您还需要评估在非生产环境中规划和测试升级所需的工程工作量，然后再考虑在生产环境中进行更改。每当您评测执行准备步骤所需的成本和工作量时，都要考虑这些工作是否可以在其他地方重复使用。在您投资创建了良好的更改管理程序后，就有机会在其他情况下重复利用这些工作成果。

升级时间表

Amazon Aurora MySQL 版本 2（兼容 MySQL 5.7）将于 2024 年 10 月 31 日终止标准支持。有关详细说明，请参阅为 Amazon Aurora MySQL 兼容版的版本 2 终止标准支持做好准备。

标准支持终止时间表

请注意标准支持终止时间表的以下关键日期：

  • 即日起至 2024 年 10 月 31 日 – 您可以将集群从 Amazon Aurora MySQL 版本 2（兼容 MySQL 5.7）升级至 Amazon Aurora MySQL 版本 3（兼容 MySQL 8.0）。
  • 2024 年 10 月 31 日 – Aurora MySQL 版本 2 的标准支持在这一天终止。为了让您能够在 Aurora 或 RDS 标准支持终止日期后继续使用现有版本（最长可达 3 年），您可以选择 Amazon RDS 扩展支持。

Amazon RDS 扩展支持

2023 年 9 月，AWS 宣布推出 Amazon RDS 扩展支持，这是一项付费服务，用于在 Aurora 或 RDS 标准支持终止日期之后，由 Amazon Relational Database Service（Amazon RDS）为 Amazon Aurora MySQL 或 Amazon RDS for MySQL 主要版本提供关键安全更新和错误修复，时间最长为 3 年。有关更多信息，请参阅 Introducing Amazon RDS Extended Support for MySQL databases on Amazon Aurora and Amazon RDS 以及 Aurora 定价中的 Amazon RDS 扩展支持费用。

有关 Aurora 版本发布日期和支持终止日期的最新时间表的更多信息，请参阅 Amazon Aurora 主要版本和 Amazon Aurora 次要版本。

选择目标版本

当您决定将现有的 Aurora MySQL 2 集群升级到 Amazon Aurora MySQL 3 时，您可能会发现，有多个次要版本可供选择作为升级的目标版本。在撰写本文时，最新的 Amazon Aurora MySQL 版本是 Amazon Aurora MySQL 3.05，兼容社区 MySQL 8.0.32。Aurora MySQL 3 还提供了长期支持（LTS）版本，即 Aurora MySQL 3.04 次要版本（兼容 MySQL 8.0.28）。使用 LTS 版本的数据库集群，可以在该版本发布后的至少 3 年内保持使用相同的次要版本，这样可以减少集群需要进行的升级周期次数。升级到 Aurora MySQL 3 时，建议升级到最新的默认次要版本，而不是使用 LTS 版本，以便获取最新功能和错误修复。有关介绍各个版本功能和改进的 Amazon Aurora MySQL 3 发行说明，请参阅 Database engine updates for Amazon Aurora MySQL version 3。

Amazon Aurora MySQL 3 的升级预检查

升级任何数据库引擎的主要版本时，要想确保整体升级成功，检查新版本及其功能与您现有应用程序之间的兼容性是至关重要的环节。MySQL 数据库各个版本和发行版的工作方式以及与应用程序交互的方式可能会有所不同，这会导致应用程序行为的变化。

与 MySQL 5.7 相比，MySQL 8.0 带来了许多更改。例如，在 MySQL 8.0 中，一些以前未予保留的关键字现在可能会成为保留关键字（例如 RANGE）；此外可能移除了一些功能（例如，查询缓存）。在升级期间，需要处理这些不同的地方。作为最佳实践，我们建议您仔细阅读 What Is New in MySQL 8.0 一文，了解所有更改并检查您的工作负载中是否存在这些情况。具体到 Amazon Aurora MySQL，您还可以查看比较 Aurora MySQL 版本 2 和 Aurora MySQL 版本 3，了解升级会带来的变化。

当您从 AWS 管理控制台或 AWS 命令行界面（AWS CLI）启动从 Aurora MySQL 2 向 Aurora MySQL 3 的升级时，Aurora 会在后台自动运行预检查以检测任何不兼容的情况。这些预检查是强制性的，不能跳过。这些预检查包括社区 MySQL 中提供的一些检查，以及一些由 Aurora 引入的检查。有关更多信息，请参阅 Aurora MySQL 的主要版本升级预检查。预检查在停止数据库实例进行升级之前运行，这意味着在运行预检查期间不会导致停机。如果预检查发现不兼容的情况，Aurora 会自动取消升级，而不会导致数据库停机，并且不会对原始的与 5.7 兼容的写入器实例进行任何更改。

然后，Aurora 在 Amazon RDS 控制台的日志和事件部分中针对不兼容问题生成一个事件，并且 upgrade-prechecks.log 文件中也会报告不兼容问题。errorCount 不为零表示升级不成功。在大多数情况下，日志条目包含指向用于更正问题的 MySQL 文档的链接。Aurora MySQL 版本 3 的升级问题故障排除中讨论了可能阻碍成功升级的示例场景及其解决方法。在 Amazon RDS 控制台的日志和事件部分中，您可以找到 upgrade-prechecks.log。您还可以使用 AWS CLI，方法是使用 aws rds describe-db-log-files，后跟 aws rds download-db-log-file-portion。

在启动升级之前，您还可以使用社区版 MySQL 预检查器工具运行临时测试，分析现有的 Aurora MySQL 数据库，并确定可能存在的大多数升级问题。

作为最佳实践，请先测试升级过程，然后才在生产环境中进行升级。有关测试方法，请参阅在升级前测试 Aurora 新版本中的数据库集群。执行这些测试后，您不仅可以通过 Aurora 预检查日志文件来了解任何妨碍升级的不兼容问题的信息（如果有），还可以估算预检查运行所需的时间以及完成升级的所需的时间。升级持续时间因工作负载和数据库对象数量而异。

最后，Aurora 预检查过程会对数据库对象中的不兼容情况进行检查，例如过程定义中的保留字。这些检查不验证任何应用程序端的逻辑；因此，您需要验证任何保留关键字或不支持的语法会对应用程序造成什么影响。我们强烈建议在升级之前对应用程序进行全面测试，确保所有功能在新版本上都能正常运行。

整体升级过程

Amazon Aurora MySQL 执行的主要版本升级是一个多阶段过程，如以下流程图所示。

当您在版本 2.x 的 Aurora MySQL 集群上启动升级时，Aurora 会首先执行预检查，用于查找在目标版本上的任何兼容性问题，如前文所述。然后，它会继续创建升级前快照，当升级出现任何问题时，您可以使用该快照进行回滚。接下来重新启动数据库，如果您的数据库有任何长时间运行的事务或者有很长的历史记录，则将在此步骤中清除撤消日志。由于 MySQL 8 引入了数据字典的新实施，因此您的数据库对象随后会根据这些更改进行转换，并且首先升级集群的写入器实例，然后再升级读取器实例。有关更多信息，请参阅 How the Data Dictionary is Upgraded 和 Aurora MySQL 主要版本就地升级的工作原理。

执行 Amazon Aurora MySQL 的主要版本升级

在了解背景信息之后，接下来我们讨论将集群升级到 Amazon Aurora MySQL 3 主要版本的步骤。对于 Amazon Aurora MySQL，您可以通过控制台、AWS CLI 或 Amazon RDS API 来修改数据库集群，从而手动启动主要版本升级。在升级期间，升级操作要求应用程序停机一段时间。Aurora 将升级整个集群的引擎版本；因此，升级操作会在写入器和读取器数据库实例上同时执行。作为最佳实践，您可以在启动升级之前创建手动快照，以便准备好回滚计划。在这一部分中，我们按照从易到难的顺序介绍以下升级选项：

  • 就地升级
  • Amazon RDS 蓝/绿部署
  • 快照恢复和 Aurora 克隆

就地升级

这是最简单的选项，您直接在集群上运行升级过程。此方法不会创建新集群。此方案可保留相同的集群端点和集群的其他特性，因为它不需要将所有数据复制到新的集群卷中。当 Aurora 执行就地升级时，集群会停机。需要注意的一点是，在升级期间不能取消升级过程，升级过程将持续运行，直至成功或失败。如果在升级过程中出现任何问题，Aurora 将尝试回滚更改。有关更多详细信息，请参阅 Aurora MySQL 主要版本就地升级的工作原理。

此选项可用于升级生产环境，但在升级期间需要停机。由于此选项易于设置，因此在生产环境中执行升级之前，您还可以使用它来测试升级过程。有关执行就地升级的完整步骤，请参阅如何执行就地升级。有关故障排除技巧，请参阅 Aurora MySQL 就地升级的故障排除。

Amazon RDS 蓝/绿部署

如果您首先要确保的是在升级期间尽可能缩短数据库的停机时间，则可以使用托管流程，并行运行升级前后的旧集群和新集群。使用 Amazon RDS 蓝/绿部署时，您需要将数据从旧集群复制到新集群，直到准备好让新集群接管为止。您可以在升级数据库集群时使用此功能，尽可能缩短停机时间并降低升级风险。蓝绿部署需要两个数据库环境：您当前的生产环境（即蓝色环境），以及暂存环境（即绿色环境）。这两个环境使用 MySQL 二进制日志复制来保持同步。因此，在为 Aurora MySQL 数据库集群创建蓝绿部署之前，集群必须关联到启用了二进制日志记录（binlog_format）的自定义数据库集群参数组。如果尚未启用，则此更改需要重新启动蓝色集群。有关创建蓝/绿部署的步骤，请参阅创建蓝/绿部署。

您在绿色环境中进行的更改，例如升级主要或次要数据库引擎版本等，不会影响到蓝色环境。在绿色环境上测试升级后，您可以执行切换以提升绿色环境。您可以指定 30 – 3600 秒（1 小时）之间的切换超时。切换成功后，Amazon RDS 会重命名绿色环境中的端点，以匹配蓝色环境中的对应端点，因此无需更改应用程序。要验证切换是否成功，请参阅蓝/绿部署的最佳实践。要查看详细步骤的演示视频，请参阅 Upgrade to Amazon Aurora MySQL Version 3 with RDS Blue/Green Deployments。

快照恢复和 Aurora 克隆

对于升级开发/测试环境之类的应用场景，由于这些场景对升级期间的停机时间容忍度更高，您可以使用快照还原或 Aurora 克隆。这通常非常有用，因为您可以创建测试环境，用于测试主要版本升级时的数据库性能和应用程序兼容性。

首先，您为要升级的集群创建手动快照。在获取快照之前，您可以决定是否停止当前集群上的写入工作负载。然后，您可以从快照中还原，在还原时，选择要升级到的目标引擎版本。升级将作为还原过程的一部分执行。当升级完成且升级后的集群可用时，您将所有客户端流量重定向到新升级的集群。在重新启用工作负载之前，请确保已在新集群上应用了所有必要的配置设置和其他自定义设置。当不再需要原始集群时，您可以将该集群删除。

对于较大的数据集，由于 Aurora 需要构建分布在三个可用区上的分布式存储集群卷，还原时间可能会增加。Aurora 克隆是一种更快、更经济高效的方案。您可以停止写入工作负载，然后为原始集群创建 Aurora 克隆。当克隆准备就绪时，您可以执行就地升级（如前所述），以这种方法对克隆数据库执行主要版本升级。当升级完成且集群可用时，您可以将应用程序流量重定向到升级集群。

这两个选项都会导致停机，因为您在获取快照或创建克隆之前停止了写入。此外，这种方法还会创建一个新集群。这意味着集群将有一个新的端点，并且需要更新应用程序代码以指向新升级的集群。

主要版本升级方法摘要

下表总结了这几种升级选项。

方法 优点 缺点
就地升级
  • 简单且方便
  • 保持相同的数据库端点
 升级期间存在停机时间。
RDS 蓝/绿部署
  • 托管功能
  • 高效
  • 减少风险和停机时间
  • 确保蓝色环境和绿色环境同步
  • 端点会自动更新
 如果未启用二进制日志记录，则必须要启用，这会导致重启。此外，由于这种方法创建新的绿色环境，因此会产生额外的成本。执行切换后，您可以删除之前的蓝色集群以节省成本。
快照还原
  • 可用于测试升级或在生产环境中执行升级
 还原和升级新集群需要停机。
克隆
  • 比还原快照的速度更快
 在克隆上执行就地升级需要停机。

最后，另一种方案是设置手动蓝/绿部署，以包括回滚选项。

升级生产环境之前，在测试环境中进行性能测试

在升级测试环境之后，非常重要的一点是需要先监控和测试数据库的性能，然后在生产环境中执行升级。尽管查询执行引擎通常会随着各个版本进行改进，但在极少数情况下，查询在较新版本中会使用可能不太理想的执行计划。在从 MySQL 5.7 更改为 MySQL 8.0 之后，您可以观察到由此导致的查询性能差异（例如，新的数据字典）。下面是关于诊断这些性能差异的建议。

  • 我们建议您存储历史性能数据并为 Aurora 集群建立基准。您可以使用此数据，将当前性能与过去的趋势进行比较。您还可以区分正常性能模式和异常情况，并设计技术手段来解决问题。
  • 从 Aurora MySQL 2 集群中捕获示例工作负载，然后在 Aurora MySQL 3 上重新运行，查看在版本 3 中性能是否有任何变化。您可以使用像 mysqlslap 这样的工具来重新运行工作负载，用于执行暴力测试。但是，由于这种方法使用相同的参数重新运行相同的查询，因此结果可能会有所不同，可能需要额外的验证工作。
  • 您可以使用 sysbench 评测 Aurora 的性能。有关更多信息，请参阅 Amazon Aurora Performance Assessment Technical Guide。尽管本指南使用 sysbench 来评测性能，不过您可以调整 bash 脚本，来调整指令以使用您的首选工具。
  • 使用 Amazon RDS 性能详情来评测数据库上的负载、热门 SQL 查询、用户和等待事件。监控数据库负载对 Amazon Aurora MySQL 等待事件有何影响。这是识别任何性能瓶颈的最关键工具之一。
  • 考虑启用 Aurora MySQL 慢速查询日志，用于查找运行时间很长因而需要进行优化的查询。
  • 主要版本升级可能会导致查询的查询执行计划发生变化。要比较不同之处，您可以从旧版本和新版本收集示例执行计划。此外，检查查询，确定您是否使用了优化器提示，例如早期版本中的强制索引，在主要版本升级后，这些提示的执行可能会有所不同。使用性能详情和慢速查询日志确定导致数据库等待的主要 SQL 后，您可以使用以下一些工具优化查询：
      • EXPLAIN 可以显示运行查询所涉及的各个步骤。
      • 查询分析指明在当前会话期间，所运行语句的资源使用情况。
      • ANALYZE TABLE 更新表和索引统计信息，这有助于优化器选择适当的计划来运行查询。
  • 社区 MySQL 8.0 和 Amazon Aurora MySQL 3 中均已移除了查询缓存。如果您一直在 Aurora MySQL 2 集群中使用查询缓存，请验证此更改对于数据库性能的影响，特别是对 SelectLatency 等查询延迟指标的影响。
  • MySQL 8.0 社区版对临时表的处理方式与早期 MySQL 版本不同，Amazon Aurora MySQL 3 中也有这种行为变化。如果您的工作负载创建了大量临时表，要了解这些更改及其影响，请参阅 Aurora MySQL 版本 3 中的新临时表行为。
  • MySQL 8.0 社区版中的默认字符集为 utf8mb4，Aurora MySQL 3 也是如此。在升级之前，请验证是否需要对字符集进行任何更改，因为如果由于排序规则冲突，导致某些查询和存储过程无法使用表索引，则性能可能会很差。
  • 在对两个版本的性能进行比较时，请检查与性能相关的参数的默认值是否有任何变化，这种做法通常非常适合隔离和缩小问题的范围。有关更多信息，请参阅 Changed Server Defaults。

监控和提醒

鉴于您已经启动升级，我们来查看一下监控数据库实例运行状况以及检查升级期间是否存在任何错误的一些方法：

  • 您可以通过监控 Aurora 事件来检查升级的当前状态。您可以在数据库实例事件中订阅与升级对应的 RDS 事件 ID，以接收升级状态通知。
  • 在升级之后，使用 CPUUtilization 和 FreeableMemory 等 Amazon CloudWatch 指标来监控资源使用情况，以及升级对 SelectLatency 和 CommitLatency 等查询延迟指标的影响。有关完整的指标列表，请参阅 Amazon Aurora 的 Amazon CloudWatch 指标。您还可以使用 CloudWatch 警报，以便在指标超过指定阈值时收到通知，并能够对问题进行故障排除。
  • 对于 Aurora 升级，初始步骤包括 Aurora 执行干净关闭以及完成未完成的操作，例如事务回滚和撤消清除。因此，在生产环境中准备启动升级时，请确认数据库没有长时间运行的事务，这可能会延长升级的持续时间。同样，过长的回滚分段历史记录长度可能会导致升级过程变慢，因为 Aurora 在升级到目标版本之前会清除撤消日志。要进行验证，您可以使用以下命令： 
    • SHOW ENGINE INNODB STATUS

    • SHOW FULL PROCESSLIST

    • SELECT NAME,COUNT FROM INFORMATION_SCHEMA.INNODB_METRICS WHERE NAME="trx_rseg_history_len";

  • 如果集群在启动和关闭时遇到任何错误，Amazon Aurora MySQL 会将错误写入 mysql-error.log 文件。日志文件还有一个时间戳，可以帮助您确定写入日志条目的时间。升级期间出现任何问题时，您可以查看日志。有关更多信息，请参阅 Aurora MySQL 错误日志。
  • 如果由于任何原因升级失败，您可以查看 mysql-error.log 文件来排除问题。在升级预检查期间遇到错误时，请在 upgrade-prechecks.log 文件中查看错误和解决错误的步骤。

关键注意事项

从 Amazon Aurora MySQL 5.7 升级到 8.0 时，请注意几个关键事项：

  • 在主要版本升级期间，如果未提供参数组，Aurora 会自动为目标升级版本创建新的参数组。对于使用自定义参数组的 Amazon Aurora MySQL 实例，在升级时，请务必在目标版本中选择一个参数组，该参数组应该与您当前版本的参数组匹配，具有相似的参数，存储了相似或相同的值。有关参数更改的信息，请参阅 Aurora MySQL 版本 3 的参数更改。
  • 如果您为 lower_case_table_names 参数使用自定义值，则必须预先使用此设置来设置自定义参数组。在从 Amazon Aurora MySQL 版本 2 升级到版本 3 时，我们建议您为 lower_case_table_names 使用相同的设置。与 MySQL 5.7 不同的是，MySQL 8.0 限制在升级后更改 lower_case_table_names 值。查看您的应用程序要求并决定要设置的期望值。此设置以后无法更改。
  • 如果您使用的是 Amazon Aurora Global Database，请查看全局数据库的就地主要版本升级中的步骤。
  • 如果您使用的是 Aurora Serverless v1，请参阅 Upgrade from Amazon Aurora Serverless v1 to v2 with minimal downtime。
  • 如果您的 Aurora 集群包含大量数据库对象（表、数据库、事件、触发器、存储过程等），请考虑使用更大的实例类，这可以提供更多的 CPU 容量和内存资源来更快地完成升级。

总结

在这篇博文中，我们了解了 Amazon Aurora MySQL 3 升级程序、不同的升级流程和最佳实践。我们建议您升级 Amazon Aurora MySQL 2.x 集群并执行所需的测试，以充分利用最新版本中提供的新功能和优化。

有关升级的更多信息，请参阅升级 Amazon Aurora MySQL 数据库集群。

关于作者

Shagun Arora 是亚马逊云科技的数据库专家级解决方案架构师。她与客户合作，在 AWS 云中设计可扩展、高度可用且安全的解决方案。

Dilip Simha 是亚马逊云科技 Amazon Aurora MySQL 团队的工程经理。他有 20 年的企业软件工作经验，过去 5 年里一直在 Amazon 工作。

Aditi Sharma是亚马逊云科技的一名技术客户经理，她最初在 RDS 数据库团队担任云支持工程师，在那里她接触到了各种数据库引擎。此后，她在 AWS 担任过多个职务，之后转任技术客户经理一职。加入 AWS 之前，她曾在银行业担任软件开发工程师。Aditi 拥有管理信息系统硕士学位和计算机科学工程学士学位，还获得了 Scrum Master、Product Owner、AWS Database Specialist 和 Solutions Architect – Associate 认证。

Isael Pimentel是亚马逊云科技的高级技术客户经理，在开发和管理复杂的基础设施方面拥有 15 年的工作经验，并持有多个认证，包括 AWS Solution Architect、AWS Network Specialty、AWS Security Speciality、MSCA 和 CCNA。