遠離故障的十大原則

文章來源:http://hatemysql.com/2012/11/24/%E8%BF%9C%E7%A6%BB%E6%95%85%E9%9A%9C%E7%9A%84%E5%8D%81%E5%A4%A7%E5%8E%9F%E5%88%99/

故障是運維人員永遠的痛。相信每個運維人員的KPI中都有一項：可用性。可用性高就是不出故障，各個公司對可用性和故障評級的標準都不相同，可是避免故障的方法倒是異曲同工。咱們怎麼避免故障，沃趣科技簡單列舉了如下幾條，與你們共勉！
一、變動要有回滾，在一樣的環境測試過
二、對破壞性的操做謹慎當心
三、設置好命令提示 
四、備份並驗證備份有效性
五、對生產環境存有敬畏之心
六、交接和休假最容易出故障，變動請謹慎
七、搭建報警，及時得到出錯信息。搭建性能監控，瞭解歷史，得到趨勢，預測將來
八、自動切換需謹慎
九、仔細一點，偏執一點，檢查，檢查，再檢查
十、簡單便是美。

 

第1條，變動要有回滾，在一樣的環境測試過。也是運維最繁瑣，最苦逼的地方，全部的變動都必須有回滾的辦法，在一樣的環境下測試過。沒有作過的東西，老是會在你意想不到的地方給你一次痛擊，在阿里巴巴的這麼多年運維經驗告訴咱們，全部沒有作過的變動，出錯的機率最大。因此咱們須要給變動以回滾的可能，在各個步驟可能出錯的狀況下，考慮回滾到最初狀態。優秀的運維人員對不考慮回滾的的操做都是敬而遠之的。從某種意義上來講，運維是一門經驗的學科，是一門試錯的學科。

 

第2條，對破壞性的操做謹慎當心。破壞性的操做有哪些列？對數據庫來講有：DROP Table， Drop database， truncate table， delete all data；這些操做作完了之後幾乎沒法考慮怎麼把數據都回滾回去了。就算回滾，代價也是很是大的。你執行這樣的語句很是簡單，可是回滾恢復數據缺很是困難。linux的命令rm能夠-r(recursive)遞歸的刪除某一個目錄，-f(force)強制刪除，可是你有沒有刪錯過文件。咱們遇到過一個文件名中末尾有空格的狀況，而有的同事rm -r習慣性的會在文件名後面加＊，這樣就成了rm -r aa *，全部當前目錄的數據都被刪除掉了！通過此次故障之後咱們給rm作了別名：
alias rm=’rm -i’
這樣在刪除數據時，rm命令會提示你，是否確認刪除該文件。
一樣的cp和mv也能夠有一樣的選項：
alias cp=’cp -i’
alias mv=’mv -i’

 

第3條，設置好命令提示。讓你時刻知道你在操做哪一個數據庫，讓你知道你在哪一個目錄下。mysql字符客戶端容許你設置提示符，默認的提示符就是一個光禿禿的mysql >，爲了讓你清楚的知道你當前是以哪一個用戶名，哪一個IP（多是localhost，127.0.0.1或者具體的物理IP），你當前操做的是哪一個schema，以及當前的時間，你能夠設置數據庫的提示符爲：prompt=」\\u@\\h : \\d \\r:\\m:\\s> 「。它能夠直接寫在my.cnf的[mysql]下，這樣你每次連上MySQL就默認顯示以下：
root@127.0.0.1 : woqutech 08:24:36>
具體prompt能夠設置哪些提示，你能夠參考http://dev.mysql.com/doc/refman/5.6/en/mysql-commands.html中的列表
而linux命令提示符也容許你設置的。有兩個地方能夠設置。第一個：PS1。這個是每次shell提示你輸入命令的信息，默認爲：$或者#，只會提示你是超級用戶仍是普通用戶。有經驗的運維者會設置export PS1=’\n\e[1;37m[\e[m\e[1;31m\u\e[m\e[1;31m@\e[m\e[1;31m\h\e[m \e[4m`pwd`\e[m\e[1;37m]\e[m\e[1;36m\e[m\n\$'。這樣你就能夠知道你當前的目錄，登陸的用戶名和主機信息了，示例提示符以下：
[root@woqu-lsv-01 /home/mysql]
#
你能夠查看http://www.cyberciti.biz/tips/howto-linux-unix-bash-shell-setup-prompt.html得到具體的PS1設置顏色，設置各個提示內容的介紹。
第二個提示符就是PROMPT_COMMAND。這個是設置你連到具體的數據庫之後標籤頁標題上顯示的內容，Windows用戶可能會用securtCRT，Mac用戶可能會用iTerm2，開多個標籤頁的話，若是每一個標籤頁的標題上內容同樣，咱們切來切去就有可能在錯誤的標籤頁上作操做，設置了這個之後，這個問題機率就會小不少。好比咱們的機器上設置爲PROMPT_COMMAND=’echo -ne 「\033]0;${USER}@${HOSTNAME%%.*}」; echo -ne 「\007″‘對應的標籤頁以下圖

 

 

 

 

