MySQL升级到8.0版本的一些经验 _MySQL

MySQL版本升级工作，从2022年上旬开始规划到生态完善实施了近1年，得到了多个中心研发团队的大力支持和理解。MySQL数据库也从原本的7个技术栈收缩为2个，挑战和难度在落地时才发现比预期的要复杂不少，为了保证业务的稳定性和研发工作的侵入度最低， DBA团队也制定了完整的数据升级流程和业务切换方案，并对业务异常的回退进行了全流程准备，整个过程零故障。一、如何看待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审核工具解决了早期的研发规范问题，后续闭源难以持续