升级到 Amazon Aurora MySQL 版本 3具有 MySQL 80 兼容性 数据库
升级到 Amazon Aurora MySQL 3 版本与 MySQL 80 兼容
关键要点
在这篇文章中，我们将探讨如何将 Amazon Aurora MySQL 升级到版本 3 以获得最新的功能和性能提升。MySQL 80 引入了诸多新特性，提供了更优的性能和更多的功能。特别地，Aurora MySQL 3 版本还支持 Amazon Aurora Serverless v2 和 AWS Graviton3。了解最佳实践和挑战，将能帮助你顺利完成升级。
Amazon Aurora MySQL 兼容版本 3与 MySQL 80 兼容是 Amazon Aurora MySQL 支持的当前主要版本。通过使用 Amazon Aurora MySQL 版本 3，您可以获得最新的 MySQL 兼容功能和性能改进。MySQL 80 引入了几项新功能，包括 JSON 函数、窗口函数、公共表表达式CTEs和基于角色的权限。Aurora MySQL 3 还包括对新功能的支持，例如Amazon Aurora Serverless v2、Amazon Aurora zeroETL、AWS Graviton3、增强的二进制日志以及Amazon Aurora I/O 优化。有关功能的完整列表，请参见Aurora MySQL 版本 3 与 MySQL 80 兼容。
当 Amazon Aurora MySQL 发布新的主要版本时，您可以选择何时及如何升级您的数据库集群。主要引擎版本的升级可能会引入与现有应用程序不向后兼容的更改，因此，了解常见的挑战和最佳实践对于升级数据库版本和最大化收益至关重要。
在这篇文章中，我们将讨论在准备升级时开始的框架，审查标准支持的结束时间表，然后深入探讨升级过程。从 Aurora 升级的预检查、整体步骤，到可用于修改您的 Aurora MySQL 集群的各种选项。本文还描述了在升级生产数据库集群之前进行性能测试的最佳实践、在更改进行时监控的技术，以及其他关键考虑因素。
准备主要版本升级
在计划主要版本升级时，您可以首先定义一系列测试和验证步骤，以确保数据库和应用程序功能保持如预期。制定主要版本升级的要求和成功标准时，将此主题分解为更小的目标可能会有所帮助。以下是一些关键关注领域，为您的规划提供结构：
兼容性 验证客户端应用程序在升级中的正确操作。识别必须存在或以某种方式运行的平台、数据库和查询级功能，以便您的应用程序能够继续按预期运行。在生产环境升级之前测试升级过程，以发现任何兼容性问题。有关测试方法，请参见在升级前使用新 Aurora 版本测试您的 DB 集群。性能 升级生产数据库之前的性能测试包括保持足够的应用程序性能和验证预期的改进。本文讨论了查询性能测试的建议和工具，因为由于更改例如 MySQL 57 和 MySQL 80 之间的差异可能会影响性能。可用性 可用性有两个关键方面。第一个是将应用程序的停机时间降至最低，第二个是出现任何问题时具有回退选项。根据可接受的停机时间和对升级过程的控制程度，您可以选择本文讨论的多个升级选项。努力 在准备主要版本升级时，您还需要评估计划和测试升级所需的工程工作量，特别是在非生产环境中进行测试。在评估执行准备步骤的成本和努力时，请考虑这些工作能否在其他地方重复使用。随着您投入创建良好的变更管理程序，您可能在其他情况下重新利用这些工作。升级时间表
Amazon Aurora MySQL 版本 2与 MySQL 57 兼容将在 2024 年 10 月 31 日达到标准支持的结束。有关详细说明，请参见准备 Amazon Aurora MySQL 兼容版 2 标准支持结束。
标准支持结束时间表
请注意以下标准支持结束时间表的关键日期：
现在至 2024 年 10 月 31 日 您可以将集群从 Amazon Aurora MySQL 版本 2与 MySQL 57 兼容升级到 Amazon Aurora MySQL 版本 3与 MySQL 80 兼容。2024 年 10 月 31 日 在此日期，Aurora MySQL 版本 2 达到标准支持的结束。为了使您能够继续使用现有版本，最多可在 Aurora 或 RDS 标准支持结束日期后的 3 年内，您可以选择加入Amazon RDS 扩展支持。Amazon RDS 扩展支持
2023 年 9 月，AWS 宣布了Amazon RDS 扩展支持，这是一项付费服务，Amazon Relational Database ServiceAmazon RDS为 Amazon Aurora MySQL 或Amazon RDS for MySQL 的主要版本提供关键的安全和错误修复，最长可达 Aurora 或 RDS 标准支持结束日期后的 3 年。有关更多信息，请参见在 Amazon Aurora 和 Amazon RDS 上为 MySQL 数据库引入 Amazon RDS 扩展支持以及 Amazon RDS 扩展支持的费用在Aurora 定价中。
有关更新的版本发布时间表和支持结束日期的信息，请参见Amazon Aurora 主要版本和Amazon Aurora 次要版本。
选择目标版本
在决定将现有的 Aurora MySQL 2 集群升级到 Amazon Aurora MySQL 3 时，您可能会注意到，有多个次要版本可以选择作为升级的目标版本。在撰写本文时，最新的 Amazon Aurora MySQL 版本是 Amazon Aurora MySQL 305，兼容社区 MySQL 8032。Aurora MySQL 3 还支持长期支持LTS版本，即Aurora MySQL 304兼容 MySQL 8028的次要版本。使用 LTS 版本的数据库集群可以在该版本发布后的至少 3 年内保持相同的次要版本，这允许集群经历较少的升级周期。在升级到 Aurora MySQL 3 时，建议升级到最新的默认次要版本，而不是使用 LTS 版本，以便访问最新的功能和错误修复。有关 Amazon Aurora MySQL 3 版本中每个版本的功能和改进的信息，请参见Amazon Aurora MySQL 版本 3 的数据库引擎更新。
Amazon Aurora MySQL 3 的升级预检查
在升级任何数据库引擎的主要版本时，检查新版本及其功能与您现有应用程序的兼容性在升级的整体成功中起着至关重要的作用。MySQL 数据库版本和发布之间的差异可能会影响其与应用程序的交互，这可能会导致应用程序行为的变化。
飞鸟云加速器MySQL 80 相较于 MySQL 57 引入了许多更改。例如，某些关键字例如 RANGE在 MySQL 80 中可能是保留字，而在之前不是，某些功能例如查询缓存有可能会被移除。这些差异可能需要在升级过程中进行处理。作为最佳实践，我们建议密切查看MySQL 80 中的新特性来参考所有更改，并查看它们是否适用于您的工作负载。针对 Amazon Aurora MySQL，您还可以查看Aurora MySQL 版本 2 和 Aurora MySQL 版本 3 的比较，以了解升级时的更改。
当您从AWS 管理控制台或AWS 命令行界面AWS CLI启动从 Aurora MySQL 2 到 Aurora MySQL 3 的升级时，Aurora 会自动在后台运行预检查以检测任何不兼容项。这些预检查是强制性的，无法跳过。它们包括一些与社区 MySQL 一起提供的检查和一些 Aurora 引入的检查。有关更多信息，请参见针对 Aurora MySQL 的主要版本升级预检查。这些预检查在升级的 DB 实例停止之前运行，这意味着在运行期间不会造成任何停机时间。如果预检查发现不兼容项，Aurora 会自动取消升级，而不会导致数据库停机，并且不会对原始的 57 兼容写实例做出任何更改。
之后，Aurora 会在 Amazon RDS 控制台的“日志和事件”部分生成不兼容性事件，同时不兼容项也会在 upgradeprecheckslog 文件中报告。非零的 errorCount 表示升级未成功。在大多数情况下，日志条目会包含指向 MySQL 文档以纠正问题的链接。有关阻止成功升级的示例场景及其解决方案，请参见故障排除 Aurora MySQL 版本 3 升级问题。您可以在 Amazon RDS 控制台的“日志和事件”部分找到 upgradeprecheckslog。您也可以通过使用 aws rds describedblogfiles 命令，然后使用 aws rds downloaddblogfileportion 下载日志。
在发起升级之前，您还可以使用社区版 MySQL 预检查工具进行临时测试，以分析您现有的 Aurora MySQL 数据库，并识别大多数潜在的升级问题。
作为最佳实践，建议在生产环境中升级之前测试升级过程。有关测试方法，请参见在升级前使用新 Aurora 版本测试您的 DB 集群。执行这些测试不仅可以提供任何升级不兼容项如果有的话，还可以估计预检查运行的时间以及整个升级的完整持续时间。升级的持续时间可能因工作负载和数据库对象的数量而异。
最后，Aurora 预检查会检查数据库对象中的不兼容项，例如过程定义中的保留字。它们不会验证任何应用程序端的逻辑；因此，您应该确认任何保留关键字或不支持的语法如何影响您的应用程序。我们强烈建议在升级之前彻底测试应用程序，以确保所有功能正常在新版本中运行。
整体升级流程
Amazon Aurora MySQL 执行主要版本升级时采用多阶段过程，如下图所示。
当您在版本 2x 的 Aurora MySQL 集群上发起升级时，Aurora 首先执行预检查以定位与目标版本的兼容性问题，随后继续创建升级前的快照，您可以使用它来回滚以防出现任何升级问题。然后，数据库会重新启动，如果您的数据库有任何长时间运行的事务或历史长度较高，会在此步骤中清除撤销日志。由于 MySQL 8 引入了数据字典的新实现，您的数据库对象会根据更改进行转换，首先升级集群的写实例，然后是读取实例。有关更多信息，请参见数据字典如何升级和Amazon 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 蓝/绿部署
如果您的首要任务是在升级过程中将数据库的停机时间降到最低，可以使用一种
