RDS MySQL助力MySQL 5.7升级8.0

背景信息

2015年10月，Oracle正式推出MySQL 5.7。相对于MySQL 5.6，MySQL 5.7具备更出色的性能、更丰富的功能以及更高的安全性，逐渐成为了后续MySQL版本的首选。2018年，MySQL 8.0发布，相比MySQL 5.7有了进一步的提升。2023年10月25日，社区推出MySQL 5.7.44，该版本为最后一个5.7版本，意味着社区将停止对MySQL 5.7的维护，不再进行缺陷的修复和功能的更新。同时，社区也鼓励用户将MySQL 5.7升级到MySQL 8.0。

MySQL 5.7作为备受信赖的服务版本，目前仍然拥有广泛的用户群体。截止至2024年1月，在阿里云RDS MySQL的用户群中，约有46%的用户仍然坚持使用5.7作为他们的主要服务版本。然而，随着生命周期的结束，由于缺乏后续的更新和支持，MySQL 5.7面临着各种问题，难以满足不断变化的需求。社区MySQL主要服务版本如下图所示。

相对于MySQL 5.7版本，MySQL 8.0版本引入了许多强大而实用的特性。

• Atomic DDL：解决了MySQL 5.7版本中DDL中断导致文件残留的问题，确保了文件操作的原子性，同时解决了Server层和引擎层数据不一致的问题。

• Instant DDL：大大缩短DDL执行的时长，快速完成表结构的变更，同时消除了Binlog复制延迟。

• 增强JSON支持：新增了多个与JSON相关的函数，并对JSON的内存使用进行了优化。

• 隐藏索引：可以将索引设置对优化器不可见，从而避免潜在的重复删除和重建索引的操作。

• 克隆插件：相比传统的复制方式更加高效，直接在源实例上进行授权和克隆，极大地提高了MySQL的可扩展性。

阿里云RDS MySQL 8.0在社区MySQL 8.0的基础上进行了深度优化，并开发了许多高级特性，包括：

• Binlog in Redo：在事务提交时将Binlog内容同步写入到Redo Log中，减少对磁盘的操作，提高数据库性能。

• 通用云盘IO加速：通过扩展InnoDB Buffer Pool，将一部分数据页和温数据缓存，使您在无任何成本变化和业务改动的情况下，就可以获得实例IO性能的大幅度提升。

• 冷热数据分离：通过将云盘归档数据转存至OSS端，大幅降低存储成本。

• RTO相关优化：通过优化Redo应用过程和启动路径等，大幅缩短实例启动时间，提升实例的可用性。

通过架构的持续演进和内核的不断优化，阿里云RDS MySQL相较社区版本拥有更高的稳定性和安全性、更强的性能和更多的功能，为用户提供稳定可靠、简单易用的数据库服务。更多RDS MySQL自研的高级特性请参见AliSQL功能概览。

作为更强大的分支，MySQL 8.0的维护周期将会更长，并且将逐步解决现有问题。长期来看，强烈建议个人用户和企业用户将MySQL 5.7升级至MySQL 8.0。

社区版MySQL 5.7升级8.0遇到的问题

升级之前需要大量的准备工作

尽管存在许多必须升级的理由，但实际上从MySQL 5.7 升级到8.0并非易事。MySQL 8.0相较于MySQL 5.7，在数据字典、存储引擎和SQL语法等方面发生了许多重大变化。由于不同版本之间存在差异，在进行升级之前需要充分评估并做好充足的准备工作。MySQL 8.0相较于MySQL 5.7的主要差异如下图所示，详情请参见MySQL社区文档。

MySQL 5.7升级到MySQL 8.0是通过inplace upgrade的方式进行的，即直接使用MySQL 8.0的二进制文件来启动MySQL 5.7的实例，升级程序将自动进行相关的检查和升级。

升级前的准备工作实际上是为了消除升级程序中无法自动处理的“不兼容的”变化。主要工作包括：

• MySQL 8.0引入了全新的数据字典用于保存数据库中的元信息，Server层和InnoDB层共享一份元数据。MySQL 8.0的information_schema中的视图全部源自于数据字典表，与InnoDB相关的视图被重命名（INNODB_SYS_XXX重命名为INNODB_XXX）。若用户的应用依赖于这些视图，需要确保应用已做出相应的修改。在升级前需要确认业务是否依赖于MySQL 8.0中删除的系统表（如mysql.proc、mysql.event等），若存在则需使用新的访问方式去获取所需的数据。此外，对于和MySQL 8.0系统表同名的用户表（如catalogs、routines等），需要手动执行RENAME/DROP TABLE操作。

