慎重升级到MySQL 8.0.38及更高版本(文末附规避风险办法)

2024年 7月 15日 48.8k 0

昨日,Percona 资深工程师 Marco Tusa 爆料,升级到 MySQL 8.0.38 版本后,当实例中的表个数超过一万个,实例重启后会发生 Crash 而失败,即便是重启时加上 validate_tablespace_paths=OFF
也不行。

这个问题在 >= 8.0.38 版本中存在,包括 8.4.1 和 9.0.0。

详细复现过程参见:https://perconadev.atlassian.net/browse/PS-9306。

我用 MySQL 9.0.0 版本测试:

-- 创建一个最简单的表,并写入数据
> CREATE DATABASE test;
> USE test;
> CREATE TABLE t_1 (
  `id` int NOT NULL,
  PRIMARY KEY (`id`)
);

> INSERT INTO t_1 SELECT 1;

然后反复创建类似上面的表,表个数达到 1 万。

> SELECT COUNT(*) FROM information_schema.tables WHERE TABLE_SCHEMA ='test';
+----------+
| count(*) |
+----------+
|    10000 |
+----------+

之后重启实例,就能看到日志里有类似下面的内容,启动失败:

[Note] [MY-012207] [InnoDB] Using 2 threads to scan 10002 tablespace files
[Note] [MY-012200] [InnoDB] Thread# 0 - Checked 876/10002 files
...
[Note] [MY-012201] [InnoDB] Checked 10002 files
[Note] [MY-012208] [InnoDB] Completed space ID check of 10004 files.
...
2024-07-12T06:48:14Z UTC - mysqld got signal 11 ;
Signal SIGSEGV (Address not mapped to object) at address 0x508
Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware.
BuildID[sha1]=7f06a4743d7801096bd81bc999201fdbca43a12c
Thread pointer: 0x0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
stack_bottom = 0 thread_stack 0x100000

[root@db160 mysql-9.0.0-linux-glibc2.17-x86_64-minimal]#  #0 0x103f726 
 #1 0x103fa8c 
 #2 0x7f18f666ac1f  at sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
 #3 0x218a7be 
 #4 0x21705a7 
 #5 0x2b1d263 
 #6 0x7f18f6660179 start_thread at /usr/src/debug/glibc-2.28/nptl/pthread_create.c:479
 #7 0x7f18f4811dc2  at sysdeps/unix/sysv/linux/x86_64/clone.S:95
 #8 0xffffffffffffffff 
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

确实挺拉胯的。

另外,还是有办法可以规避的,也就是采用 共享/通用 表空间方案,例如:

-- 1. 共享表空间方案
> SET GLOBAL innodb_file_per_table = 0;
> CREATE TABLE ...;

-- 2. 通用表空间方案
> CREATE TABLESPACE test ADD DATAFILE 'test.ibd';
> CREATE TABLE t_1(...) TABLESPACE=test;

上述方案我已经验证过。

说下我个人看法,这个 Bug 却很 low,但这个问题很小,也很容易规避。

MySQL 最近表现确实很辣鸡,但我依然热爱它 。。。这算不算罗曼罗兰说的那种英雄主义,咱就是这么乐观,哈哈哈。

Enjoy MySQL 🙂

《深入浅出MGR》视频课程

戳此小程序即可直达B站

https://www.bilibili.com/medialist/play/1363850082?business=space_collection&business_id=343928&desc=0

文章推荐:

    • Oracle MySQL,怒其不争,自甘堕落

    • MySQL 9.0发布,号称支持向量(Vector),但我却看不懂Oracle到底在玩什么

    • Slave SQL线程与PXB FTWRL死锁问题分析

    • GreatSQL统计信息维护管理

    • GreatSQL死锁案例分析及扩展解读

    • GreatSQL优化技巧:半连接(semijoin)优化

    • MySQL复制从库延迟优化思路

    • MySQL复制从库延迟原因深入分析

    • 探究网络延迟对事务的影响

    • 源码解析丨一次慢SQL排查之旅

    • 面试题:INSERT...t...SELECT s会对s表加锁吗

    • 被很多人忽视的NULL值对NOT IN子查询结果的影响问题

    • MySQL 8.0.26版本升级32版本查询数据为空的跟踪

    • SQL优化案例解析:MINUS改写为标量子查询后提升5倍,但还可以再快近百倍

    • 关于GreatSQL字符集的总结

    • 为什么SHOW TABLE STATUS显示Rows少了40%

    • MTS性能监控你知道多少

    • MySQL对derived table的优化处理与使用限制

    • MySQL一次大量内存消耗的跟踪

慎重升级到MySQL 8.0.38及更高版本(文末附规避风险办法)-1

题图是我的手机摄影作品

想看更多技术好文,点个“在看”吧

相关文章

Oracle如何使用授予和撤销权限的语法和示例
Awesome Project: 探索 MatrixOrigin 云原生分布式数据库
下载丨66页PDF,云和恩墨技术通讯(2024年7月刊)
社区版oceanbase安装
Oracle 导出CSV工具-sqluldr2
ETL数据集成丨快速将MySQL数据迁移至Doris数据库

发布评论