建站
咨詢
售后
建站咨詢
新聞中心
?昨天在南京搞了一場分布式數(shù)據(jù)庫運(yùn)維與優(yōu)化的沙龍，對于分布式數(shù)據(jù)庫的運(yùn)維，我遇到過一個朋友，他說他們現(xiàn)在很頭痛。分布式數(shù)據(jù)庫是小問題不需要運(yùn)維，大問題運(yùn)維人員搞不定。搞得他請外包DBA覺得不劃算，不請又心里不踏實(shí)，用原廠又用不起。目前的情況是有不少企業(yè)已經(jīng)開始使用分布式數(shù)據(jù)庫了，也還有些企業(yè)在觀望，不太敢馬上入坑。他們擔(dān)心的問題主要還是運(yùn)維的問題。運(yùn)維領(lǐng)域有句名言“運(yùn)維最大的困難是未知”。
成都創(chuàng)新互聯(lián)專業(yè)為企業(yè)提供丹陽網(wǎng)站建設(shè)、丹陽做網(wǎng)站、丹陽網(wǎng)站設(shè)計(jì)、丹陽網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、丹陽企業(yè)網(wǎng)站模板建站服務(wù)，10年丹陽做網(wǎng)站經(jīng)驗(yàn)，不只是建網(wǎng)站，更提供有價值的思路和整體網(wǎng)絡(luò)服務(wù)。
這句話包含了多個層面的含義：對數(shù)據(jù)庫運(yùn)行狀態(tài)的未知；對技術(shù)的未知；對可能遇到的問題的未知，這些未知匯聚起來就是恐懼。當(dāng)年我們從foxpro轉(zhuǎn)向大型數(shù)據(jù)庫，轉(zhuǎn)向Oracle的時候，也遇到過這樣的時期，那時候出過幾次大問題并且搞不定后，很多企業(yè)都有過想回到簡單的不需要運(yùn)維的foxpro。與我們熟知的集中式數(shù)據(jù)庫相比，分布式數(shù)據(jù)庫就像一只巨大的史前生物一樣，神秘、未知、令人恐懼。
用過分布式數(shù)據(jù)庫的朋友都知道，分布式數(shù)據(jù)庫從組成結(jié)構(gòu)上來說，更加復(fù)雜。甚至有些國產(chǎn)分布式數(shù)據(jù)庫是由幾十個不同的開源組件組合而成的。僅僅安裝部署，我們就需要學(xué)習(xí)ETCD、ZOOKEEPER、KAFKA、Mysql、Myproxy、普羅米修斯等大型開源組件后才能完成。不過也有些朋友說分布式數(shù)據(jù)庫運(yùn)維其實(shí)沒那么復(fù)雜，大部分的運(yùn)行中遇到的軟硬件故障，分布式數(shù)據(jù)庫都會自動處置，不需要運(yùn)維人員干預(yù)。
說句實(shí)在話，有一種說法。分布式數(shù)據(jù)庫出小問題的時候比較容易處理，數(shù)據(jù)庫本身的高可用就能自動規(guī)避一些小問題，不過分布式數(shù)據(jù)庫最怕出大問題，最怕出了問題不知道如何處置。
在分布式數(shù)據(jù)庫中最怕遇到的是兩個事情，一個是后臺自動任務(wù)沒在維護(hù)窗口跑完，又不敢輕易停止。另外一個就是一個大查詢好像總是跑不完，又不敢干掉重來。遇到這種事情我們是無能為力的，既不能殺掉會話，又不敢重啟數(shù)據(jù)庫，以往在運(yùn)維集中式數(shù)據(jù)庫中的利器似乎都不靈了。
在這種情況下，未知帶來的恐懼是運(yùn)維中最大的問題，因?yàn)榭謶侄扇″e誤的處置措施，從而導(dǎo)致災(zāi)難性的后果，是運(yùn)維中最不能承受的。所以說，我們需要更深入的去理解分布式數(shù)據(jù)庫產(chǎn)品，去探討分布式數(shù)據(jù)庫產(chǎn)品運(yùn)維的一些新的思路。既然未知是最大的困難，那么變未知為可知，甚至已知，是解決分布式數(shù)據(jù)庫運(yùn)維中的十分重要的措施。我們看到現(xiàn)在很多國產(chǎn)分布式數(shù)據(jù)庫已經(jīng)開始重視其可觀測性的問題，不僅提供大量的運(yùn)行指標(biāo)，等待事件，也開始提供一些ASH，SQL執(zhí)行狀態(tài)的全面跟蹤等接口都在不斷的完善中。
雖然數(shù)據(jù)庫提供了一些可觀測性接口，但是我們?nèi)绻欢绾稳ナ褂盟彩前状?。因此我們需要?gòu)建分布式數(shù)據(jù)庫的可觀測性接口的采集、分析能力。與集中式數(shù)據(jù)庫不同，分布式數(shù)據(jù)庫是多節(jié)點(diǎn)、多分區(qū)、多租戶的，計(jì)算節(jié)點(diǎn)和存儲節(jié)點(diǎn)都是分布式的。其指標(biāo)體系十分復(fù)雜。比如一個簡單的參數(shù)“IO讀取隊(duì)列延時”，就是關(guān)于數(shù)據(jù)庫讀磁盤時的AIO隊(duì)列延時。
在分布式數(shù)據(jù)庫中，這個指標(biāo)有明細(xì)的清單，比如在每個服務(wù)，每個租戶上都有一個指標(biāo)。我們來分析這些指標(biāo)的時候，直接用明細(xì)指標(biāo)不太方便，我們還需要構(gòu)建一組統(tǒng)計(jì)數(shù)據(jù)，比如最大值，最小值，標(biāo)準(zhǔn)差，平均值等。在分析的時候，也需要通過這些統(tǒng)計(jì)數(shù)據(jù)來進(jìn)行分析，不能僅僅分析原始數(shù)據(jù)。這樣就會導(dǎo)致原本就十分復(fù)雜的指標(biāo)體系，變得更加復(fù)雜，更加難以人工監(jiān)控了。因此對于分布式數(shù)據(jù)庫的運(yùn)維監(jiān)控，必須構(gòu)建自動化的體系，否則哪怕是專家，遇到一些他們沒有見到過的問題，也很難完成快速分析與問題定位。
在分布式數(shù)據(jù)庫的監(jiān)控指標(biāo)體系構(gòu)建是十分復(fù)雜的，如上圖是一個分布式思考指標(biāo)體系構(gòu)成的示意圖。只有完成這樣的指標(biāo)體系，分布式數(shù)據(jù)庫的健康管理才能進(jìn)行。光有原始指標(biāo)是不夠的，我們必須理解指標(biāo)背后的含義。因此我們需要構(gòu)建分布式數(shù)據(jù)庫指標(biāo)體系的知識圖譜。
比如上面的加強(qiáng)緩沖命中率指標(biāo)關(guān)聯(lián)的問題就涉及到很多個方面。在構(gòu)建知識圖譜的時候，主因次因，直接關(guān)系，間接關(guān)系都要考慮到。這樣在問題分析的時候，才能發(fā)現(xiàn)更多的衍生路徑。這些知識的來源主要是原廠的文檔、專家的運(yùn)維知識、運(yùn)維案例、甚至是開源數(shù)據(jù)庫的源代碼。因?yàn)槟壳拔覀兊膰a(chǎn)數(shù)據(jù)庫的資料與運(yùn)維案例相對匱乏，因此積累運(yùn)維經(jīng)驗(yàn)并不容易。但是這項(xiàng)工作必須開展起來，否則當(dāng)國產(chǎn)數(shù)據(jù)庫大規(guī)模應(yīng)用的時候就抓瞎了。
最后我分享幾點(diǎn)分布式數(shù)據(jù)庫運(yùn)維中的常見問題，首先是分布式數(shù)據(jù)庫本身的高可用架構(gòu)會屏蔽一定的故障。因此對于分布式數(shù)據(jù)庫來說，某個組件的故障是最容易處置的。隔離故障硬件，修復(fù)后再加入集群就可以了。最怕的是硬件不穩(wěn)定，時好時壞。比如某個網(wǎng)絡(luò)接口一會兒UP，一會兒宕，并且是不是丟包。這種情況很可能引發(fā)分布式數(shù)據(jù)庫的嚴(yán)重故障。不過如果能夠盡早發(fā)現(xiàn)這個問題，并且盡快手工停掉這個網(wǎng)絡(luò)端口，對數(shù)據(jù)庫的影響就很小了。硬盤故障也是如此，特別是多路徑故障，很容易形成時好時壞的局面，這時候IO讀寫變得十分不穩(wěn)定，這個節(jié)點(diǎn)就會變得不穩(wěn)定，從而可能引發(fā)整個數(shù)據(jù)庫的問題。
對于硬件故障來說，網(wǎng)絡(luò)故障對分布式數(shù)據(jù)庫的影響是全方位的，偶發(fā)的網(wǎng)絡(luò)延時增大，網(wǎng)絡(luò)丟包等，可能會導(dǎo)致分布式數(shù)據(jù)庫性能抖動甚至引發(fā)主從副本誤切換，從而引發(fā)更大的故障。確保分布式數(shù)據(jù)庫的網(wǎng)絡(luò)帶寬與網(wǎng)絡(luò)延時在一個合理的范圍內(nèi)并且網(wǎng)絡(luò)帶寬不出現(xiàn)瓶頸十分關(guān)鍵。
集群數(shù)據(jù)分布不均衡和負(fù)載分布不均衡也可能會導(dǎo)致分布式數(shù)據(jù)庫的嚴(yán)重故障，當(dāng)某個節(jié)點(diǎn)出現(xiàn)資源瓶頸時，這個影響可能會引發(fā)大型故障。因此對節(jié)點(diǎn)資源的監(jiān)控，一旦發(fā)現(xiàn)較長時間出現(xiàn)某些節(jié)點(diǎn)資源瓶頸，則需要盡快排查，避免引發(fā)大故障。
分布式數(shù)據(jù)庫的慢SQL分析也是十分關(guān)鍵的，發(fā)現(xiàn)慢SQL，讀懂分布式執(zhí)行計(jì)劃，發(fā)現(xiàn)執(zhí)行計(jì)劃中存在的問題，是分布式數(shù)據(jù)庫運(yùn)維DBA日常經(jīng)常要干的事情。如果發(fā)現(xiàn)某個節(jié)點(diǎn)上的并行執(zhí)行比較慢，那么就需要對某個節(jié)點(diǎn)進(jìn)行分析，排除隱患了。
分布式數(shù)據(jù)庫的運(yùn)維，對于企業(yè)和DBA來說，都是處于剛剛起步的階段，相關(guān)的運(yùn)維知識、故障案例、專家經(jīng)驗(yàn)都比較匱乏。數(shù)據(jù)庫廠商也有義務(wù)梳理整理這方面的資料，并在自己的管網(wǎng)上發(fā)布，以便于大家遇到運(yùn)維問題的時候，有個可參考的依據(jù)。我們也希望一些使用同種數(shù)據(jù)庫產(chǎn)品的企業(yè)，也能建立起一個朋友圈，共同分享這方面的經(jīng)驗(yàn)，盡快渡過這個運(yùn)維知識與能力的空窗期。
網(wǎng)站名稱：分布式數(shù)據(jù)庫運(yùn)維有啥特殊的
文章來源：http://www.dlmjj.cn/article/cdphpse.html