• MySQL 8.0不再支持的旧的数据类型（如old style decimals、old style varchar、old style TIME、DATETIME和TIMESTAMP等）。在升级之前，需要使用REPAIR TABLE或逻辑导出加导入的方式对问题表进行修复。

• MySQL 8.0中，分区表的处理已由Server层下沉至引擎层，MySQL Server不再支持通用分区。Non-native的分区表在MySQL 8.0中被废弃，因此需要将这类分区表改为Native类型（如InnoDB引擎）或是删除该分区表。

• 较早版本的MySQL 5.7（5.0.17之前的版本）的触发器（Triggers）不支持DEFINER属性，因此在MySQL 5.7实例中可能会存在缺失DEFINER属性的触发器，这些触发器会导致升级MySQL 8.0失败。在升级前您需要重新创建这些缺失DEFINER属性的触发器。

• MySQL 8.0中，外键约束的长度存在限制，如果外键约束过长，在升级过程中可能会导致错误和失败。因此，在进行升级之前，需要将问题外键修改为长度小于64个字符的约束。

• MySQL 8.0之前版本，视图的列名长度上限为255个字符，而在MySQL 8.0版本中，视图的列名长度上限缩短至64个字符。因此，在进行升级之前，需要将视图中过长的列名修改为长度小于64个字符的列名。

• MySQL 8.0中，单个ENUM和SET列元素的长度不得超过255个字符或1020个字节，因此在升级之前需要修改超出限制的ENUM和SET。

• 如果.frm文件和InnoDB数据字典表元数据信息不一致，那么会导致升级错误。因此，在进行升级之前，需要对数据进行逻辑导出和导入。若存在游离的.frm文件（即不含.ibd文件仅有.frm文件），则需要进行相应清理。

• MySQL 8.0废弃了部分空间函数。如果生成列中包含了已删除的函数（新引入的空间函数以"ST"和"MBR"开头），则需要在升级前对相应的列进行修改。

• 在进行升级前，必须确保MySQL 5.7的实例已经进行了正确的关闭，即需要确保在升级前不存在待应用的REDO日志和等待回滚的事务。

• MySQL 8.0中引入了一些新的保留字，其中大多数禁止用作表名、列名等，因此需要对MySQL 5.7中包含的MySQL 8.0引入的新保留字做处理。

• 在升级前，需要将废弃的sql_mode变量内容（例如NO_AUTO_CREATE_USER等）修改为MySQL 8.0支持的模式，以避免导致实例无法启动。

• 较新版本的MySQL 8.0实例（8.0.13及之后的版本），共享表空间（系统表空间和通用表空间）中不允许存在InnoDB类型的分区表，因此在进行升级前需要将共享表空间移动至独立表空间。

• MySQL 8.0实例中，GROUP BY子句不支持ASC或DESC排序规则，因此，在进行升级前，需要修改或删除包含相应句法的存储过程。

• 在MySQL 5.7中，lower_case_table_names是一个可修改的值，但在MySQL 8.0中，lower_case_table_names是一个初始化参数，一旦实例初始化完成，就无法在后续进行修改。在进行升级时，若需要将该参数值修改为1，请确保升级前库表名称为小写，以避免出现升级错误。

