一、前言
升级需求：将5.7.35升级到8.0.27, 升级方式 in-place升级【关闭现有版本MySQL，将二进制或包替换成新版本并在现有数据目录上启动MySQL并执行升级任务的方式，称为in-place升级】
二、Mysql 生命周期
以下Mysql 生命周期-内容来自于互联网
关于数据库版本升级，一直都是热议话题，对于升级的缘由各家也有所不同，有业务驱动的，有DBA自发驱动的，有规划导向也有方向指引的……抛开各种原因，当升级这个决定落下来的时候，对于DBA手头的几百几千套数据库来说，就好比是一场动物大迁徙，满满的画面感。
从Oracle发布的版本生命周期规划可以看到，Mysql5.7已经走到了生命周期的终点，意味着后续将不再为Mysql5.7提供官方更新、错误修复或安全补丁。
阿里云和AWS都在官方公布了版本支持计划,Mysql5.7版本已经开始了倒计时。
三、MySQL8.0的新特性
默认字符集由latin1变为utf8mb4。
MyISAM系统表全部换成InnoDB表。
JSON特性增强。
支持不可见索引，支持直方图。
sql_mode参数默认值变化。
默认密码策略变更。
新增角色管理。
支持窗口函数，支持Hash join。
四、升级建议
支持从MySQL5.7升级到MySQL8.0，注意仅支持GA版本之间的升级。
不支持跨大版本的升级，如从5.6升级到8.0是不支持的。
建议升级大版本前先升级到当前版本的最近小版本，如5.7先升级到5.7.35后再升级到8.0。
做好充足的备份！数据无价！！!
五、升级前准备
5.1 Mysql-shell 检查工具兼容性
在执行升级操作前需要做一些检查工作，确认准备工作是否就绪，避免升级过程中出现异常。可以使用MySQL Shell使用util.checkForServerUpgrade进行检查，返回内容包括不符合迁移要求的问题，error的问题需要迁移前修改。
这里我们选择8027版本
然后上传文件至5.7.35的机器/root目录下
从输出报告可以看出，升级检查器在23个方面进行了检查，最终得出4个警告信息和1个提示。
消除警告：
Usage of utf8mb3 charset 在MySQL 8.0版本之前，默认字符集为latin1 ，utf8字符集指向的是utf8mb3 。从MySQL8.0开始，数据库的默认编码将改为utf8mb4 ；为了避免新旧对象字符集不一致的情况，可以在配置文件将字符集和校验规则设置为旧版本的字符集和比较规则。
New default authentication plugin considerations，密码认证插件变更。为了避免连接问题，可以仍采用5.7的mysql_native_password认证插件。
消除提示：
Usage of obsolete sql_mode flags：Mysq8.0 版本sql_mode不支持NO_AUTO_CREATE_USER，要避免配置的sql_mode中带有NO_AUTO_CREATE_USER。
通过以上的例子，可以发现，MySQL Shell提供的升级检查工具能够帮助我们检测版本兼容性，减轻升级工作负担。
5.2 逻辑备份Mysql数据
5.3 优雅的停止数据库
# 确保数据都刷到硬盘上，更改成0InnoDB关闭模式。如果值为0，InnoDB会在关闭前进行缓慢关闭、完全清除和更改缓冲区合并。如果值为1（默认值），InnoDB会在关闭时跳过这些操作，这个过程称为快速关闭。如果值为2，InnoDB刷新其日志并冷关机，就好像MySQL崩溃了；没有提交的事务丢失，但崩溃恢复操作使下一次启动需要更长的时间。在仍然缓冲大量数据的极端情况下，缓慢关闭可能需要几分钟甚至几小时。
5.4 备份Mysql 数据目录,安装目录 和配置文件
5.5 下载并解压MySQL8
安装包上传至原安装包目录下 我的是/usr/local/mysql
六、升级
6.1 修改my.cnf 配置文件
因5.7版本与8.0版本参数有所不同，为了能顺利升级，我们需要更改部分配置参数。主要注意sql_mode、basedir、密码认证插件及字符集设置，其他参数最好还是按照原5.7的来，不需要做调整。下面展示5.7和8.0的配置文件,注意备份原来配置文件。
6.1.1 Mysql5.7_my.cnf 配置文件
相比5.7，8多了以下配置
6.2 执行升级程序
在mysql5.7升级的时候，MySQL启动后还需执行mysql_upgrade后重启MySQL。MySQL8.0.16开始，MySQL 不推荐使用mysql_upgrade；直接使用 mysqld_safe 直接启动。关于--upgrade=的一些参数。
--upgrade=AUTO MySQL升级所有过时的内容
--upgrade=NONE MySQL跳过升级步骤，可能会导致报错
--upgrade=MINIMAL MySQL在必要时升级数据字典表，information_schema和information_schema。这可能会导致部分功能不能正常使用，例如MGR
--upgrade=FORCE MySQL会升级所有的内容，这会检查所有schema的所有对象，导致MySQL需要更长的时间启动。此模式下MySQL会重新创建系统表if they are missing。
新开一个窗口，可观察下错误日志看是否报错
tailf /data/mysql/mysql-error.log 然后登录数据库测试
6.3 修改Mysql环境变量
由于basedir 从/usr/local/mysql 变成了 /usr/local/mysql8，需要修改下环境变量信息：
6.4验证恢复过来的数据是否正常
七、问题及经验总结
7.1 问题一
在升级Mysql8.0后，关于JDBC中SSL连接的一些报错信息，如下图：
经排查发现，Mysql8.0 数据库默认开启了SSL认证，且之前Mysql5.7.39 也是默认开启了SSL认证，代码和JDBC驱动版本都没有变化，那很有可能就是Mysql8.0 中对于SSL的一个变化，咨询了DBA 朋友，专业的解释是，在5.7.31的时候SSL在源码中貌似没有真正的起作用，后面版本完善了这块的内容。倘若，不使用SSL去连接，就 需要按照如下的方法去处理：
方法一：从数据库成面，直接在my.cnf 中 添加skip_ssl 参数，从源头上关闭SSL 认证的方式
方法二：从代码层面，在JDBC 连接中，使用 &useSSL=false 参数，表示不使用SSL 认证
7.2 问题二
Mysql 报错unblock with ‘mysqladmin flush-hosts’，报错如下：
JDBC连接报错，报错内容 ERROR 1129 (HY000): Host ‘192.168.59.202’ is blocked because of many connection errors; unblock with ‘mysqladmin flush-hosts’
原因：同一个ip在短时间内产生太多，中断的数据库连接而导致的阻塞；而中断的因为有些业务使用SSL去连接数据库，导致登录失败，登录被锁；
临时解决方法，使用mysqladmin flush-hosts 命令清理一下hosts文件，mysqladmin -u xxx -p flush-hosts,根本上去解决，就需要排查什么异常的连接导致阻塞，登录被锁，比如上面提到的SSL认证的问题。
7.1 问题三
MySQL--使用innodb_force_recovery修复数据库异常
当MySQL服务异常重启失败后，可以通过配置参数innodb_force_recovery来对MySQL服务进行修复启动。
参数innodb_force_recovery选项：
参数innodb_force_recovery设置：
在配置文件中的mysqld模块添加参数innodb_force_recovery。
相同参数innodb_force_recovery在不同MySQL版本允许的操作可能不同，所有版本中innodb_force_recovery>0时都允许对表进行SELECT操作。
使用参数innodb_force_recovery建议：
在日常运维中，应将使用innodb_force_recovery参数进行数据恢复作为最后手段，做好完善的备份恢复机制，避免对数据库做高危操作。
