MySQL數據庫運維的五大指標

如何評價一個公司數據庫運維水平的高低？用什麼來進行橫向與縱向對比？自動化平臺建設的目標是什麼？必須有相應的指標體系來指導，此指標體系必須知足如下條件： 
• 能夠用數字來測算和衡量 
• 最終指標，而不是中間指標 
好比有時DBA會關注數據庫的吞吐量，但吞吐量越高不能表明數據庫提供的服務質量越好，開發人員關心這個指標的緣由也是由於擔憂太高的吞吐量會影響響應時間或者形成系統不可用，因此這只是一箇中間指標。 
• 能夠全面衡量一個網站的數據庫運維水平，而不會顧此失彼 
• 有人文關注

1.1. 數據安全 
數據安全是第一位的，DBA的首要職責必須保證不丟數據，丟掉數據就丟掉了飯碗！ 
這有3方面的含義： 
1）在人爲誤操做的時候（update,insert,delete,drop,alter)，可以恢復數據到正確的狀態
2）在機房，硬件故障或者操做系統，數據庫軟件故障的時候，可以恢復數據到正確的狀態 
3）不丟事務，保證已經入庫的數據可以被正確的查詢到 
另外，還要注意到須要保證主從數據庫的一致性，不然讀寫分離的狀況下其實在用戶看來仍然丟失了數據。 
對於1，主要靠備份來保證，由於複製能夠容災，卻不能夠容錯（固然延遲備份在必定程度能夠）。 
對於2，可能用備份來恢復，也可能直接進行主庫或者從庫的切換來恢復服務 
對於3，電商，支付庫的要求會很是高，採用最高安全級別的數據庫軟硬件設置以及冗餘設備，目標是不丟任何1個事務，由於即便1個事務也可能形成大量金錢的損失，同時形成企業信譽的降低。 
「911」事件曾形成1200家公司受災，其中一半以上的企業由於IT數據損毀、丟失，致使業務沒法恢復，以至於宣佈倒閉。金融界巨頭Morgan Stanley 全球營業部次日就恢復正常工做，正是由於先前創建的遠程容災系統保護了重要的數據。 
可測量指標： 
RPO（Recovery Point Object）：恢復點指標，是指災難發生後，容災系統能把數據恢復到災難發生前的哪個時間點的數據，它衡量企業在災難發生後會丟失多少生產數據 
RTO（Recovery Time Object）：系統恢復的時間 
RPO說明了備份的可靠性和完整性，RTO說明了恢復的可靠性與速度。 
因爲MySQL開源版本並不提供熱備的工具以及備份管理的工具（ＭSSQL，Oracle是提供的，固然它們是商業軟件），因此要求ＤBA開發出本身的備份還原管理平臺（腳本）。這也是DBA的首件工做。

1.2. 無端障（停機）時間 
運維和開發不同，開發最重要的是保證必定效率的狀況下實現功能，同時程序Bug少。運維講的是提供穩定服務的時間。用術語來講就是幾個9，具體含義就是年度不可服務（不論是主動的仍是被動的）時間除以整年時間，百分比越高越好。具體和時間的換算關係見下表： 

根據墨菲定理（If anything can go wrong,it will）的推論，世界上沒有 100% 可靠的 Web站點(除非不運行)。運維的最高境界固然就是5個9了，一年停機時間只有5分鐘，這是至關難以達到的目標，每每一個大故障就會把整年的停機時間用完。 
業界網站的可用性都是多少？引人注目的 Web 新貴 Twitter (http://twitter.com)， 2008 年前四個月的可用性只有 98.72%，有 37小時 16分鐘不能提供服務，連2個9 都達不到，甚至還沒達到」基本可用」狀態。電子商務巨頭 eBay 2007 年的可用性是 99.94%，考慮到 eBay 站點的規模與應用的複雜程度，這是個很不錯可用性指標了。 
多數狀況下，網站可用性會是 SLA （Service Level Agreement, 服務水平協議) 中的一個重要度量指標，也是運維團隊向本身老闆作出的正式承諾。但可用性是可以持續改進的東西，運維負責人不可但願一步登天。 
另外，若是是作第三方託管，須要明確第三方的服務能力與責任。不然，IDC 常常斷電或者斷網，即便自身作的再好也沒法保證服務時間了。 
提升可用性的一些常規策略有消除單點，部署冗餘設備等。若是要提供更高的可用性，好比 4 個 9 甚至 5 個9，就不是簡單靠硬件就能作到的事情，還須要創建自動化的工具與平臺，完善的流程制度與變動機制，7*24小時的專人值班等。 
可測量指標： 
年度不可服務時間比例：年度不可服務（不論是主動的仍是被動的）時間除以整年時間。

