5.7停服倒计时！关于MySQL升级到8.0版本的一些经验 _MySQL

作者介绍
杨建荣，竞技世界数据库专家、dbaplus社群联合发起人，腾讯云TVP，Oracle ACE，《Oracle DBA工作笔记》和《MySQL DBA工作笔记》作者；现就职于竞技世界，擅长数据管理、数据迁移、性能优化，目前专注于开源技术、运维自动化和性能优化，坚持写技术博客，已坚持2400多天。
数据库是基础资源的重要组成部分，随着业务的发展，数据库版本升级的话题自然会摆上桌面。
一、如何看待MySQL版本升级
关于数据库版本升级，一直都是热议话题，对于升级的缘由各家也有所不同，有业务驱动的，有DBA自发驱动的，有规划导向也有方向指引的……抛开各种原因，当升级这个决定落下来的时候，对于DBA手头的几百几千套数据库来说，就好比是一场动物大迁徙，满满的画面感。
从Oracle发布的版本生命周期规划可以看到，MySQL5.7已经走到了生命周期的终点，意味着后续将不再为 MySQL 5.7 提供官方更新、错误修复或安全补丁。

文章插图
阿里云和AWS都在官方公布了版本支持计划，MySQL 5.7版本已经开始了倒计时。

文章插图
而要想让这件事情获得研发同学的大力支持，就需要平滑升级或者最低成本的改动。所以对于这场迁移的基本要求，我在心里默默对自己提了要求：零故障，平滑升级。
（一）行业内的MySQL版本数据情况
我在2022年底左右调研了下行业内的一些公司的MySQL数据库版本情况，列表如下：

文章插图
可以看到大部分的公司还是在MySQL 5.7这个版本，而且从服务规模来看，越是规模大的公司，要想做整体升级这个事情的复杂度就会高出几个数量级。
（二）我们做数据库版本升级的理由
我们做这件事情是从规划导向来切入的，也有一部分DBA自驱的因素。说是规划导向，转义过来就是不打无准备之仗，MySQL后续的整体架构是构建在基础存储之上的，如果基础存储存在瓶颈，对于后续的架构演进也存在明显短板，所以我们在2019年底就开始调研并小范围在新业务中试点MySQL 8.0了。
如下是早期调研中对于MySQL 8.0和MySQL 5.7使用sysbench压测的一些信息供参考，可以看到MySQL 8.0是有明显性能提升的。至于MySQL 8.0的版本，我们的考虑是和验证测试的8.0.19保持一致，在后期支持新版本的无缝升级。

文章插图
从功能上来说，开发特性更加丰富，SQL优化效果和运维功能上都有明显的提升，在兼容性方面会更加严格（兼容性严格具有两面性）。

文章插图
在经过了一个相对稳定的周期验证之后，无论从稳定性、性能和功能方面确实达到了预期的效果，有一些特性确实解决了当时的一些运维问题。
说是DBA自驱的理由，是因为我们盘点了一下近些年来的MySQL技术栈使用情况，发现实际的情况比我们预想的要差一些，比如MySQL 5.5我会定义为一个分支技术栈，以此类推，我们目前存在7个分支技术栈。

文章插图
在这些因素的基础之上，我们以点带面展开分析，发现多分支技术栈散乱只是表象，还有一些潜在问题和瓶颈问题：
1、MySQL版本过旧，架构管理不一致，运维复杂度较高
1) MySQL 5.5和5.6为过旧技术栈，官方已不再维护
2) 未来3年内需要从MySQL 5.7升级至8.0 ，演进复杂度高
3) 40%操作系统版本过旧，后续的数据库版本升级存在风险
2、部分技术栈已闭源，服务异常时存在恢复风险
1) Infobright已转为商业版维护
2) TokuDB已于2020年不再维护
3、数据库规范和审核机制难以支撑现有的业务需求
1) SQL审核工具解决了早期的研发规范问题，后续闭源难以持续
2) 数据库开发规范已4年未更新，部分开发规范已难以满足业务需要
4、人员稳定性和持续发展
1)DBA不可避免地在做一些重复劳动，一些繁琐的差异化操作势必会削弱工作热情，也会发生一些意料之外的异常
2)个人运维经验无法有效的沉淀转化
所以这是一个综合的问题，涉及到对技术、业务和人的管理，而且是环环相扣。