原文地址 : https://dbaplus.cn/news-11-5623-1.html
一、如何看待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)个人运维经验无法有效的沉淀转化
所以这是一个综合的问题，涉及到对技术、业务和人的管理，而且是环环相扣。
当然对于一件事情的基本逻辑越简单，实现起来也更聚焦。所以我们进一步提炼了一下目标，7->2，即7个分支技术栈整合为2个，在这个基础上进行生态技术栈的补充和完善。
（三）数据库版本升级的意义
做这件事情有什么好处呢，也就是所谓的意义，我觉得是：降本增效，提高整体业务稳定性。主要体现在如下六个方面：
- 应对未来3年内的数据库基础服务风险，对后续的数据存储平台架构迭代奠定基础（这个需要由明确的规划支撑）
- 通过版本升级提高整体业务性能和稳定性
- 实现支持系统的一致性，提高基础服务支撑能力
- 将单点业务迁移至MySQL主流技术栈，预防故障风险
- 对开发规范和SQL审核机制进行规范化支持和落地
- 为后续的环境标准化建设提供实践经验
我从公有云和私有云的视角盘点了下MySQL技术栈发展的情况，其实MySQL 8.0已经成为了行业主流的基线版本，各种数据库产品层出不穷，如果基线版本已经落后了，后续势必会有整合和返工，所以这也算是一个技术的战略点。在协议兼容的前提下，还需要进一步考虑到国产化数据库的影子，当然也可以有更多的选择，重心在于协议和生态技术栈兼容。
毕竟数据库的升级是一项大工程，大开大合，研发同学再配合支持也需要权衡，所以MySQL 8.0的大版本基础之上，在满足驱动和协议兼容之后，后续的小版本和迭代升级计划都是在8.0的体系之内完全平滑闪断完成，也就不需要研发同学全程跟进了。
（四）数据库版本升级的潜在难点
当然任何事情都得多面看，看到好处（意义），也需要看到难点：
- 跨中心多团队协作，周期较长
- 开发语言技术栈有7个，MySQL 8.0的驱动兼容性都需要充分考虑
- 部分升级改造需要研发侧支持旁路数据双写
- 根据数据库拓扑关联主机业务的亲和性，避免服务器故障
- 按照业务特点和优先级制定差异化升级方案
- 基于滚动模式的数据库资源全量替换，避免资源冗余
- 制定平滑的MySQL集群迁移方案，对业务侵入性最低
因为我们升级的基调是平滑模式，所以基本是资源平替，快速切换的实现策略，在这种情况下，每一个数据库实例都需要反复确认，会有大量的沟通协调工作，况且业务不能停，因为数据库升级直接影响到业务使用，这件事情的性质也就变了。
二、通过五个方面保障数据库升级的稳定性
整个数据库版本升级，不是单单有标准版的主从集群，还需要考虑到中间件集群，因为NewSQL集群上线已经完成了兼容性测试，所以不在本次升级的考虑范围之内。
通过这项梳理也能够基本明确其他分支技术栈该如何做方案设计。
（二）制定升级策略
1、整体升级策略
这场数据库版本升级的大迁徙，是从7个分支技术栈收缩为2个，所以需要对不同的分支技术栈规划落地方案，整体上我们是倾向于让MySQL 8.0承载尽可能完整的业务。
因为上一步明确了数据库版本升级的范围是标准版和中间件集群和其他分支技术栈，则需要制定相应的升级策略。
2、标准版升级策略
对于标准版主从来说，如果是MySQL 5.5,5.6版本，需要先过渡到MySQL 5.7，完成兼容性测试之后，观察一段时间之后，再次升级到MySQL 8.0；如果是MySQL 5.7版本，则可以直接升级到MySQL 8.0。
因为上一步明确了数据库版本升级的范围是标准版和中间件集群和其他分支技术栈，则需要制定相应的升级策略。
2、标准版升级策略
对于标准版主从来说，如果是MySQL 5.5,5.6版本，需要先过渡到MySQL 5.7，完成兼容性测试之后，观察一段时间之后，再次升级到MySQL 8.0；如果是MySQL 5.7版本，则可以直接升级到MySQL 8.0。
3、中间件集群升级策略
对于中间件集群来说，整体的思路还是做拓扑下沉，即通过级联的方式，把从库提升为主库。
4、其他分支技术栈升级策略
对于其他的分支技术栈来说，这些技术栈早期也确实解决了一些业务厄待解决的问题，随着MySQL 8.0的性能提升和集群技术的迭代，需要做一些整合。
- TokuDB迁移至TiDB
- Infobright迁移至MySQL 8.0
- 对于一些历史遗留业务，还需要研发协助完成数据旁路双写
所以整体来上来看，数据库版本升级不是单一升级到8.0，在策略上需要考虑完整。
（三）定制化升级列表
如果有成百上千个实例要落地升级计划，显然是一件庞大的工程，某个业务有几十个实例，断断续续地沟通，研发同学也受不了，而且整体的进度也不好控制，所以我们是从两个维度来做梳理和整合的。
- 先按照数据库版本把所有业务的信息都梳理出来，比如MySQL 5.6,MySQL 5.7的，可以整理成不同的tab页，按照业务负责人进行汇总；
- 然后按照不同的业务大类或者业务负责人，把上面这个数据中的信息提取出来，这样就形成了业务视角的数据库升级计划，基本就可以开始和研发同学沟通了；
- 当然沟通也不能全靠嘴，还需要一些标准化的文档，比如我们整理了不同版本升级需要注意的事项，把整个过程需要研发协助的事情都列清楚，避免重复的解释和无效沟通；
- 最后是回退方案，这应该是整个方案里面研发同学最关心的部分了，毕竟先把最坏的结果考虑到，一旦发现问题也能及时处理。
如下是我们计划和研发同学进行的沟通的双方协作的流程。
....
详情请查看原文 : https://dbaplus.cn/news-11-5623-1.html