记录一个关于MySql数据库从5.7升级到8.0.x的一个重要注意点

现在是2024年1月26号，公司这边及客户这边都需要升级一个数据库版本，然后我竟然从25号下午的5点半开始搞到现在。这也算是我所遇到的一次重大挑战。

重点在于当时没搞清楚mysql的 glibc 版本，惯性思维的认为越高越好。因此从一开始就陷入了错误的路线。

mysql包下载的glibc版本选项。这似乎是一种系统版本的选项（看不懂英文）

很巧合的是我选择了2.28版本的mysql包，后面一阵折腾升级结果是处处报错。什么缺少libstdc++.so.6依赖啊。什么libncurses.so.6乱七八糟的缺少依赖，然后我还去找了这些依赖然后安装到了服务器上了哈哈。但显然这种方式是不能解决问题的，依旧是启动的时候疯狂报错依赖不存在GLIBCXX_3.4.20不存在之类的。

而后面我是如何发现这个版本的问题呢？其实还是源于一开始安装mysql的旧版本的包还放在那里，旧的压缩包是5.7版本的，然后名称是mysql5.7xxx...glibc2.28。我眼睛一瞅心理寻思着mysql官网为什么要分出2.28和2.17还有2.12的选项呢？然后我百度一搜好家伙，原来这个glibc版本是有区分的，至此就发现了问题的关键所在。

        但是我还没来得及高兴，好家伙，这个疯狂报错的mysql怎么自己跑起来了？？而且还kill不掉

一kill就说这个进程不存在？？然后我根据我的经验，只剩下一阵感叹这场面真的是似曾相识啊。我记得mysql里mysqld_safe是专门来帮你启动mysql服务的，一监听到mysql服务挂了会立刻把它启动...没错之前启动mysql服务的时候我就是根据这个东西来启动的。但现在它疯狂被启动随后又因为各种缺少依赖不断的挂掉，反复诈尸...后来我就开始和这个该死的问题对决了。当然我那个时候并不想让服务器重启的，我想试一试能不能在服务器不重启的时候彻底干掉它，不要让它反复诈尸。所以在我发现它反复诈尸的时候第一招就打出了slof |grep mysql 来定位让它的文件夹（那个时候并不是完全确定是缺少依赖的mysql包导致的诈尸）然后确认文件夹路径再狠狠的打出一技 chmod -R 000 xxx 尝试废掉它的文件权限 然后它竟然依旧是反复诈尸。顿时只觉得心中火大，狠狠的打出终极杀招—— rm 来删除掉它的文件夹。本以为它会停止下来，结果 一技ps -ef|grep mysql试探让我楞了，这文件夹都没了你咋还能运行呢？然后再来一手slof |grep mysql 看看情况，结果它还是挂在上面，只不过目录地址被加了个用括号包裹起来的已删除的后缀...事已至此，我别无选择，发动神技——shutdown -r now 我的xshell免费版似乎传来了一阵空冥之声嗡的一下我断开了连接....然后服务器就重新启动了...再使用ps -ef|grep mysql的时候，这一切都已经烟消云散了.................ZZzz..

后续：其实那个进程的进程id不断在变的其实是grep筛选的进程哈哈（出来丢人）