【MySQL】关于MySQL升级到8.0版本的实践方案
关于MySQL升级到8.0版本的实践方案
关于数据库版本升级，一直都是热议话题，对于升级的缘由各家也有所不同，有业务驱动的，有DBA自发驱动的，有规划导向也有方向指引的……抛开各种原因，当升级这个决定落下来的时候，对于DBA手头的几百几千套数据库来说，就好比是一场动物大迁徙，满满的画面感。
从Oracle发布的版本生命周期规划可以看到，MySQL5.7已经走到了生命周期的终点，意味着后续将不再为 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优化效果和运维功能上都有明显的提升，在兼容性方面会更加严格（兼容性严格具有两面性）。
在这些因素的基础之上，我们以点带面展开分析，发现多分支技术栈散乱只是表象，还有一些潜在问题和瓶颈问题：
1、MySQL版本过旧，架构管理不一致，运维复杂度较高
-
MySQL 5.5和5.6为过旧技术栈，官方已不再维护
-
未来3年内需要从MySQL 5.7升级至8.0，演进复杂度高
-
40%操作系统版本过旧，后续的数据库版本升级存在风险
2、部分技术栈已闭源，服务异常时存在恢复风险
-
Infobright已转为商业版维护
<