mysql8.0二进制安装遇到的问题

公司新项目需要用CentOS8.0以上的系统和mysql8.0；于是在虚拟机上开始操作测试；

一实验环境

1、系统版本：CentOS8.3
2、数据库版本：mysql-8.0.23
3、数据库下载链接：https://dev.mysql.com/downloads/mysql/

二、遇到的问题

　　这里不讲安装过程，之前博客有写只不过用的是mysql5.7，安装过程是一样的；直接说问题；

　　当解压完mysql8.0压缩包后，配置完环境变量后就可以直接执行mysql -V命令去测试环境变量是否成功；但是执行mysql -V命令报错了，报错信息如下：

mysql: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory

　　当看到这个信息的时候我初步判断是因为我没有对数据库做初始化，导致没有加载libtinfo.so.5这个公共库；于是我接着初始化了mysql，并且mysql成功启动，但是当我再次执行mysql命令的时候，依然是之前的报错；于是我find / -name libtinfo.so.5这个模块，发现确实没有，就又执行了yum install libtinfo.so.5 -y来安装该模块；安装完成之后成功的在/usr/lib/目录下找到了该模块，以为问题解决了，但是当再一次执行mysql命令的时候发现仍然是之前的报错；

于是，开始思考它到底在找哪个目录没有找到，因为lib目录有两个lib和lib64，于是我将/usr/lib/目录下的libtinfo.so.5做了个软连接到/usr/lib64目录下(ln -s /usr/lib/libtinfo.so.5 /usr/lib64/libtinfo.so.5)，再次执行mysql命令发现报错信息并非原来的那个No such file or directory了，报错信息如下：

mysql: error while loading shared libraries: libtinfo.so.5: wrong ELF class: ELFCLASS32

　　由此报错可以判断，mysql确实是找的lib64目录中的libtinfo.so.5；又百度了下“ELFCLASS32”，表示调用的so文件是32位的；既然32位的不对，那么就需要一个64位的so文件，于是我在lib64目录下执行了以下命令：

[root@slave lib64]# ll libtinfo*
lrwxrwxrwx. 1 root root 15 5月 11 2019 libtinfo.so.6 -> libtinfo.so.6.1
-rwxr-xr-x. 1 root root 208616 5月 11 2019 libtinfo.so.6.1

　　发现有关于libtinfo.so的模块，于是抱着尝试的心态在lib64目录下面又做了一个软连接：

[root@slave lib64]# ln -s /usr/lib64/libtinfo.so.6 /usr/lib64/libtinfo.so.5
[root@slave lib64]# ll libtinfo*
lrwxrwxrwx  1 root root     24 3月   4 17:33 libtinfo.so.5 -> /usr/lib64/libtinfo.so.6
lrwxrwxrwx. 1 root root     15 5月  11 2019 libtinfo.so.6 -> libtinfo.so.6.1
-rwxr-xr-x. 1 root root 208616 5月  11 2019 libtinfo.so.6.1

　　然后再次执行mysql命令，执行成功了；问题解决；

　　后续我又将/usr/lib64下面的软连接libtinfo.so.5删除，将其软链接到了/lib64目录下，发现也是可以的；所以又学习了这几个目录的关系，总结下来就是：/lib64是内核级的,/usr/lib64是系统级的,/usr/local/lib64是用户级的；

三、工作中遇到的一些关于mysql问题的整理

　　1、客户反馈接口调用无响应

　　客户反馈他们有个产品调用我们的接口没有响应，由于产品是部署在客户侧设备的，我没有登录权限，只能远程指导客户去排查，起初根据客户描述接口没有响应，就用curl命令发起了一次POST请求，这里data数据是错误的，返回了400状态码，这表示接口是有响应的；因为服务在内网环境下，外面又接了负载均衡，怀疑是负载均衡是不是有什么安全限制给拦截了，于是让客户直接在部署服务的设备上直接用curl命令调用以127.0.0.1为ip的接口，这时候data数据依然是错误的，返回的还是400状态码，这时候也排除了安全限制的问题，查看程序后台日志，也是有返回的，提示参数错误，本身data数据就是有问题的，所以这也是意料之中的事情；

为什么要用错误的data数据来发起POST请求呢，这个解释下，因为客户反馈的问题是调用接口无响应，用错误的data数据只是为了节省时间，初步判断下接口是否给响应；这步工作做完后还是没有定位到问题，于是让客户找了一条正确的data数据用curl命令发起了一次真实的POST请求，发现接口果真没有响应，一直是请求等待中；因为这条接口返回的数据是从mysql库里拿的，接口不返回数据也就意味着数据库没有返回，于是让客户看了3306端口也是起的；又让客户看了mysql所在的设备的磁盘容量，结果发现问题了，mysql的data目录挂载的磁盘使用率100%了，让客户清理了一些无用数据之后，空间释放，再去测试接口，接口响应正常；

有问题后续还会更新。。。。。。。。。。。。。