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

wubx
833 阅读12分钟

首先来说MySQL升级后性能下降，在我从事MySQL DBA这10多年中也遇到几次，而且排查难度比较大。这里给大家提供一个MySQL升级管管理方案供大家参考。内容较长，建议收藏后以方便查阅。

本篇文章结构如下：

  1. MySQL为什么要升级，大概多久进行一次

  2. 升级前升级中升级后关键事项以及需要业务应用侧配合事项

  3. 如何规划MySQL升级方案

  4. 如何规划MySQL升级回退方案

  5. 怎么避免MySQL升级后造成性能下降

  6. 升级后性能下降问题诊断及性能优化解决思路

  7. 总结

第一：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和升级前进行对比

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

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

升级后收尾及相关工作：

  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%的时间花在测试上。真正的升级，可能利用自动工具，也可以非常快的完成。

本文使用 文章同步助手 同步

avatar
文章
阅读
粉丝