01

---------------

升级初探

绝大多数的IT系统按照上线流程，大致划分为：开发、测试、预发、生产等四个环境，每一个环境都有其独特的用途。昨天接到系统使用方的需求，要将生产数据同步到预发。在好奇心的驱使下，登入到预发环境一看，卧槽，，，登入到测试环境，卧槽槽槽...生产用的MySQL5.7.18，预发用MySQL5.6.26，测试用的MySQL5.6.25。为了愉快且平稳的使用MySQL，主要是方便DBA统一管理，除了都升级到5.7.18，也没有其他法子了。一次成功的升级失败教训，就这样经历了。

02

---------------

牛刀小试

在确定需要将测试和预发的环境都升级到MySQL5.7以后，就决定先挑个测试环境来小试牛刀。为了保障安全，一般情况下，后端服务系统与公网是不互通的，这就导致不能使用MySQL官方推荐，也是最方便的yum安装方式来进行升级了。另外，由于数据量较大，采用mysqldump将数据备份、恢复的逻辑升级方式由于速度较慢，在此场景下显然不合适；再结合系统停机不能过长这点要求，只能采用原地替换二进制包的方式，一次性将MySQL从5.6升级到5.7。

OS使用的是CentOS6.5，X86架构。由于前面提到的种种限制，需要按照以下步骤来完成升级：

1. 根据OS版本，使用公网登入MySQL官方网站下载对应的rpm安装包到本地的电脑上

2. 采用远程登入工具，将已下载到本地的rpm安装包上传到服务器，并完成解压

3. 登入到MySQL系统上，将选项innodb_fast_shutdown的值设置为0，这样确保关闭MySQL服务时，将缓冲区的数据全部刷新到磁盘

4. 运行mysqladmin，关闭MySQL服务

5. 将MySQL数据文件夹和配置文件进行备份，万一升级失败，还可以借此回滚

6. 查找并将系统上旧版本的二进制包清理干净

7. 采用新上传到服务器的rpm二进制包，来部署一套MySQL环境

8. 修改配置文件，将数据文件加改成原系统的路径，并重启MySQL服务，如果重启失败，可根据错误日志来进行修复

9. 运行mysql_upgrade程序，检查并修复MySQL5.6与5.7不兼容的地方

10. 兼容性问题完成后，在重启一遍MySQL服务，确保升级完成的系统可以交付给使用方

讲道理，按照以上步骤，应该很成功就完成升级。但是，在进行到步骤7，即安装rpm包的时候，却提示缺少glibc-2.14共享包，CSDN上搜索一遍之后，给出的解决方法是将系统原有的glibc-2.12升级到glibc-2.14。找到法子之后，就直奔gnu的官网，下载glibc源码，编译并进行安装。到目前，安装glibc-2.14看似一切顺利，歇了一会儿，使用cd命令切换路径时，辣眼睛的一幕发生了：cd命令不能用，在试一下ls命令，好像也不能用了；不知什么时候，到服务器的ssh连接直接断了，进行重连，却得到连接超时的反馈。开始意识到，通了个篓子。第一想法，这事已经超出我的能力范围，得靠我师傅来力挽狂澜了。师父的建议时，先保留现场，然后联系SA[系统管理员]进行修复。默默地看了一下时间，23:34:15，大概半小时后SA那边有了反馈："系统加载共享包失败，机器搞坏了"。到此，测试环境的MySQL升级以失败收尾。

03

---------------

磨刀霍霍

第二天一大早，系统使用方围了过来，原来是他们需要使用测试环境的MySQL，但机器已经被俺给搞坏了。嗯，别打脸就好，其他随便.....在部门老大的协调下，另一名SA过来帮忙修复系统，使用镜像，以救援模式登入到系统，经过近一个小时的抢救，SA叹了一声：“卧槽，太慢了”，然后反馈系统已修复。到这里复盘了一下，找到rpm安装失败，提示缺少glibc-2.14的原因是：在CentOS6.5上使用了CentOS7.5的安装包，以至于提示共享包依赖确实。以上系统的对于关系为：
CentOS6.5-->glibc-2.12-->mysql*el6*.rpm, CentOS7.5-->glibc-2.14-->mysql*el7*.rpm。
定位到失败的原因后，从MySQL官方网站重新下载rpm包，测试环境的MySQL成功升级到MySQL5.7.18

04

---------------

挥快刀斩乱麻

在有了升级测试环境的经验之后，快到一挥，花了大概15分钟的时间，将预发环境的MySQL由5.6.26成功升级到5.7.18。接下来，等着老大一声令下，将5.7.18升级到8.0.21