本文希望表達(dá)的是：在遇到問題的時候羹令，要有明確的思路和數(shù)據(jù)。不要隨便猜损痰。很多人在看到這問題的時候福侈，就會問是不是redis雪崩了，是不是連接數(shù)過多了卢未，這個是最low的肪凛。一般能直接定位的問題就不是問題了。
開發(fā)者是要學(xué)會思考的辽社。遇到問題不要拍頭猜問題伟墙。要有解決的思路。該問題的的答案是我個人的滴铅。每個人如果有興趣可以想想戳葵，從這道題出發(fā)，自己的思路是什么汉匙。
提出有用的問題拱烁，獲得想要的答案，一步一步定位問題盹兢。
場景
問題是：我們的一個數(shù)據(jù)庫進(jìn)程掛了邻梆，你來定位一下問題在哪里？ 你可以提出各種你認(rèn)為有價值的問題绎秒，我給你各種數(shù)據(jù)反饋浦妄，直到你定位到問題在哪里。
總體的指導(dǎo)思想
出問題的時候，一般都會有一些指標(biāo)會有異常
解決問題的前提
你對正常情況下的指標(biāo)和業(yè)務(wù)的架構(gòu)都比較清楚剂娄，不清楚的前提先弄清楚蠢涝，或者有之前的指標(biāo)可以對比，而且不僅僅停留在數(shù)據(jù)庫本身
剩下的其他的阅懦，都是解決方法的問題和二，至于哪個方法好用，主要根據(jù)實際業(yè)務(wù)場景的一些情況耳胎，
先用最簡單的方法定位問題的范圍惯吕，然后逐步找到問題并解決問題
我的思路
提出每個問題，并提出自己想要得到的數(shù)據(jù)
- 這個數(shù)據(jù)庫是什么業(yè)務(wù)在用的怕午？
【希望】：了解業(yè)務(wù)場景废登，看是否有訪問峰值，初步了解該業(yè)務(wù)特點郁惜。
- 數(shù)據(jù)庫掛掉的大概時間
【希望】：和第一個問題相呼應(yīng)堡距，看是否能得出什么提示。如高峰時數(shù)據(jù)庫掛掉兆蕉。
- 是否有主從和讀寫分離
【希望】：了解數(shù)據(jù)庫是否有主從結(jié)構(gòu)羽戒，幾主幾從。是否有做讀寫分離
- 若有3虎韵，是主庫掛掉還是從庫掛掉
【希望】：則從主庫掛掉或者從庫掛掉可以大概知道是讀還是寫導(dǎo)致的數(shù)據(jù)庫掛掉（注意這里不能確定判斷易稠，只是有個大概方向）。
- 系統(tǒng)的結(jié)構(gòu)（數(shù)據(jù)庫在系統(tǒng)中所處的位置和作用）
【希望】：代碼的邏輯層都是直連數(shù)據(jù)庫劝术，還是中間有緩存層（全部 or 局部）缩多。
- 系統(tǒng)監(jiān)控數(shù)據(jù)是否有異常
【希望】：
mysql監(jiān)控信息呆奕，連接數(shù)养晋，慢查詢，讀寫比例等梁钾，sql執(zhí)行的qps等绳泉。
cpu負(fù)載，內(nèi)存使用姆泻，硬盤容量零酪。看是否有異常拇勃，可能導(dǎo)致數(shù)據(jù)庫進(jìn)程掛掉四苇。
緩存機(jī)器or集群的健康狀況： 若緩存層有狀況，看是否是存在雪崩的情況（若是雪崩方咆，mysql的監(jiān)控信息月腋，應(yīng)該會給出警報）
- 日志排查
【希望】： 通過查看mysql錯誤日志，二進(jìn)制日志或系統(tǒng)錯誤日志等日志，希望可以得到進(jìn)程掛掉的時間段是否有相應(yīng)的錯誤提示信息榆骚。
- 是否有人主動殺掉
【希望】： 在上面的過程中片拍，一般能從技術(shù)上定位到問題了。這一步可以從非技術(shù)的角度分析妓肢“剖。看是否是有管理員或者某個腳本或進(jìn)程誤停掉進(jìn)程。更甚碉钠，看一下機(jī)器是否被入侵纲缓。被惡意殺掉進(jìn)程。
后續(xù)
上面的過程是基于前面條件不成立的情況下的排查思路喊废。在排查期間色徘，會有很多分支的情況。
- 比如：在業(yè)務(wù)高峰訪問的點掛掉操禀？
則就需要判斷為什么這個點會掛掉褂策。是代碼發(fā)布原因，還是系統(tǒng)的突發(fā)狀況颓屑。
- 比如： 已經(jīng)知道連接數(shù)過多導(dǎo)致的進(jìn)程掛掉斤寂？
則就需要排查為什么連接數(shù)過多，是業(yè)務(wù)上的原因（如上線活動）揪惦，還是sql執(zhí)行的原因（慢查詢導(dǎo)致連接關(guān)閉不了）等等
- 比如：cpu負(fù)載過高遍搞？
為什么cpu的負(fù)載過高？是其他服務(wù)占用了cpu器腋，還是mysql本身的占用了cpu（為什么占用了cpu）
等等溪猿，等等
問題的排查，在不是很明確的情況下纫塌，每一個猜測應(yīng)該是有依據(jù)的诊县。