1.3. 響應時間 
響應時間是指一條查詢或者更新語句從發出請求到接收完數據的時間。 
由於最大響應時間的不肯定性和不可重複性，因此通常使用X%的查詢響應時間做爲指標。若是值爲95%爲10ms，意味着95%的查詢會在10ms內返回。對於OLTP查詢來講，在50ms內返回是比較理想的結果。超過200ms的查詢能夠視爲慢查詢。 
此指標較難收集，採用tcprstat雖然能夠，可是tcprstat自己有必定的負載，另外也只收集最高到99%的響應時間，若是想知道好比99.999%的平均、最大響應時間就須要修改源碼了。 
目前有2個思路收集此數據： 
採用tcpdump+pt-query-digest，將tcpdump抽樣數據發送到中心機上利用pt-query-digest進行分析，而後入庫後顯示。此方法也須要修改pt源碼，由於原版的pt支持的粒度太粗了，以下圖，100ms直接跳到了1s：

此方法的優勢是能夠顯示不一樣語句的狀況，缺點是若是抽樣時間長，中心機分析不完，而抽樣時間短又可能信息沒有表明性。 
另一個更輕量級的方法是將慢查詢日誌閥值打到50ms甚至更低，而後統計慢查詢時間的分佈，能夠按時間和服務器維度進行分析（使用pt工具也能夠獲得不一樣語句的響應時間分佈）以下表所示： 
4901 130421 
dt num avg 
—————————– 
0 1839 605 
1 920 596 
2 1215 450 
3 973 481 
4 488 603 
5 449 487 
6 516 597 
7 874 634 
8 1129 532 
9 1160 457 
10 1115 502 
11 987 529 
12 1531 559 
13 1185 537 
14 2238 1235 
15 1418 534 
16 1589 535 
17 951 548 
18 1790 531 
19 1520 503 
20 1845 496 
21 1855 542 
22 1583 564 
23 1840 562 
None 31010 587

ip num ratio 
—————————– 
10.73.xx.xx 4418 14 
10.75.xx.xx 121 0 
10.75.xx.xx 7905 25 
10.75.xx.xx 5706 18 
10.75.xx.xx 6812 22 
10.75.xx.xx 6048 20 
None 31010 100 
根據此結果能夠發現慢查詢在服務器之間分佈並不均衡，這也是分析問題的很好的切入點。

可測量指標： 
X%的查詢/寫入響應時間（ms）。

1.4. 成本 
在解決了穩定和速度後，就是成本的問題了。有人認爲若是不計較成本，任何功能都是能夠實現的，而且不須要高深的技術。我不徹底認同這個觀點。但架構師的使命的確不只僅是「完成」功能，若是說完成功能能夠有50種方法， 
由於經濟學上認爲找到最優方案可能成本比回報還要高，那麼至少要找出相對較優的幾種方法並進行最終的選擇。 
成本的構成主要是硬件成本＋軟件成本＋人力成本，由於互聯網企業軟件以自主開發和開源爲主，因此其中主要是硬件和人力成本，硬件成本也包含了機房的機架，帶寬，電力成本。 
對大型互聯網公司來講，服務器規模都在上萬臺以上，Google的服務器規模更達到了百萬級。而互聯網公司的人才規模也是至關驚人，TAB公司的人員都在萬人以上。 
所以如何可以提升硬件的使用效率，下降人工運維成本，提升人均產出，也就成爲關係到互聯網公司生死存亡的事情了。 
可測量指標： 
投入成本＝硬件成本（含機架，帶寬，電力）＋軟件成本(ＭySQL可忽略) ＋人力成本

1.5. 運維人員幸福度 
運維自動化是方向不假，但目前階段來講，有不少工做還須要人來完成，越是複雜的工做越須要人工干預。對於一些創業公司，自動化平臺更是要從頭打造，此時間段內的不少操做須要手工完成。 
克拉克的《與拉瑪相會》描繪了一個徹底靠機器人運維，在太空中飛行了上萬年的巨大人工飛行器。但如今科技畢竟離此階段還差得遠。人也不是機器人，是有個性，獨一無二的智慧生物。

爲了體現運維的人文關懷，必須加入人員幸福度指標。 
幸福度能夠從3方面考量： 
1）人均承擔數據庫讀寫量（若是數據庫讀寫量大，這個值低，那麼必然運維人員多，人均產值/薪酬低） 
2）運維人員長期從事機械化的，重複性工做的時間比例 
3）運維人員在工做時間之外進行切換上線，故障處理的時間比例 
若是這3項指標差， 那就意味着團隊的幸福感差，必然離職率高。因此離職率也是衡量指標之一。

若是有一個系統可以將上面的5個指標都量化記錄下來，並採用各類方法持繼改進指標，相信最終會創建一個比較好的運維平臺。

 

 

原文  http://www.iamcjd.com/?p=1285