剛入職公司接觸到的第一個項目，應用架構比較簡單和無理
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/slow.log';
set global long_query_time=1; #超過一秒就記錄配置文件的慢日志配置
-
[mysqld]
-
slow_query_log = ON
-
slow_query_log_file =
/var/log/mysql/slow.log -
long_query_time = 1