包阅导读总结
1. `MySQL`、`新版本`、`崩溃`、`BUG`、`稳定性`
2. 文本主要讲述了 MySQL 8.0x 到 9.0 新版本存在大 BUG，表数量超 10000 张会系统崩溃并重启。提醒开源数据库使用者不要马上追随升级，某云厂商成员报告问题并对相关设计提出质疑。
3.
– MySQL 8.0x 到 9.0 存在大 BUG
– 表数量超 10000 张系统崩溃重启
– 某国内云厂商内核开发质问甲骨文未测试就推新版本
– 对开源数据库升级的提醒
– 不要新后马上追随升级现有版本
– 建议上新 1 年后再计划升级，稳定性最重要
– 某云厂商成员报告问题及质疑
– 指出未完全测试的严重问题及原因
– 对相关函数设计合理性提出讨论和质疑
思维导图：
文章地址：https://mp.weixin.qq.com/s/LcSW19BBYwhCpl_OMNJUmA
文章来源：mp.weixin.qq.com
作者：dbaplus社群
发布时间：2024/7/29 10:23
语言：中文
总字数：1352字
预计阅读时间：6分钟
评分：85分
标签：MySQL,数据库管理,数据库稳定性,版本升级,系统崩溃
以下为原文内容
本内容来源于用户推荐转载，旨在分享知识与观点，如有侵权请联系删除 联系邮箱 media@ilingban.com
最近看一些友人都在发MySQL9的新功能，很想查查有什么新鲜的东西，但不查不要紧，一查吓一跳。MySQL 8.038 ,8.4.1, 9.0 均存在大BUG，并挖出大瓜，某国内云厂商内核开发在MYSQL BUG List 质问甲骨文MYSQL，为什么这么简单的问题连测试都不测试就上线推新版本。
根据Percona的BLOG中的文章显示，当前他们发现MYSQL 8.037后面的版本均存在BUG，当表的数量超过 10000 张后，对应版本的MYSQL会系统崩溃，并进行重启。当前发现的 8.038, 8.4.1, 9.0 均存在此问题。
这再次提醒使用开源数据库的公司和人员，不要在开源数据库上新后，就马上进行追随，升级现有的数据库系统的版本，具体稳妥的方式为，在开源数据库上新1年后，在进行数据库版本的计划的升级。终究数据库升级不是儿戏，也不是越新越好，稳定性才是最重要。
其他开源数据库也发生过类似的一些事情，如POSTGRESQL 14版本在初期在线添加索引，导致丢失数据的问题等。
更多具体的信息参见：https://perconadev.atlassian.net/browse/PS-9306
另某云厂商 RDS 核心团队的成员 Huaxiong Song，报告了此次问题给MYSQL官方，具体的翻译内容如下
我从 Percona 的博客中了解到了 bug#115517，这是一个严重的问题，尚未完全经过测试。实际上，这个 bug 的原因非常简单：当数字超过 8000 时，InnoDB 会调用多个线程进行检查，而主线程以外的线程的 THD 未初始化，导致在 commit#28eb1ff 引入的修复中对 DD 的访问异常。
但我想谈谈其他问题。
这是一个并发函数，但测试用例并未涵盖它。这种设计的合理性值得怀疑。我对 MySQL InnoDB 大型表的启动进行了大量测试和研究。获取 DD 信息并不是一项非常快速的行为。以我的测试数据为例：100 万个表（sysbench 构建），正常关闭和重新启动，启动时间如下：Tablespace_dirs::scan() – 44.4 秒 fetch_global_components(&tablespaces) – 25.5 秒 validate(tablespaces) – 15.8 秒 总计 – 90.7 秒 我们可以发现，fetch_global_components(&tablespaces) 占据了启动时间的 28%，而这个函数是用来读取 DD::tablespace 表并构建 DD::tablespace 对象的。
在引入 commit#28eb1ff 后，忽略 bug#115517，我们可以假设除了获取所有表空间外，还需要获取所有 DD::table。与获取 DD::tablespace 不同，获取 DD::table 将更耗资源，因为每次获取都需要构建和销毁 Auto_releaser 对象。（尽管引入了多线程，我认为问题仍然存在）。对于函数 dict_name::parse_tablespace_path，我认为这个函数值得单独讨论：3.1 我认为将 std::string path 传递给函数并不理想。我认为 const std::string &path 更为合适。3.2 函数中使用了 SUB_PART_SEPARATOR 和 PART_SEPARATOR，但由于历史原因，分区和子分区的分隔符也可能是 #P# 和 #SP#。显然，这个函数无法处理这个问题。让我们回到 Validate_files::check 函数。在 parse_tablespace_path 之后，实际上调用了 fil_update_partition_name 来处理我上面提到的分区分隔符问题。因此，dict_name::parse_tablespace_path 的设计和使用并不完全合理。