• MySQL 5.7和MySQL 8.0的字符集（charater set）和排序规则（collation）的配置可能存在差异，这可能导致索引失效、查询报错等问题，例如：

  • MySQL 8.0默认字符集为utf8mb4，使用1~4字节存储一个字符，MySQL 5.7默认字符集为utf8mb3，使用1~3字节存储一个字符，因此字段和索引长度会受到影响。在REDUNDANT或者COMPACT行格式下，InnoDB引擎所允许的最大索引长度为767字节，对应在5.7中索引允许的最大字符数是255，而在8.0中则无法创建超过191字符的索引。

  • 当在MySQL 5.7中使用了utf8mb3字符集创建表，如果升级MySQL 8.0后默认使用的字符集为utf8mb4，新建表在没有指定charater set时默认使用 utf8mb4。当新表（utf8mb4）和迁移表（utf8mb3）相关字段发生JOIN时，会因为JOIN两端字符集类型不一致导致索引失效。

  • 当在MySQL 5.7中使用了utf8mb4_general_ci排序规则创建表，如果升级到MySQL 8.0后，默认使用的排序规则为utf8mb4_0900_ai_ci，新建表在没有指定collation时默认使用utf8mb4_0900_ai_ci。由于utf8mb4_general_ci和utf8mb4_0900_ai_ci优先级相同（无法选择排序规则），当新表和迁移表相关字段发生JOIN时，会因为JOIN两端排序规则不兼容导致报错。

  为避免出现字符集引发的问题，在升级前需要检查MySQL中的字符集和排序规则使用情况，您也可以通过下述SQL来修改库、表、字段的字符集和排序规则。

  SQL

  # 修改库的字符集和排序规则
  ALTER DATABASE database_name CHARACTER SET = charset COLLATE = collation;
  # 修改表的字符集和排序规则
  ALTER TABLE table_name CONVERT TO CHARACTER SET charset COLLATE collation;
  # 修改字段的字符集和排序规则
  ALTER TABLE table_name CHANGE column_name column_name type CHARACTER SET charset COLLATE collation;

  重要

  • 修改列的charset时，MySQL会尝试映射数据值，但如果修改前后charset不兼容，可能会发生数据丢失。

  • 在阿里云RDS MySQL中，各版本默认字符集均使用utf8mb3，默认排序规则均使用utf8mb3_general_ci，如果没有手动修改过字符集和排序规则，大版本升级前后不会出现此类问题。

  • 更多信息可参考：调整实例character_set_server参数和collation_server参数和MySQL 社区字符集配置。

除了上述的准备工作外，版本间存在的驱动、错误码、参数、优化器差异等也需要业务上做适配。对于自建用户，在进行MySQL 5.7到MySQL 8.0的大版本升级前，可以利用MySQL Shell、mysqlcheck工具和社区的升级检查文档检查准备工作。MySQL 5.7升级到MySQL 8.0变化和检查细节请参见MySQL社区文档。

经常升级失败并且难以分析失败原因

尽管社区提供了相应的检查工具和帮助文档，以帮助用户进行升级前的检查和问题解决。然而在实际操作中经常会遇到升级失败的情况，出现各种各样的错误，并且很难从日志信息中逐一分析升级失败的原因。升级失败分析困难的原因包括但不限于以下几点：

1. 报错不明确。不同原因导致的错误，在日志中可能会记录为相同或相似的错误。用户需要投入大量时间和精力来排查错误的根本原因，这增加了升级的难度。

2. 报错不完整。在问题出现后，针对性地解决后发现重复的问题再次导致失败。这是因为升级程序在首次检测到某一类错误时就提前退出，导致相同问题无法一次性全部被检测到。用户需要进行多次尝试和排查，这增加了升级的复杂性和时间成本。

3. 部分错误只提供了错误提示，却没有相应的解决方案。用户需要自行查找解决方案或向社区寻求帮助，这增加了升级过程中的困惑和不确定性。

4. 部分MySQL 5.7或更早版本存在的问题已经得到修复，但对存量实例的处理仍然存在不足。

在解决大版本升级问题中发现，由于版本差异以及更老的MySQL 5.x版本信息残留，大版本升级涉及的问题琐碎繁多，升级失败的根源大多集中在数据字典上。

使用RDS MySQL轻松升级到RDS MySQL 8.0

阿里云RDS MySQL拥有大量正在使用的实例，每个月都有一些实例从5.7版本升级到8.0版本。在这一过程中，阿里云RDS团队积累了丰富的经验，建立了完善的预检查逻辑，并对多个大版本升级相关的Bug进行了分析和修复。

阿里云RDS MySQL团队致力于提前发现升级问题，保障升级平稳进行，提升大版本升级成功率，使用户获得更顺畅的升级体验。升级后用户可以享受到阿里云RDS MySQL 8.0带来的高性能和可靠性。此外，RDS将延长对不同版本的MySQL的支持期限，为用户提供更充裕的缓冲时间。社区MySQL和阿里云RDS MySQL生命周期如下：

在自建MySQL 5.7升级至8.0的过程中，除了前期繁琐的检查工作外，根据报错信息逐步进行修复可能需要多次进行，并且可能会遇到难以修复的问题，导致无法完成升级的情况。升级过程中停机时间长，返工次数多，耗费时间和精力。

与自行升级用户相比，用户进行阿里云RDS MySQL的大版本升级时，无需进行繁琐的检查，也无需反复核查错误日志并逐一解决问题，仅需点击控制台上的升级按钮，所有升级动作将在后台自动完成。

• 针对线上常见的大版本升级失败问题，阿里云RDS MySQL内核已进行修复工作。当用户的实例存在修复覆盖下的问题时，升级过程将不会失败，从而可实现无感升级。

