2023年6月24日发(作者：)

⼀次业务Connectionisnotavailable,requesttimedouta。。。刚⼊职公司接触到的第⼀个项⽬，应⽤架构⽐较简单和⽆理1、业务是推送数据到ldap数据库，应⽤是java写的2、架构是两台mysql主主复制，haproxy做两台mysql的负载（ps：由于应⽤代码的逻辑，导致haproxy只能把流量切换到⼀台数据库），keepalived做⾼可⽤3、现象是：业务端⽇志总是提⽰Connection is not available, request timed out after 30000ms，⼏率出现的⼤⼩为30%~50%之间，线上服务器没有监控4、由于没有任何的监控系统，所有信息都只有从头收集，第⼀步检查了应⽤和vip之间的⽹络，直接⽤的ping，查看后均正常，第⼆步，查看mysql⽇志，未见任何异常⽇志，当时操作系统操作⾮常流畅，完全不卡顿，就没想到查看服务器负载，于是未发现问题，进⾏再次同步数据，现象依然存在，重复检查⽹络、⽇志均正常，iftop查看流量，也能看见流量到达数据库服务器，但是就是应⽤报连接数据库超时，此时检查服务器负载，居然达到60 58 40，8c16g的服务器，负载居然跑到这么⾼，当时就惊呆了！于是ps -ef 查看果然是mysql占⽤的，此时只能查看mysql中的进程，查看⾼负载时运⾏的语句：show processlist，查看到有10+的⼀条语句在select状态，再⼀查，变成sending data状态，于是赶紧打开慢⽇志，⼀看果然是这条语句，查询时间多达6s，句⼦很复杂，只有让研发处理，要么优化语句，要么加索引，要么加缓存逻辑set global slow_query_log='ON';set global slow_query_log_file='/var/log/mysql/';set global long_query_time=1; #超过⼀秒就记录配置⽂件的慢⽇志配置[mysqld]slow_query_log = ONslow_query_log_file =

/var/log/mysql/g_query_time = 1