写点什么

MySQL 数据库升级后如何防止性能下降

  • 2021 年 12 月 16 日
  • 本文字数:4062 字

    阅读完需:约 13 分钟

第一:MySQL 数据库为什么要升级,大概多久进行一次

首先 MySQL 的每个版本有相应的 Endlife 周期,现阶段 MySQL 的 Endlife 周期如下:



从上图来看,当前处在官方支持生命周期的版本是 MySQL 8.0, 其中 MySQL 5.7 处在 Extended Support 也就意味着只会做安全方面的更新,其它的方前端培训面不在处理,MGR 的很多特性就没在往 5.7 中合并。所以当前最佳的方式是升级到 MySQL 8.0。那么我们接来来聊一下多久进行一次升级。这块大概可以分成三种情况

a. 依据产品形态定位升级时间

b. 依据服务的性能指标及成本做决定

c. 依据于使用到的 MySQL 特性做决定

以上三点,如果从升级的必要性角度看,可以反过来看。如果从业务角度出发可以正着看。

我这里首先从业形态上描述一下,对于依据产品的形态定位升级时间可以这么理解,我给大家举一个例子,例如我经历的产品有:SNS, 邮件系统,彩票系统,IM,电商,支付,直播等相关业务。其中邮件系统就是一个非常特殊的业务,他对 DB 的依赖不是特别大,对于数据库的使用,只需要记录用户认证及邮件列表的一些信息,并发要求也不高,所以现在还有一些系统跑在 MySQL4.1 上还是运行的很好,很多系统已经超过 1500 天以上没有重启的都有。对于这类业务,基本没有升级的必要,对于 MySQL 依赖非常轻,只是简单的 CRUD 使用,升级并不能带来特别大的提升,反而增加了复杂度。

另一类业务属于高速增长的业务:SNS,彩票,IM,电商,支付,这种系统基本上对性能都有较强需求,好的性能意味着更好的用户体验。一般情况下这种业务建议是出现大版本更新可以升级,例如:MySQL 5.5 比 MySQL5.1 的性能好, MySQL5.6 比 MySQL5.5 的性能好,MySQL 5.7 又比 MySQL5.6 的性能好,MySQL 8.0 是功能丰富了很多对于开发,DBA 管理等方面都更加友好,而且如果你的硬件在 32 个 core 以上,也可以考虑升级到 MySQL8.0,如果硬件比较旧(cpu core 小于 32, 没有使用 ssd 以上的盘)也不能获取升级到 8.0 性能优势。

所以针业务形态定位这块一般建议是出现大版本更新,MySQL 大版本稳定后可以安排升级,通过时间间隔在 1-2 年的情况,另一类对数据依赖不大的业务,没遇到 Bug 也可以不用升级。

依据于服务的性能指标及成本做决定。从目前的经验来看 MySQL8.0,MySQL 5.7 的性能基本是吊打以前的版本,同样对资源的利用率也更高了,所以在 MySQL 5.7, MySQL 8.0 这两个版本可以说 MySQL 非常优秀的版本。对于这两个版本推荐使用 MySQL 8.0,如果条件(机器资源烂)也可以考虑使用 MySQL 5.7。通常情况下公司的业务也在发展,MySQL 新版本的升级总可以带来正向的促进,也促进公司的技术人员更加关注新知识的发展。

这里我们再来看看使用到 MySQL 的特性来决定,也是最重要的一点。使用到特性主要是指的:CRUD 的使用,复制,MGR 等三个方面,对于 CRUD 的更关注在 MySQL 的 SQL 解析,连接数,Buffer 的优化,索引的优化这块基本是随着版本的升高,都会有相应的优化;接下说一下复制,目前 MySQL 的复制可以说到 MySQL5.7 才算真正处理的完美,所以使用到复制功能的人,使用 MySQL 的最低版本应该是 MySQL5.7 并开启基于 writeset 的并行复制,这个特性在 MySQL8.0 中优先实现,后来合并到 MySQL5.7 中;接下来说一下 MGR 这个特性,如果你已经使用到 MGR,你是属于技术激进派的,同时也恭喜你现在 MySQL8.0.22 及以后的 MGR 非常的稳定了,可以使用了。但 MGR 还算是 MySQL8.0 中比较新一个特性,每个小版本中也会有一些特性的更新及 Bug 修复,所以建议使用 MGR 的朋友,如果现在你还是使用 8.0.23 以前的版本,可以考虑升级到 8.0.23 后版本。对于使用比较新的特性,需要关注每个小版本,如果小版本中有重要的修复,也可以安排小版本出来测试,一个月左右进行升级,这个在企业版本客户中特别常见。