第4條，備份並驗證備份有效性。是人總會出錯，是機器總可能會有忽然崩潰的那一天。怎麼辦－咱們須要準備備份。

備份的學問很大。按照不一樣的緯度能夠分爲：冷備份和熱備份；實時備份和非實時備份；物理備份和邏輯備份。

互聯網企業爲了提供7*24小時不間斷的服務，數據庫就須要有實時熱備份。在主庫出現問題的狀況下可以由備庫提供服務。備庫時候有效，數據是否一致，主庫出現問題的時候怎麼切換都須要運維人員認真考慮。

是否是有了這些就夠了列？不行，應用程序也是人寫的，曾經出現過程序一不當心delete語句沒有帶任何條件，致使一個表中全部的數據都被刪除的慘狀。因此你除了實時的備份，還須要有非實時的備份，在你的數據出現邏輯錯誤以後可以從備份數據中恢復出來。如今不少人在研究MySQL模仿oracle的flashback功能，利用binlog來恢復數據。可是這樣的話，binlog_format必須設置爲row而且對於DDL操做也沒法回滾。它是爲快速解決部分數據被錯誤刪除的解決方案，可是沒法代替非實時備份的做用。

非實時備份有能夠分爲在線延時備份和離線備份。在線延時備份是搭建數據庫的必定時間延遲的熱備份，好比MySQL就能夠搭建一個延遲一天的slave，一直保持着備庫與主庫的延遲在一天。能夠利用pt-slave-delay工具來實現這個功能。另外，離線備份是目前你們用的比較多的，能夠利用mysqldump進行邏輯備份或者xtrabackup進行物理備份。爲了空間的緣由和快速恢復考慮，你還能夠利用xtrabackup進行增量的物理備份。

備份有了，是否就能夠高枕無憂了？仍是不行。你須要驗證備份的有效性。沒有一個備份可以保證它備份出來的數據可以100%恢復出正確的數據，特別是物理備份的機率相對來講，更低，xtrabackup備份一個月總有那麼幾回來大姨媽，不能給你很好的服務。因此，備份並不僅是備份，它還包括備份的驗證，它若是不能恢復出正確的數據，就只是浪費空間而已。備份的驗證最簡單的就是找一個空閒的庫，來恢復出來，mysql啓動之後檢查部分數據。若是不須要這麼嚴謹，對於xtrabackup來講，你至少得驗證它–apply-log可以恢復上去吧？一樣，備庫的數據一致性也須要常常檢查一下，mysql的replication並不保證100%的數據一致性，你能夠去翻翻mysql statement複製的bug列表，有些數據在主備不一樣的環境上分別執行，數據就會不同。能夠考慮用percona的工具pt-table-checksum來檢查主備不一致，用pt-table-sync來同步主備數據。

 

 

第5條，對生產環境存有敬畏之心。這應該是運維者進入行業首先須要具有的素質。可是咱們仍是須要把它拿出來強調一下。

有機會的話，你能夠梳理一下：

• 你的生產環境上有哪些帳戶，這些帳戶是否都確實須要登陸到機器上來？這些帳戶即包括linux用戶還包括數據庫帳戶。
• 你的root用戶是否開放給了某些用戶，這些用戶安全嗎？
• 你的用戶密碼是否常常修改，是否加密不讓具體的操做人員直接看到，密碼強度時候足夠，密碼重試次數達到必定次數是否黑名單；
• 你的生產環境和線下環境是否隔離，數據庫是否和外網隔離？
• 是否一些工做明明可以在開發庫和測試庫作，卻被放到生產環境上去了。
• 是否有專門的人負責線上應用的發佈，從而避免開發人員直接接觸生產環境

這些都是你避免出現csdn密碼泄漏，在業界的名聲一落千丈的法寶。

 

 

第6條，交接和休假最容易出故障，變動請謹慎。這個是經驗之談。咱們在總結故障的狀況時，發如今公司部門有變化時，工做交接(無論是休假，工做職責變化仍是離職)，故障的出現頻率會比正常狀況下多50%以上。有人說，這是由於機器或者應用是有感情的，捨不得離開的運維者。

