昨天一个同事晚上7点多给我发了微信消息：一客户的数据库最近总挂（也就是hung住了，挂起），也找不到原因。有时候挂在执行存储过程，有时候挂在JAVA程序做文件入库，有时候程序执行SQL时，实在没辙了。
这样的问题反馈，其实我也是挺懵逼的，没有环境信息，只能从开发同事这里了解到并不是很清晰的信息，因此需要按照自己平时处理问题的思路，来让同事取要相关信息。同时，也记录一下自己的思路。
首先，了解环境信息。
软硬件（物理机/虚拟机：虚拟机，CPU类型x86/arm：x86，配置资源-CPU/内存/存储：4c/8g/IBM 5000）
环境类型：测试/生产：测试。测试环境也要重视，基线等一般会和生产相类似
数据库版本：8.0.21
数据库安装方式：RPM/二进制/源码：RPM。不要忽略了安装的细节。
数据库基线：包括操作系统的配置sysctl.conf，security.conf以及用户profile，MySQL的参数文件my.cnf。这里要说明一点，用户profile不能忽视，里面可能会设置某些特性变量。
其次，问题现象的的描述不能放过
从业务/开发端去了解问题现象：本次则是直接从开发同事了解了信息，从描述的几种挂的场景，都有一个共同特性，那就是对数据库在进行操作，而这几种操作的共性就是会造成大量IO操作。往往很多运维分析都忽略了业务/开发端的情况，只站在运维角度，从操作系统、数据库等查起。实践经验告诉我们，不能陷入思维怪圈，要跳出来全面考虑。
从后端运维去了解问题现象：通常为一线人员，对于环境信息收集以及沟通来说更便捷（都是运维出身，会在一个频道上）。
再次，去找问题发生时的信息
问题是发生过去，因此看现在的状态信息并没有多大的作用，那么能保存当时信息的都有哪些？
数据库错误日志（也称告警日志）：已拿到
操作系统的messages日志：未拿，本次忽略了
监控系统：测试环境未部署，裸跑
最后，通过以上信息开始排查分析
基于以上所构成的信息，梳理一下思路。
开发同事的反馈，初步定位跟IO关联性较大。
数据库版本是8.0.21从官网上看了release note也未发现和IO直接关系的bug。
查看数据库错误日志，在
SEMAPHORES
、TRANSACTIONS
、FILE I/O
几处都有等待
FILE I/O
这张图，是一直有等待异步IO的现象，如果存储不是很差，是不会出这样的问题。
SEMAPHORES
这张图，红框处，是在执行fil0fil.cc
的8498行时出现等待，去翻阅源码，可以看到是 innodb_flush_method的代码，这里不解释其含义了，主要也印证了是IO问题没错。客户环境设置的是O_DIRECT ，我们一般也都会设置这个值。如果性能确实存在很严重的IO问题，可以考虑将其设置O_DIRECT_NO_FSYNC。
从拿到的MySQL配置文件my.cnf
中，可以看到其基线中规中矩，设置的都还挺合理的。
总结一下
分析的结果是I/O问题没错了，那么客户的操作系统及数据库基线也都OK，能引起IO问题的那能是什么呢？
第一个是存储，客户用的是IBM v5000，终端存储，性能也不差，按照开发反应的现象以及操作数据量，可以排除掉。
第二个是虽然我们检查了基线是没问题的，但好像忽略了一个重要的点–系统安装包。告警日志中是体现了异步IO的请求等待，而且也看到了存储其实是不差的。
经与客户确认操作系统没有安装libaio
及libaio-devel
包。MySQL的异步I/O是依赖操作系统原生AIO的，未开启AIO，会严重影响数据库的并发性、高性能。在部署Oracle时，这个也是必不可少的。当然，所有的数据库在部署时，都记得要安装这个包。