第二: 升级前升级中升级后关键事项以及需要业务应用侧配合的事项

数据据库升级是一个全公司需要一起行动的工作。在这里我们可以先把工作,分为升级前, 升级中,升级后的关键事项及业务应用侧需要配合的事项。

升级前准备及相关工作:

1. MySQL 的版本升级必要必能对比。功能性验证,bug 验证,性能验证

2. 最优配置文件确定

3. 功能环境验证新版本,同时给开发人员讲解新版本的特性及使用上注意事项

4. 带业务(核心业务的)性能测试,这个步骤需要按生产环境部署

5. 确认可以升级停业务的时间,采用不同的升级方案

6. 升级后 checklist 制定

7. 预期升级后的对比点


升级中执行及相关工作:

1. 当晚工作分配列表及时间规划

2. 应用对于 DB 服务中断的处理策略,好的升级方案,可能只需要 DB 中断服务在秒级别以下,在升级方案中详讲。

3. 升级执行前停止数据库对应系统的报警及报警升级

4. 升级中业务进行日志观察

5. 数据库 OPS,DML 和升级前进行对比

6. 新上线的 DB 系统加入监控报监控系统

7. 回退系统部署方案及知会开发


升级后收尾及相关工作:

1. 升级后的运行情况报告

2. 开发侧数据库相关日志收集及对比

3. 回退系统下线

从上面策略上看可以说把更多的工作压到前面来做,特别是升级前的的准备工作也占用大量的时间的工作。在这个环节上 DBA 的测试工作也比较多。

对于升级方案,涉及到产品功能验证,bug 验证,性能验证,升级方案的确定等。 凡是涉及到升级可能就会涉及到 MySQL 的性能有提升,或是遇到重要 Bug。这块其实有一个技能被大家忽略了:就是官方发布的 mrr test 测试。做为我们个人,可以通过把低版本的 mrr test 放到目标版本中测试,可以对比一下两个版本在同样的配置下 mrr test 跑完的时间,及具体 case 跑完的时间,通过该测试从 DBA 角度可以评估出来现在使用的版本和将要升级的目标版本间的差距。该操作可以反过来进行,把高版本的 mrr test 放到低本下跑一次,可以看看具体修到的 Bug 及对应的东西,友情提示,该工作需要一个强劲的机器,同时是一个比较花时间的过程。建议认真阅读 change log 找对应的修复,测试对应修复关心的问题即可。接下来可以通过 sysbench, mysql-tpcc 这类工具对两个版本压测试,得出来一个较佳的配置文件, 同时得出来两个版本在 Bug,性能上全方面数字量化升级指导意见。后续就可以交给功能测试和性能测试的同事介入了。


第三: 如何规划 MySQL 升级方案

对于升级案最佳的方案就是少停机,尽量减少对业务的影响。这里给一个兼顾回退方案的方案的升级方案,也是我认为比较稳妥的一个升级方案。利用复制技术升级。大致步骤如下:



在第 2 步骤时,可以通过添加一个从库,只用于数据同步,确认没有问题后可以入 Proxy 或是 DNS 中对外提供服务,遇到问题可以立即下线。

第 3 步,可以把原来其中的一个 slave 也升级到新版本上。



第 4 步,可以把所有读请求转到从上库上,原始的从库版本不用对外提供服务;观察俩个新的 slave 对外服务的情况。