咱們不談感情，簡單的理性分析一下。公司或者部門不免會作一些調整，變化是世界上惟一不變的事情。而運維人員是一線作事情的人，部門調整或者領導的更換可能致使工做的着重點不一樣，作事的方式和評測的標準變了，適應過程當中不免會出現一些考慮不周到的地方，出故障也是情理之中了。

而工做交接，對運維人來講，實際上是一個很是費時費力的事情，你須要把全部日常作的工做都梳理清楚，甚至包括你的一些經意不經意的操做習慣，這樣的話，下一我的纔可能接手的下來。好比：你可能認爲備庫正常狀況下沒有訪問，因而讓某些並不重要的任務(一個月一次抽取部分數據到線下測試？)直接連備機IP進行操做。下一我的接手，認爲備機就是備機，操做起來不會有任何問題，結果下一次任務抽取就是一個故障出來了。再舉一個咱們遇到了事例吧：同事A出國休假了，休假期間估計聯繫不上，他留了文檔，並告誡說某幾個庫和表是比較核心和容易出問題的，沒有特殊狀況最好等他回來再作變動。正好，休假期間，開發人員找到同事B，要求他重置一個字段的某一位（bit），並打包票說這個bit沒有用，同事B拒絕，並背上了不配合的罵名。同事A回來嚇了一身冷汗，原來這個字段已經被另一個離職的開發使用了。

因此，運維部門和運維人員對變化須要儘可能放平心態；接手別人的工做要一而再，再而三的確認變動方案。請教人並不見得就是能力不行的表現；休假前最好各類能夠作好的事情，最好可以準備一份文檔，指明在什麼狀況下怎麼作和聯繫哪些人。在別人放假的時候接手工做，「能拖則拖」，實在須要執行：必須不厭其煩的跟原運維者確認各個操做細節。 

 

 

第7條，搭建報警，及時得到出錯信息。搭建性能監控，瞭解歷史，得到趨勢，預測將來。運維的最高境界不是故障來了，泰山崩於前而不驚，蒼老師勾引你而抗日；而是沒有故障，讓故障消失在萌芽之中。請給那些默默無聞，天天想着咱們的系統還存在哪些隱患，怎麼解決，怎麼及早發現的運維人員鼓掌。他們是最可愛的人。而他們賴以生存的工具就是報警和監控。Oracle發展了這麼多年，awr和相關的性能參數都相對比較全；MySQL如今也已經迎頭遇上，配套的工具愈來愈多。

報警可讓你及時知道系統出現了什麼異常。好比slave io報警，在數據庫replication異常的時候就會提醒你：IO線程出現了問題，多是網絡問題，主數據庫問題等，slave sql報警會提醒你replication的SQL線程出現了問題，多是主備不一致，slave被停掉了，存儲過程在備機有異常或者其餘問題。這樣你收到報警就能夠及時跟進，而不至於主備長時間不一致，主庫壞掉了想要切換到備庫的時候卻不能切換。

性能監控可讓你瞭解系統的歷史性能信息。分析故障發生時的各類現象，確認故障的真正緣由；瞭解變化趨勢，發現故障的苗頭，及早優化和調整。好比你若是使用了PCI-E的Flash卡，你能夠監控logical_written_bytes，logical_read_bytes，physical_written_bytes，physical_read_bytes以便得到flash卡的每秒的邏輯讀寫和物理讀寫字節數。對於MySQL你能夠監控Com_delete+Com_delete_multi, Com_insert+Com_insert_select，Com_update+Com_update_multi，Com_select來得到每秒的MySQL DML刪除，插入，更新和查詢的次數。

報警和性能監控其實不不徹底獨立的，不少性能的監控項也能夠報警出來。好比linux的iostat中的await_time能夠做爲性能監控採集起來得到系統IO響應時間的變化曲線，當該值達到20以上的時候，也能夠報警出來，讓運維人員跟進是磁盤陣列中壞了一塊，仍是異常的數據拷貝影響了系統的IO性能等。

