第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./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[4mpwd\e[m\e[1;37m]\e[m\e[1;36m\e[m\n\$’。這樣你就可以知道你當前的目錄，登錄的用戶名和主機信息了，示例提示符如下： [root@woqu-lsv-01 /home/mysql]# 你可以查看http://www./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條，對生產環境存有敬畏之心。 這應該是運維者進入行業首先需要具備的素質。但是我們還是需要把它拿出來強調一下。 有機會的話，你可以梳理一下：
這些都是你避免出現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./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的一些分區，生僻函數，沒有必要的話不要使用。 最后祝大家運維的運維工作一帆風順，多福多壽，不出故障。 |
|
|
