[[71788]]

　　很早前就想寫篇文章介紹一下互聯(lián)網(wǎng)DBA需要干的一些事情，但苦于沒有時(shí)間，忙于平臺(tái)建設(shè)，最近，各個(gè)模塊都初具規(guī)模，故有時(shí)間靜下心來，介紹一下。

　　眾所周知，互聯(lián)網(wǎng)DBA與傳統(tǒng)行業(yè)DBA有很大的不同，那就是管理的機(jī)器多，新技術(shù)更新快，面對(duì)的開發(fā)多、網(wǎng)絡(luò)環(huán)境復(fù)雜、要求7*24待機(jī)；這樣就 導(dǎo)致互聯(lián)網(wǎng)DBA的工作在傳統(tǒng)DBA工作之上，增加了更多的復(fù)雜性，我們必須考慮如何大批量部署，如何集中化監(jiān)控、如何解決單點(diǎn)故障而保障7*24，而為 了做到這些，不是靠堆人力，我們必須有一個(gè)完整的平臺(tái)作為支撐，那么數(shù)據(jù)庫平臺(tái)到底要建成什么樣子呢？

1、強(qiáng)有力的監(jiān)控系統(tǒng)（監(jiān)+控）：

　　監(jiān)控是我們的眼睛，我們不可能7*24個(gè)小時(shí)盯著我們的DB，所以，我們需要監(jiān)控系統(tǒng)來幫我們盯著，一旦異常，監(jiān)控不僅僅通知我們，而必須要有控 制，例如：MySQL 從庫宕機(jī)了我們通過監(jiān)控自動(dòng)讓其下線；從庫同步狀態(tài)失效了，可以自動(dòng)修復(fù)同步等；并且，隨著機(jī)器的增加、實(shí)例daemon的增加，我們會(huì)發(fā)現(xiàn)我們的手機(jī)報(bào) 警會(huì)急劇增加，為了我們自己晚上能睡一個(gè)安穩(wěn)覺，我們?cè)趺慈ソ档臀覀兊膱?bào)警，例如：哪些該短信，哪些該郵件；所有機(jī)器的磁盤空間報(bào)警是否可以整合后在報(bào) 呢？這就是我們監(jiān)控系統(tǒng)必須考慮的，

2、自動(dòng)審核系統(tǒng)：

　　開發(fā)很多，項(xiàng)目很多，但是開發(fā)的習(xí)慣都不一致，可能會(huì)導(dǎo)致我們審核表結(jié)構(gòu)的時(shí)頭都看大了，為了保證線上的統(tǒng)一，為了保證不被開發(fā)的神奇SQL搞傷， 不被N多的項(xiàng)目審核壓垮，我們必須有一個(gè)自動(dòng)建表審核系統(tǒng)，我們定義一些規(guī)則，如：不能用預(yù)留字段、主鍵必須為INT，BIGINT等，然后開發(fā)填寫準(zhǔn)備 上線的表結(jié)構(gòu)，通過系統(tǒng)自動(dòng)審核，審核通過的，自動(dòng)上線，審核不通過的，給出建議；

3、慢日志分析系統(tǒng)：

　　隨著自動(dòng)審核系統(tǒng)的上線，我們可能會(huì)漏掉一些索引使用不太好的SQL，那么我們就需要慢日志分系統(tǒng)幫助我們，在設(shè)計(jì)該系統(tǒng)時(shí)候，我們需要考慮是實(shí)時(shí) 抓取慢日志，還是每天定期推送慢日志、慢日志抓取后是立即推送給開發(fā)還是自動(dòng)分析完以后給出建議給開發(fā)、慢日志還要考慮一些SQL是否需要過濾，因?yàn)樗?能是每天的統(tǒng)計(jì)，當(dāng)然這些都是自動(dòng)的，設(shè)計(jì)完后，不需要人工介入；

4、統(tǒng)計(jì)系統(tǒng)：

　　我們必須清晰的知道線上DB的整體運(yùn)行情況，訪問量的變化、寫入量的變化、圖是死的，他不會(huì)欺騙任何人；我們能通過訪問統(tǒng)計(jì)知道是否有惡意訪問、是否需要優(yōu)化，是否需要增加節(jié)點(diǎn)抗住更大的壓力；

5、備份系統(tǒng)：

　　不管你信不信，我是信了，冷備份總是我們的救命草，不管我們做的多么好，故障總會(huì)有，drop database也會(huì)發(fā)生，所以，一個(gè)完整的備份系統(tǒng)，勢(shì)在必行，我們的備份是否正常，備份的數(shù)據(jù)是否能恢復(fù)，恢復(fù)需要多少時(shí)間，都是我們備份系統(tǒng)需要考慮的；

6、管理系統(tǒng)：

　　我們機(jī)器少則上百臺(tái)，多則可能好幾千，如何清晰知道每臺(tái)機(jī)器跑了多少daemon，DB Proxy下面有哪些機(jī)器，如何能對(duì)主庫機(jī)器、從庫機(jī)器進(jìn)行腳本分別分發(fā)等；都需要管理系統(tǒng)來幫我們完成；

7、中間層：

　　是把雙刃劍，他能給我們帶來好的擴(kuò)展，例如：動(dòng)態(tài)添加從庫、主庫失效檢測(cè)等；但是他帶來了DBA管理的復(fù)雜性、帶來了更多的故障點(diǎn)、帶來了更多的 bug、如果DB Proxy性能不好的話，那就更糟了，并且為了解決client透明，我們必須考慮很多，例如：連接保持，如：字符集、last_insert_id、 use dbname等；如果我們有人力開發(fā)維護(hù)，那么我相信Proxy會(huì)帶給我們歡樂；

　　以上各個(gè)系統(tǒng)都是為我們管理DB提供支持，如果沒有這些系統(tǒng)支持，那么數(shù)據(jù)庫管理就談不上平臺(tái)，談不上批量管理，談不上承載百億訪問量，百T數(shù)據(jù)量 的數(shù)據(jù)庫；當(dāng)然在涉及這樣的系統(tǒng)時(shí)候，我們也要考慮新技術(shù)的引進(jìn)，例如：如果能快速的打造NoSQL 平臺(tái)等；當(dāng)然在部署這些模塊的時(shí)候，我們時(shí)時(shí)刻刻記得，所有的模塊都是會(huì)變的，我們需要不停的學(xué)習(xí)，不停的改進(jìn)，才會(huì)打造宕機(jī)時(shí)間更低的數(shù)據(jù)庫服務(wù)。

　　后續(xù)會(huì)慢慢分享出，我們這些模塊是如何做的，及其進(jìn)度如何。