nagios和cacti是目前MySQL領域使用最普遍的報警和性能展現系統。percona最新推出percona-monitor-plugins( http://www.percona.com/software/percona-monitoring-plugins)就是基於他們倆的。

 

 

第8條：自動切換需謹慎。如今數據庫的HA不少都是進行自動切換的，這樣運維人員深夜起來手工切換到備庫的機會就會少不少。切換也會快速不少。可是，它帶來的反作用也不容忽視。

如今業界使用的HA軟件很是多，heartbeat因爲不少SA兼做DBA的運維比較熟悉，在MySQL自動切換也是很多的。通常來講，它會經過mysqladmin ping來探測MySQL是否存活，若是發現異常，那麼他就會切換VIP和MySQL資源到備庫。可是此時備庫的數據延遲是否爲0，主庫crash以後binlog的數據是否所有都同步到備庫上去了，備庫的read_only是否關閉，這些heartbeat都無論。咱們想象一下，主庫上應用提交了一筆訂單，結果發生了切換，這筆訂單沒有同步到備庫上，賣家也就損失了一個銷售單，對客戶，對公司都是很是大的影響。

固然，自動切換也不能全盤否認，它可以更快速的將應用切換到新的熱備份備庫上，應用的不可用時間大大縮短。只是咱們要好好利用這一把雙刃劍，仔細評估它的影響，下降或者去除反作用，讓它爲咱們服務。

 

 

第9條，仔細一點，偏執一點，檢查，檢查，再檢查。以前我跟一個資深的運維學習線上操做的時候，以爲這傢伙有點變態，他在作一個變動的時候，會先提早一兩週發送郵件並電話手機的通知相關人；在測試機上寫好腳本，召集你們review操做步驟和腳本；測試完成之後拷貝到生產環境；登陸對應機器，「打開，關閉，打開，關閉」該腳本；跟相關人員再次確認執行的操做，順序，時間點，可能的影響和回滾是否都準備好了；執行前還要退出這個機器，而後再登陸進去，「打開，關閉」腳本；最後纔在後臺運行腳本，在另一個窗口登陸着，隨時ps和查看結果輸出。期間姿式端正，呼吸急促而均勻，眼神凝重。操做的人不以爲累，卻是一邊學習的人很累。

當我作到必定程度，我也開始這樣了。醫學上，這種好像叫作強迫症。唉…，提早通知會讓你們都有準備，也避免了臨時相關人員過來講這個操做和其餘操做有依賴須要調整操做時間的問題； 召集你們review步驟和腳本是爲了讓你們一塊兒來看看整個過程當中還有哪些依賴沒有考慮到或者哪些細節沒有注意到，三個臭皮匠頂一個諸葛亮在運維來講是金科玉律；「打開，關閉，打開，關閉」是爲了一再確認腳本拷貝過來是否正確，目錄時候正確，思考在測試環境運行和在生產環境運行有什麼不同的；退出再登陸機器是爲了確認我登陸的機器確實沒有錯；在後臺運行是擔憂網絡忽然中斷，個人腳本運行到一半怎麼辦；調整呼吸和端正姿式是爲了對這個操做的敬重，對本身工做和運維工做的尊重。

以MySQL 使用flash卡爲例吧。flash算是一個比較新的事務，提供的IO比普通磁盤是幾個數量級的提高。要想在生產環境使用，首先咱們須要對他進行詳盡的評估和破壞性測試，設置各類參數，考慮他們在各類場景下使用的配置；24小時不間斷的進行半個月讀寫操做，中途忽然掉電；高併發，高吞吐量下的測試；溫度溼度極限測試；預留空間釋放測試等等。而後咱們會嘗試在測試庫上部署試用，收集和修改各個配置已達到最穩定，最高性能的配置；運行穩定之後咱們才考慮在線上備庫使用，而且主備要求異構；適當的時機切換爲使用新的flahs卡爲主庫，萬一出現了問題，還能夠切換回原主機。

這裏也跟你們簡單介紹一下screen命令，這個命令會在服務器段開啓一個session，就算你的網絡斷掉了，你的腳本也會自動在後臺運行。screen -S woqutech能夠開啓一個woqutech命令的後臺session；若是你的網絡斷掉了，你能夠用screen -dr woqutech連上以前的session繼續進行操做。IBM的文檔庫中有一個很是靠譜的文檔： http://www.ibm.com/developerworks/cn/linux/l-cn-screen/。

 

第10條，簡單便是美。最後一條有點禪的意境了。它和Unix的思想不謀而合。咱們老是面臨着各類誘惑：新的系統架構，新的更智能的命令和工具，最新的硬件平臺，功能更全的HA軟件等。他們老是以各類各樣的方式吸引咱們，most exciting，unbelievable，讓你欲罷不能。你能夠在線下安裝，測試，怎麼搞都行。可是若是想要在生產環境下使用起來，那就得通過很是詳細，很是漫長，各類方式驗證其穩定性的過程。

可以使用系統內置命令的話，就不用考慮其餘要專門下載安裝的軟件了；腳本自己就能完成的功能，就沒有必要專門找一個功能豐富的軟件來作；linux自己自帶的字符界面比那些複雜的圖形界面要簡潔方便；MySQL的一些分區，生僻函數，沒有必要的話不要使用。