第 5 步, 通过 HA 切换把原来的 Old Master 切换成从库,并提供对外服务,确认没有问题时把原来最后一个从库也升级到最新版本

第 6 步,把原来的版本 slave 停止对外服务,全部使用新版本对外提供服务。

该升级方案的好处,基本上可以白天用于数据准备工作,新节点创建,老节点替换等,在业务低峰期,也只是更新一下 Proxy 配置或是走一个 HA 切换,相对来讲对外影响非常小,回退处理也相当容易。


这块可以使用到的技术:

proxy 推荐:ProxySQL

HA 切换推荐:Orchestrator, Xenon

如果不想用 Proxy 那么 Zookeeper, Consul,etcd 也可以使用。


第四:如何规划 MySQL 升级回退方案

一个好的升级方案是自带回退,进可攻,退可守,例如上面的方案,就属于一个优秀的升级方案。 如果基于上述方案中进行,对于任何一个失败点,在第 6 步前,都可以轻易回到旧版本中对外提供服务,这个过程可能就是需要多浪费一台机器,也可以说是一个实例,在多实例环境,这种方案处理着非常容易。在我处理的客户环境通常建议他们全局各每一种的端口号是唯一的,所以通过多实例来处理比容易上手。


第五: 怎么避免 MySQL 升级后造成性能下降

大多数情况下 MySQL 升级后会有一定的性能提升,但也不可避免出现性能下降的现象。例如我遇到性能下降问题:MySQL 升级后某个业务超时严重, 当时的问题我们在升级数据时,开发也更新了应用,造成大家对于这个问题有点不好对比。所以尽量在升级时尽量业务侧的变更,引入较少的变量。对于升级后性能下降的避免方法,我最大的经验是一定要做好:性能测试,基本业务的性能测试,也可以说是一个全链路性能测试采样对比。


第六: 升级后性能下降问题诊断及性能优化解决思路

这个问题可以说是 DBA 工作中一个重点任务,也是一个非常复杂的问题。这里尽量假设时你已经保证性能测试,功能测试,带业务的功能测试都过了,在功能环境,性能环境确认新版本是有性能提升。最后上线,又出现新性能问题。 那么这个时间出现性能问题,可以通过对比 sys.statement_analysis 中的内容,看看是不是有和功能环境不一致的 SQL,另外也可以结合慢日志查看和以前的慢日志内容是不是一致,通过这两条基本上很容易对比出来性能下降的点。如果使用的 ProxySQL 也可以在 ProxySQL 中查看每个 SQL 的响应时间分布,对于性能问题排查还是比较容易。通过对比 SQL 样品表,比较容易找到原因。另一类问题遇到统计信息失效,show processlist 显示大量的 Statics 相关的信息,可以通过收集索引信息或是重新整理表空间清除;还有一个类是字符配置错误,造成索引失效。


第七:总结

到今天为止 MySQL 技术非常成熟,很多公司已经把 MySQL 也定位在微服务架构中的一个持久化服务,使用上比较容易上手。但对于升级这个环节,如果为了减少问题,尽可能花更多的时间去测试。同样需要慢慢完善数据库的架构,这样后面升级管理方面也更加友好。

升级中遇到问题是否可以快速定位,我觉得有两方面的能力,一方面是 MySQL DBA 的基本技能能力,另一方面是对业务熟的程度,这个也是我在面试中或是同事考核中比较看重的,例如:核心系统,核心表是哪些,核心 SQL 是哪些,大概每天的请求量分布是什么样,高峰期核心库的 DML 操作量是多少,整个业务系统大概有多少条唯一的 SQL,如果能对这些问题清楚的了解,那么对整个系统的性能问题的排查就相当容易了。也可以说升级是一个对全体人员要求比较高的工作,也是一个需要配合的工作,同时也希望把 80%的时间花在测试上。真正的升级,可能利用自动工具,也可以非常快的完成。

原创作者:吴炳锡

用户头像

关注尚硅谷,轻松学IT 2021.11.23 加入

还未添加个人简介

评论

发布
暂无评论
MySQL数据库升级后如何防止性能下降