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

2) 数据库开发规范已4年未更新，部分开发规范已难以满足业务需要

4、人员稳定性和持续发展
1)DBA不可避免地在做一些重复劳动，一些繁琐的差异化操作势必会削弱工作热情，也会发生一些意料之外的异常
2)个人运维经验无法有效的沉淀转化

所以这是一个综合的问题，涉及到对技术、业务和人的管理，而且是环环相扣。

当然对于一件事情的基本逻辑越简单，实现起来也更聚焦。所以我们进一步提炼了一下目标，7->2，即7个分支技术栈整合为2个，在这个基础上进行生态技术栈的补充和完善。

（三）数据库版本升级的意义
做这件事情有什么好处呢，也就是所谓的意义，我觉得是：降本增效，提高整体业务稳定性。主要体现在如下六个方面：

应对未来3年内的数据库基础服务风险，对后续的数据存储平台架构迭代奠定基?。ㄕ飧鲂枰?擅魅返墓婊?С牛?/li>
通过版本升级提高整体业务性能和稳定性
实现支持系统的一致性，提高基础服务支撑能力
将单点业务迁移至MySQL主流技术栈，预防故障风险
对开发规范和SQL审核机制进行规范化支持和落地
为后续的环境标准化建设提供实践经验

我从公有云和私有云的视角盘点了下MySQL技术栈发展的情况，其实MySQL 8.0已经成为了行业主流的基线版本，各种数据库产品层出不穷，如果基线版本已经落后了，后续势必会有整合和返工，所以这也算是一个技术的战略点。在协议兼容的前提下，还需要进一步考虑到国产化数据库的影子，当然也可以有更多的选择，重心在于协议和生态技术栈兼容。

文章插图

毕竟数据库的升级是一项大工程，大开大合，研发同学再配合支持也需要权衡，所以MySQL 8.0的大版本基础之上，在满足驱动和协议兼容之后，后续的小版本和迭代升级计划都是在8.0的体系之内完全平滑闪断完成，也就不需要研发同学全程跟进了。

（四）数据库版本升级的潜在难点
当然任何事情都得多面看，看到好处（意义），也需要看到难点：

跨中心多团队协作，周期较长
开发语言技术栈有7个， MySQL 8.0的驱动兼容性都需要充分考虑
部分升级改造需要研发侧支持旁路数据双写
根据数据库拓扑关联主机业务的亲和性，避免服务器故障
按照业务特点和优先级制定差异化升级方案
基于滚动模式的数据库资源全量替换，避免资源冗余
制定平滑的MySQL集群迁移方案，对业务侵入性最低

因为我们升级的基调是平滑模式，所以基本是资源平替，快速切换的实现策略，在这种情况下，每一个数据库实例都需要反复确认，会有大量的沟通协调工作，况且业务不能停，因为数据库升级直接影响到业务使用，这件事情的性质也就变了。

二、通过五个方面保障数据库升级的稳定性
【MySQL升级到8.0版本的一些经验】接下来我会从如下的几个方面来保障整个升级过程的稳定性。

（一）梳理和确认目标和范围
整个数据库版本升级，不是单单有标准版的主从集群，还需要考虑到中间件集群，因为NewSQL集群上线已经完成了兼容性测试，所以不在本次升级的考虑范围之内。

通过这项梳理也能够基本明确其他分支技术栈该如何做方案设计。