記一次伺服器宕機災難
時間日期專案背景
某日下午六點多，業務中斷，伺服器無法連線，聯絡伺服器託管方重啟機器，但半個多小時後被告知系統故障，重啟失敗。然後就一直在催他們處理，確保資料不丟失的前提下儘快恢復機器。但是效率極低，溝通也非常困難，對接的市場和售後工程師剛開始都不給現在工程師的聯絡方式，導致目標不一致，浪費了很多時間。
宕機3個多小時，10點左右他們才給出方案，用新硬碟裝新系統，將老硬碟作為資料盤掛載上去。結果裝機又花了2個多小時，恢復連結時已經12點了，整整宕機接近6個小時。由於我們業務已經正式上線，導致損失巨量流量，造成了極大損失。
恢復業務
伺服器恢復後，接下來恢復業務，主要要重新安裝業務環境，從掛載的老硬碟中，將mysql資料庫恢復。
遇到和解決的問題
-
linux安裝多個硬碟後，如何掛載，如何將B硬碟資料拷貝進A硬碟
Linux檢視與掛載新磁碟 -
mysql 啟動問題，啟動報mysql.pluge的錯誤
Linux下MySQL報錯:Can't open the mysql.plugin table -
mysql 資料恢復
進入舊磁碟mysql的資料存放路徑，yum預設安裝的話在/xxx/var/lib/mysql/,將要恢復的表的資料夾拷貝到當前系統下/var/lib/mysql，確保mysql有讀寫許可權，重啟mysql服務 -
php-fpm遇到的奇怪許可權問題，以service php-fpm start 啟動後無論如何都沒讀寫許可權(apache使用者的許可權已分配)，並且無法連線到資料庫，直接以php-fpm啟動就可以，ps -ef檢視程序所屬使用者，兩種都是Apache。在其他機器中，service和直接啟動就都沒問題。主要不以service啟動的話，要重啟或殺死php-fpm就比較麻煩，一共有120多個程序，批量殺死可以用此命令:
ps -ef | grep php-fpm | grep -v grep | cut -c 9-15 | xargs kill -s 9 ;
總結
恢復系統後，查看了老系統盤裡的系統日誌/var/log/messages
,發現了cpu過熱的告警，當時cpu消耗大致在60%左右，那臺機器的cpu過熱溫度是84，機房是風冷散熱，所以確實可能是這個原因導致的宕機，系統崩潰無法重啟的問題，就不好確定了，伺服器商的工程師上去定位後也懷疑是自己的機器有硬體問題。
至於cpu消耗如此大，溫度過高的原因，除了我們業務本身就需要處理大量請求，nginx負載嚴重外，後面通過分析接入日誌，發現也存在大量不合法的高頻攻擊性請求，導致負荷超過實際。我們當前是8核16g，估計後面得升cpu數了。另外還發現，那臺機器的nginx負荷非常不均勻，8個nginx程序，有的60%的負荷，有的只有20%，這個跟系統
之後緊急開發了讀取接入日誌，分析高頻非法請求，利用iptable+ipset批量拉黑ip的程式，每30s處理一次，才降低了一些nginx負荷，目前每天能拉黑3w個左右的疑似有問題ip。用sensor監控系統溫度，目前的週末晚高峰峰值在75度以內，還算健康。