• 针对内核侧无法直接修复的问题，阿里云 RDS MySQL 管控侧主动进行了多项兼容性检测。在实例触发大版本升级动作前，提前发现问题并进行提示，用户在无需重复启停的情况下就能够解决大部分问题。同时，对于升级失败的节点会自动回滚到升级前的状态，不会影响业务运行。

自建MySQL 5.7升级到 8.0和阿里云RDS MySQL 5.7升级到8.0流程对比如下：

经过一系列的治理，2023年至2024年期间，阿里云RDS MySQL 5.7成功升级至8.0的比例高达97.3%以上。阿里云RDS MySQL 5.7升级8.0的部分治理工作如下表所示：

升级方法

关于RDS MySQL的升级，详细信息请参见升级数据库版本。

升级案例

案例一：Server层与InnoDB字段、索引大小写不一致导致升级失败

• 自建MySQL升级失败：

  [ERROR] [MY-012071] [InnoDB] Column name mismatch: From InnoDB: id_c From Server: Id_c
  [ERROR] [MY-010767] [Server] Error in fixing SE data for test.t3
  [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
  [ERROR] [MY-010119] [Server] Aborting

• RDS MySQL自动修正引擎元数据，升级成功：

  [Warning] [MY-012071] [InnoDB] Column name case mismatch: From InnoDB: id_c From Server: Id_c, DD will be consistent with Server one.
  [Note] [MY-011088] [Server] Data dictionary initializing version '80023'.

案例二：表、字段、索引和存储过程包含乱码导致升级失败

• 自建MySQL升级失败：

  [ERROR] [MY-013140] [Server] Comment for table 'test.t4' contains an invalid utf8mb3 character string: '\xF0\x9F\x90'.
  [ERROR] [MY-010022] [Server] Failed to Populate DD tables.
  [ERROR] [MY-010119] [Server] Aborting

• RDS MySQL自动清除表、字段和索引注释的乱码，升级成功：

  [Warning] [MY-025076] [Server] Clear utf8mb3 character strings: '\xF0\x9F\x90' in comment of table 'test.t4'.
  [Note] [MY-011088] [Server] Data dictionary initializing version '80023'.

案例三：5.x 老版本临时表残留导致升级失败

• 自建MySQL升级失败：

  [ERROR] [MY-012216] [InnoDB] Cannot open datafile for read-only: '/tmp/#sql1dc6f_2_0.ibd' OS error: 71
  [ERROR] [MY-010020] [Server] Data Dictionary initialization failed.
  [ERROR] [MY-010119] [Server] Aborting

• RDS MySQL自动清理残留的元信息，升级成功：

  [ERROR] [MY-012216] [InnoDB] Cannot open datafile for read-only: '/tmp/#sql8947_1_0.ibd' OS error: 71
  [Warning] [MY-025078] [InnoDB] Skip orphaned tablespace during upgrade, space_id: 7, filepath: /tmp/#sql8947_1_0.ibd.
  [Note] [MY-011088] [Server] Data dictionary initializing version '80023'.

当然，阿里云RDS MySQL团队并未完全解决MySQL 5.7升级到8.0过程中的所有问题，在场景和方案上仍然存在需要完善的地方。

• 当前，在大版本升级过程中，为了确保用户实例不受影响，升级过程首先会在源实例的克隆实例上进行。当克隆实例完成升级后，再将用户实例进行切换，并释放旧版本实例。这个过程难免会消耗更多的时间和资源，因此有必要探索更好、更快的解决方案。

• 目前的治理手段无法覆盖所有的升级失败场景，无法保证100%的升级成功率。同时，用户行为导致升级失败的情况，通常需要用户介入进一步处理，无法实现完全的全自动升级。因此，进一步降低用户干预的比例是需要持续努力的方向。

总结

在进行大版本升级时，必须进行详细的升级前检查，逐步解决升级过程中出现的问题，并且完成升级后的验证和测试工作。大版本升级失败问题的解决并非一蹴而就。阿里云RDS MySQL团队一直在进行相关问题的修复和建设，提供了简便和高效的大版本升级机制。随着8.0版本的稳定推进，大版本升级的问题会逐步得到解决，直至完全消除。

相关文档

• 您可以将自建MySQL或第三方云数据库MySQL迁移至RDS MySQL，利用RDS轻松升级到MySQL 8.0。数据迁移请参见数据迁移方案。

• 更多MySQL的信息，请参见MySQL。