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

当然对于一件事情的基本逻辑越简单，实现起来也更聚焦。所以我们进一步提炼了一下目标，7->2，即7个分支技术栈整合为2个，在这个基础上进行生态技术栈的补充和完善。
（三）数据库版本升级的意义
做这件事情有什么好处呢，也就是所谓的意义，我觉得是：降本增效，提高整体业务稳定性。主要体现在如下六个方面：

应对未来3年内的数据库基础服务风险，对后续的数据存储平台架构迭代奠定基?。ㄕ飧鲂枰?擅魅返墓婊?С牛?/li>
通过版本升级提高整体业务性能和稳定性
实现支持系统的一致性，提高基础服务支撑能力
将单点业务迁移至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 。