【正文】 ill，最后發(fā)現(xiàn)是內(nèi)存不夠用，導(dǎo)致OOM kill了mysqld進(jìn)程并且沒有swap分區(qū)，后臺(tái)監(jiān)控內(nèi)存是夠用的，最后升級(jí)物理內(nèi)存解決。大多人都有rmrf /data/mysql的經(jīng)歷，發(fā)現(xiàn)刪除之后，那種心情你可以想象一下，可是如果沒有備份，你急又有什么用，一般這種情況下，你就要冷靜想下最壞打算了，對(duì)于mysql來說，刪除了物理文件，一部分表還會(huì)存在內(nèi)存中，所以斷開業(yè)務(wù)，但是不要關(guān)閉mysql數(shù)據(jù)庫，這對(duì)恢復(fù)很有幫助，并使用dd復(fù)制硬盤，然后你再進(jìn)行恢復(fù)，當(dāng)然了大多時(shí)候你就只能找數(shù)據(jù)恢復(fù)公司了。調(diào)優(yōu)框架以及先后熟悉了底層運(yùn)行機(jī)制，就要有調(diào)優(yōu)的框架和先后順序，比如數(shù)據(jù)庫出現(xiàn)瓶頸，好多人直接就去更改數(shù)據(jù)庫的配置文件，我的建議是，先根據(jù)瓶頸去分析，查看日志，寫出來調(diào)優(yōu)方向，然后再入手，并且數(shù)據(jù)庫服務(wù)器調(diào)優(yōu)應(yīng)該是最后一步，最先的應(yīng)該是硬件和操作系統(tǒng)，現(xiàn)在的數(shù)據(jù)庫服務(wù)器都是在各種測(cè)試之后才會(huì)發(fā)布的 適用于所有操作系統(tǒng)，不應(yīng)該先從他入手。有人說過，一個(gè)公司在安全投入的成本跟他被安全攻擊損失的成本成正比，安全是一個(gè)很大的話題，也是一個(gè)很基礎(chǔ)的工作，把基礎(chǔ)做好了，就能相當(dāng)?shù)奶岣呦到y(tǒng)安全性，其他的就是安全高手做的了 / 8四、日常監(jiān)控系統(tǒng)運(yùn)行監(jiān)控好多人踏入運(yùn)維都是從監(jiān)控做起，大的公司一般都有專業(yè)24小時(shí)監(jiān)控運(yùn)維。防火墻防火墻生產(chǎn)環(huán)境一定要開，并且要遵循最小原則，drop所有，然后放行需要的服務(wù)端口。如果真需要?jiǎng)h除，一定要謹(jǐn)慎。通常我們運(yùn)維接到任務(wù)，都會(huì)進(jìn)行簡(jiǎn)單查看如果無法解決，就請(qǐng)求他人幫忙，可是當(dāng)問題焦頭爛額的時(shí)候，客服主管（懂點(diǎn)linux），網(wǎng)管，你上司一起調(diào)試一個(gè)服務(wù)器，當(dāng)你各種百度,各種對(duì)照，完了發(fā)現(xiàn)，你的服務(wù)器配置文件，跟上次你修改不一樣了，然后再改回來，然后再谷歌，興沖沖發(fā)現(xiàn)問題，解決了，別人卻告訴你，他也解決了，修改的是不同的參數(shù)……這個(gè)，我就真不知道哪個(gè)是問題真正的原因了，當(dāng)然這還是好的，問題解決了，皆大歡喜，可是你遇到過你剛修改的文件，測(cè)試無效，再去修改發(fā)現(xiàn)文件又被修改的時(shí)候呢？真的很惱火，切忌多人操作。第二個(gè)例子是關(guān)于文件同步的，大家都知道rsync同步很快，可是他刪除文件的速度大大超過了rmrf,在rsync中有一個(gè)命令是，以某目錄為準(zhǔn)同步某文件（如果第一個(gè)目錄是空的，那么結(jié)果可想而知），源目錄（有數(shù)據(jù)的）就會(huì)被刪除，當(dāng)初我就是因?yàn)檎`操作，以及缺乏測(cè)試，就目錄寫反了，關(guān)鍵是沒有備份……生產(chǎn)環(huán)境數(shù)據(jù)被刪了沒備份，大家自己想后果吧，其重要性不言而喻。你甚至有可能找到真正的故障源頭。 Varnish。查找訪問和錯(cuò)誤日志, 直接找 5xx 錯(cuò)誤, 再看看是否有 limit_zone 錯(cuò)誤。 是否有某個(gè)定時(shí)任務(wù)運(yùn)行過于頻繁? 是否有些用戶提交了隱藏的定時(shí)任務(wù)?在出現(xiàn)故障的時(shí)候，是否正好有某個(gè)備份任務(wù)在執(zhí)行？十三、應(yīng)用系統(tǒng)日志這里邊可分析的東西就多了, 不過恐怕你作為運(yùn)維人員是沒功夫去仔細(xì)研究它的。do crontablu $user。 SWAP交換的設(shè)置是什么？對(duì)于工作站來說swappinness 設(shè)為 60 就很好, 不過對(duì)于服務(wù)器就太糟了：你最好永遠(yuǎn)不要讓服務(wù)器做SWAP交換，不然對(duì)磁盤的讀寫會(huì)鎖死SWAP進(jìn)程。 你的中斷請(qǐng)求是否是均衡地分配給CPU處理，還是會(huì)有某個(gè)CPU的核因?yàn)榇罅康木W(wǎng)絡(luò)中斷請(qǐng)求或者RAID請(qǐng)求而過載了？ 檢查磁盤使用量：服務(wù)器硬盤是否已滿? 是否開啟了swap交換模式(si/so)?CPU被誰占用：系統(tǒng)進(jìn)程? 用戶進(jìn)程? 虛擬機(jī)?dstat 是我的最愛。 六、CPU 和內(nèi)存$ freem$ uptime$ top$ htop 注意以下問題:在netstat顯示的服務(wù)列表中的PID 和 ps aux 進(jìn)程列表中的是一樣的。netstatnalp倒也可以。對(duì)要不然光看到一堆不知道啥時(shí)候執(zhí)行的命令，同樣會(huì)令人抓狂的。（ne cook in the kitchen is enough.）三、之前發(fā)生了什么? $ history查看一下之前服務(wù)器上執(zhí)行過的命令。只能再繼續(xù)摸索了。 我們基本上都會(huì)從以下步驟入手：一、盡可能搞清楚問題的前因后果不要一下子就扎到服務(wù)器前面，你需要先搞明白對(duì)這臺(tái)服務(wù)器有多少已知的情況，還有故障的具體情況。當(dāng)出現(xiàn)此類問題時(shí)，應(yīng)該如何處理？本文給大家詳盡的分析了一下，一起來看看。10g設(shè)置好命令提示當(dāng)然、你也可以在 里面設(shè)置對(duì)于 Linux 而言、bash 環(huán)境的提醒可設(shè)置 PS1 來知道當(dāng)前目錄、登陸用戶名和主機(jī)信息等對(duì) PS1 更多理解、請(qǐng)見：man PS1㈣ 備份并驗(yàn)證備份的有效性人非圣賢、豈能無過？是機(jī)器總有計(jì)劃內(nèi)或計(jì)劃外崩潰的一天怎么辦？備份??！備份的學(xué)問很大、按照不同的維度可以分：冷備和熱備；實(shí)時(shí)和非實(shí)時(shí)；物理和邏輯OLTP 7*24 在線業(yè)務(wù)、DB 就需要有實(shí)時(shí)熱備這樣就可以了嗎？如果開發(fā)人員的一個(gè)不帶任何條件的 delete 誤刪所有數(shù)據(jù)所以、此時(shí)你除了實(shí)時(shí)、還需要有非實(shí)時(shí)的備份、把 DB 從邏輯錯(cuò)誤中恢復(fù)出來備份有了、可以高忱無憂了嗎？不行！尚須驗(yàn)證備份的有效性一個(gè)總有那么幾次、備份無法保證 100% 恢復(fù)簡(jiǎn)單的驗(yàn)證就是找個(gè)空庫、恢復(fù)出來㈤ 對(duì)生產(chǎn)環(huán)境永保敬畏之心會(huì)計(jì)人員在從業(yè)之前、都有個(gè)職業(yè)操守的訓(xùn)練同理、這也應(yīng)該是運(yùn)維人員進(jìn)入行業(yè)首先需要具備的素養(yǎng)比如：于 Oracle 而言、你可以跑一個(gè) RDA 巡檢 DB 的健康狀況于 Linux 而言、是否有 password aging、隔離外網(wǎng)等㈥ 交接和休假最容易出故障、變更請(qǐng)謹(jǐn)慎接手別人的工作要一而再，再而三的確認(rèn)變更方案。alias mv=39。第一篇：逃離故障的十條運(yùn)維工作經(jīng)驗(yàn)總結(jié)逃離故障的十條運(yùn)維工作經(jīng)驗(yàn)總結(jié)故障、于 DBA、于 運(yùn)維人員 都是 心中永遠(yuǎn)的痛、而避免故障的原則卻是殊途同歸現(xiàn)列如下、與君共勉㈠佛說：每次創(chuàng)傷、都是一次成熟、這便是運(yùn)維人員的真實(shí)寫照從某種意義上講、運(yùn)維是一門經(jīng)驗(yàn)的學(xué)科、是一門試錯(cuò)的學(xué)科沒有做過的東西、總是會(huì)給你不期而遇的痛擊請(qǐng)保護(hù)現(xiàn)場(chǎng)、讓 變更 有回頭的機(jī)會(huì)㈡ 對(duì)破壞性的操作謹(jǐn)慎小心什么是破壞性的操作哩？比如：對(duì) Oracle 而言：truncate table_name、delete table_name、drop table_name這些語句執(zhí)行起來輕松簡(jiǎn)單也愜意極了、但記?。〖幢銛?shù)據(jù)可被回滾、代價(jià)也是非常大！對(duì) Linux 而言：rmr 所有當(dāng)前及其子目錄的所有數(shù)據(jù)都將被變更要能回滾、先在同樣的環(huán)境測(cè)試過刪除經(jīng)歷過這種故障的人、大多會(huì)給 rm 上個(gè)別名alias rm=39。cpi39。RACnode1primary10g39。但是如果想要在生產(chǎn)環(huán)境下使用起來、請(qǐng)三思！能夠使用系統(tǒng)內(nèi)置命令的話，就不用考慮其他要專門下載安裝的軟件了腳本本身就能完成的功能，就沒有必要專門找一個(gè)功能豐富的軟件來做linux本身自帶的字符界面比那些復(fù)雜的圖形界面要簡(jiǎn)潔方便............第二篇：linux服務(wù)器故障之運(yùn)維經(jīng)驗(yàn)總結(jié)服務(wù)器故障之運(yùn)維經(jīng)驗(yàn)總結(jié)作為一個(gè)運(yùn)維人員，遇到服務(wù)器故障是在所難免的，要是再趕上修復(fù)時(shí)間緊、奇葩的技術(shù)平臺(tái)、缺少信息和文檔，基本上這過程都會(huì)慘痛到讓我們留下深刻的記憶。遇到服務(wù)器故障，問題出現(xiàn)的原因很少可以一下就想到。 故障的表現(xiàn)是什么？無響應(yīng)？報(bào)錯(cuò)？ 故障是什么時(shí)候發(fā)現(xiàn)的？ 故障是否可重現(xiàn)？有沒有出現(xiàn)的規(guī)律（比如每小時(shí)出現(xiàn)一次）最后一次對(duì)整個(gè)平臺(tái)進(jìn)行更新的內(nèi)容是什么（代碼、服務(wù)器等）？故障影響的特定用戶群是什么樣的(已登錄的, 退出的, 某個(gè)地域的…)? 基礎(chǔ)架構(gòu)（物理的、邏輯的）的文檔是否能找到?是否有監(jiān)控平臺(tái)可用?（比如Munin、Zabbix、Nagios、New Relic… 什么都可以）是否有日志可以查看?.（比如Loggly、Airbrake、Graylog…）最后兩個(gè)是最方便的信息來源，不過別抱太大希望，基本上它們都不會(huì)有。有道是一山不容二虎嘛。到這里先提醒