线上生产故障处理思路及流程 mysql8.0 linux 磁盘io利用率高

### 作为DBA运维的你是否有过这些苦恼 1）什么？又有告警啦，CPU咋又飙高啦？IO又打满啦？对服务器赶紧一顿操作猛如虎，然并卵，故障犹如股市大盘，依然坚挺，还有客户、领导在后面排队督军，此时谁来help我呢？ 2）有时候出去面试，明明感觉和面试官聊的很好，但面试完成后就没有后续，是否有过疑惑，这是why？ <!--more--> ### 面试官：请给出数据库实例所在的物理机上CPU飙高及IO飙高的故障排查思路。 应聘者：可以先查看当前系统的性能，然后在查看一下数据库的会话，一般都是慢日志导致的，针对慢sql优化进行话题展开。 面试者：如果io飙高确认不是慢sql导致的，该如何排查呢？ 应聘者：啥？啥？啥？弄啥嘞？这该怎么回答，我也没遇到过啊，心中万只草泥马在奔腾。 ## 一 、心中有章，遇事不慌 比生活中买彩票中奖率高的就是我们运维中遇到的一些性能问题了：业务接口响应慢了、数据库卡了、服务器性能飙高了、数据库异常宕机了、业务时快时慢等意想不到又在情理之中的问题。那么，我们第一次（或多次）遇到又该如何处理呢？ ### 一整套故障排查及应对策略送给你，让你像包拯一样断案如神： ### 首先 我们碰到问题之后要做到心中有章（章程），遇事不慌。先沉着冷静，仔细了解故障现象（如果收到报警信息，则需要进行报警信息确认；如果是客户/用户反馈问题，要和客户确认现象，有时客户/用户反馈的问题不一定准确，为了缩短故障判断，我们需要确认故障现象来避免我们问题排查时进入思想误区）； ### 其次 我们需要根据故障现象来进行初步分析，例如：操作系统性能，我们要先查看操作系统当前的性能指标，确定是哪个应用程序导致的，如果是某个应用程序有问题（MySQL宕机），则需要进行日志收集； ### 然后 确定了应用程序后我们可以进行具体分析。例如查看日志输出，使用性能工具进行分析（perf、pstack、pidstat、strace等）； ### 接着 通过日志或者现象我们可以得到部分结论，通过部分结论继续排查及论证，类似于包拯破案，层层抽丝剥茧，完善整个故障链条，针对同一个故障现象进行反复论证，防止出现冤假错案，也使最终结论更有说服力及专业性，让领导、客户、用户、伙伴都认可放心； ### 最后 我们针对问题已经有了具体分析，也有了结论，我想故障该如何解决并避免等后续问题，你心中应该有答案了。此时就可以梳理成故障报告，昭告天下喽~ ## 二、真实案例，我们能赢 说了这么多理论，想必你感兴趣的是货真价实的实践了，那么我们就拿一个真实案例进行分析——当数据库所在的实例IO高，该如何分析处理： ### 3.1 故障处理场景 岁月静好，阳光慵懒的午后，某人正在享受熟睡的香甜。突然的信息打破了温馨的画面... 什么！？？？ 收到一条某客户的数据库实例所在的宿主机磁盘io利用率高的报警信息！ 这会导致客户的业务系统运转缓慢，万里的服务准则是优先保障客户业务正常运转！ 运维DBA小伙伴瞬间惊醒，开始在键盘上运指如飞，大脑指令也在飞速运转。 - 报警10s后：登录涉事服务器检查一下当前系统状态 - 大脑报告：目前系统load负载高，成上升趋势，cpu等待io的响应时长较高，说明故障刚发生没多久，可能存在磁盘io压力 - 报警12s后：检查当前各个设备的磁盘IO情况 - 大脑报告：目前数据库所在的sda磁盘块设备io读写压力较大 - 报警17s后：检查sda磁盘块的每秒读写比例 - 大脑报告：目前sda磁盘块压力较大，每秒写入比每秒读差距较大，说明当前存在大量的io写入 - 报警23s后：快速检查一下sda磁盘中哪个应用程序占用的io较高（单台物理机多实例部署） - 大脑报告：通过pidstat发现，确实是数据库（某个实例）的io比较高，且该实例部署在sda磁盘中，pid为73739 - 报警30s后：快速分析该数据库实例哪一个线程占用io比较高 - 大脑报告：目前是74770这个线程占用的io比较高 - 报警40s后：分析这个线程在干什么 - 大脑报告：目前这个线程在写入多个文件，文件句柄号有64、159 - 报警50s后：看看这个文件句柄是什么 - 大脑报告：这个线程在大量写入临时文件 - 报警60s后：通过线程号，看一下对应的会话信息 - 大脑报告：目前有一个sql执行了67s，且此sql使用了group by和order by，同时通过会话列表进行确认 - （故障已定位并反馈，进行相应的应急处理….） - 故障汇报后：分析一下慢sql，并和客户业务方沟通处理 - 大脑报告：已在进行中 具体的实操步骤请详见[故障分析 |MySQL8.0 linux 磁盘io利用率高，分析的正确姿势](https://mp.weixin.qq.com/s/7cu_36jfsjZp1EkVexkojw "故障分析 | linux 磁盘io利用率高，分析的正确姿势") （该案例根据真实案例改编） 经过上述一顿猛如虎的操作和排查，1-2分钟内快速定位了问题原因，且及时和客户业务方进行沟通，最大化地减少并避免了业务受到的影响。同时，在故障排查过程中保留了排查步骤及结果图，故障处理完成后进行故障报告编写，全流程专业、顺畅、有序的操作得到了客户的认可与肯定。 ## 复盘 故障排查结束后 万里的技术团队在做什么？ 继续完善及挖掘监控漏洞 本次故障是监控系统先于业务发现故障，在业务感知前及时发现并进行了处理，没有造成任何对业务不利的影响，在监控预警阶段就把问题扼杀在摇篮里，充分体现了监控预警的重要性，后续还得继续挖掘及完善目前监控不到的信息，保障监测全面、准确； 继续整理各种故障场景预案 针对常见的不同类型故障场景做好预案方案的梳理和筹划，形成完备的故障处理操作指南库，指导实际业务中的工作有序、快速、准确完成； 针对特定的故障排查思路制作自动化工具 万里DBA团队针对特定或相同的工作流程进行工具化处理，实现自动分析，缩短人为处理的时间，最大程度实现重复、简单工作的自动化、智能化响应处理。 ### 说了这么多干货和方法，小编想告诉大家： 作为一名从业多年的DBA运维人员，业务系统出现故障并不可怕，可怕的是我们没有任何思路和解决方案，出现问题时措手不及，影响了客户的业务运转，引发客户对公司技术团队专业能力的质疑。 转载自： >https://mp.weixin.qq.com/s/uhgfphXfrrty6jOME6QRZQ