建站
咨詢
售后
建站咨詢
新聞中心
?前陣子和一個(gè)做數(shù)據(jù)庫服務(wù)的朋友交流，他們承接了某個(gè)企業(yè)的國產(chǎn)分布式數(shù)據(jù)庫的運(yùn)維工作，安排了一個(gè)該數(shù)據(jù)庫的認(rèn)證工程師駐場做服務(wù)，不過從半年的工作情況來看，效果并不好。作為分布式數(shù)據(jù)庫的運(yùn)維，平時(shí)小問題也不需要DBA介入，分布式數(shù)據(jù)庫的故障自愈能力能夠很好的屏蔽這些小問題，并且能夠在短時(shí)間內(nèi)完成自愈。如果真的出了大問題，DBA面對數(shù)十個(gè)節(jié)點(diǎn)的分布式數(shù)據(jù)庫環(huán)境又束手無策，很難定位問題，這種情況讓他們感到很困惑。
創(chuàng)新互聯(lián)建站成都企業(yè)網(wǎng)站建設(shè)服務(wù)，提供網(wǎng)站制作、網(wǎng)站建設(shè)網(wǎng)站開發(fā),網(wǎng)站定制,建網(wǎng)站,網(wǎng)站搭建,網(wǎng)站設(shè)計(jì),自適應(yīng)網(wǎng)站建設(shè),網(wǎng)頁設(shè)計(jì)師打造企業(yè)風(fēng)格網(wǎng)站,提供周到的售前咨詢和貼心的售后服務(wù)。歡迎咨詢做網(wǎng)站需要多少錢:18980820575
實(shí)際上這個(gè)問題還是挺復(fù)雜的，涉及到分布式數(shù)據(jù)庫這種典型的分布式系統(tǒng)與集中式數(shù)據(jù)庫之間在架構(gòu)與功能上的巨大差異。在傳統(tǒng)的數(shù)據(jù)庫運(yùn)維上，我們習(xí)慣于查看一些指標(biāo)，例如CPU負(fù)載，鎖超時(shí)，活躍會話數(shù)、錯(cuò)誤率等。對于分布式數(shù)據(jù)庫來說，這些指標(biāo)實(shí)際上并沒有相對于集中式數(shù)據(jù)庫環(huán)境那么重要，因?yàn)榉植际綌?shù)據(jù)庫從體系架構(gòu)上具有極高的容錯(cuò)能力。數(shù)據(jù)庫的某個(gè)物理節(jié)點(diǎn)、某個(gè)服務(wù)、某個(gè)分區(qū)、某個(gè)副本都可以出故障，此時(shí)數(shù)據(jù)庫內(nèi)部雖然已經(jīng)存在故障，但是你一點(diǎn)都不需要為此擔(dān)心，數(shù)據(jù)庫依然能夠很好的對外提供服務(wù)。這些指標(biāo)實(shí)際上都沒有正確的反映出數(shù)據(jù)庫是否能夠?yàn)榭蛻舳肆髁刻峁┱５姆?wù)，而這些才是用戶需要關(guān)注的。
在“具有動態(tài)糾錯(cuò)能力”并且“可以自動擴(kuò)展、動態(tài)負(fù)載均衡”的分布式數(shù)據(jù)庫中，如果單個(gè)服務(wù)無法實(shí)現(xiàn)完整的數(shù)據(jù)庫功能，那么單個(gè)服務(wù)是否處于“啟動”或者“活躍”狀態(tài)并不重要，因?yàn)檫@些很可能都不會影響分布式數(shù)據(jù)庫對外提供服務(wù)，這使得像ping延時(shí)、CPU使用率這樣的簡單檢查幾乎毫無用處。雖然利用傳統(tǒng)的監(jiān)控理念，判斷某個(gè)服務(wù)是否宕掉并不復(fù)雜，但要確定處于活動狀態(tài)的數(shù)據(jù)庫服務(wù)是否健康要困難得多。
也可以通過一些比較簡單的方式來判斷分布式數(shù)據(jù)庫的服務(wù)是否正常。服務(wù)很有可能處于“啟動”狀態(tài)，并且并能夠?qū)ν馓峁?shù)據(jù)庫服務(wù)，但是它無法在服務(wù)的 99分位延遲內(nèi)完成給定的工作任務(wù)（比如完成一條標(biāo)準(zhǔn)SQL的執(zhí)行），那么這個(gè)數(shù)據(jù)庫就是不健康的。
對于分布式數(shù)據(jù)庫來說，無法在P99延時(shí)內(nèi)執(zhí)行完某條SQL，但是數(shù)據(jù)庫服務(wù)還是能承接相關(guān)業(yè)務(wù)的，這種情況是比較常見的故障場景，也是我們的DBA面對的束手無策的常見場景。這種場景大多數(shù)情況下與數(shù)據(jù)庫的某些組件流量過載有關(guān)，在高并發(fā)服務(wù)中，“高并發(fā)的重負(fù)載”會在分布式數(shù)據(jù)庫中受到某些串行化機(jī)制的影響，正常情況下，通過資源管理器與隊(duì)列機(jī)制有序的排序。但是如果某個(gè)組件出現(xiàn)過載，那么隊(duì)列會產(chǎn)生溢出，這可能導(dǎo)致 RPC 調(diào)用的延遲增加。一般情況下遇到這種情況，下游服務(wù)將簡單地使請求超時(shí)并進(jìn)行重試，這種機(jī)制將會導(dǎo)致高負(fù)載情況下出現(xiàn)分布式系統(tǒng)的效率下降的問題，此時(shí)分布式數(shù)據(jù)庫的總體性能會有所下降。而如果此時(shí)疊加一些其他的因素，比如某塊硬盤的IO延時(shí)過大、某個(gè)網(wǎng)卡出現(xiàn)丟包、某個(gè)節(jié)點(diǎn)的操作系統(tǒng)出現(xiàn)嚴(yán)重?fù)Q頁，那么整個(gè)分布式數(shù)據(jù)庫環(huán)境就有可能出現(xiàn)了正常的處理邏輯無法承受的臨界狀態(tài)，再疊加上數(shù)據(jù)庫本身就存在的一些對此類情況處理不周的BUG，那么數(shù)據(jù)庫出現(xiàn)嚴(yán)重的問題，甚至出現(xiàn)無法對外提供服務(wù)的情況，也是必然的。
而且分布式數(shù)據(jù)庫一旦進(jìn)入這樣的狀態(tài)，要想通過自身的容錯(cuò)能力與資源調(diào)度能力恢復(fù)系統(tǒng)運(yùn)行，那就不是秒鐘級甚至分鐘級能夠完成的了。此時(shí)最好的方法應(yīng)該是徹底關(guān)閉數(shù)據(jù)庫系統(tǒng)，解決掉出現(xiàn)問題的根源問題，然后重新啟動數(shù)據(jù)庫。但是對于分布式數(shù)據(jù)庫這種大型系統(tǒng)而言，在出現(xiàn)故障的時(shí)候關(guān)閉數(shù)據(jù)庫在大多數(shù)場景中也是不現(xiàn)實(shí)的。因此我們只有退而求其次，降低數(shù)據(jù)庫當(dāng)前的復(fù)雜，解決掉故障問題是退而求其次的解決方案。如果這個(gè)方法還是無法執(zhí)行，那么就只能先解決掉導(dǎo)致問題的故障，再慢慢等著系統(tǒng)恢復(fù)了。
綜上所述，分布式數(shù)據(jù)庫的某個(gè)服務(wù)在其生命周期中很可能在不同程度的“健康狀態(tài)”之間波動，從完全正常，能夠以預(yù)期的并發(fā)級別運(yùn)行下降到接近不正常，此時(shí)可能某些高負(fù)載導(dǎo)致某的隊(duì)列溢出，如果問題持續(xù)惡化，數(shù)據(jù)庫將進(jìn)入“不正?！睜顟B(tài)，此時(shí)數(shù)據(jù)庫服務(wù)質(zhì)量大幅下降。對于分布式數(shù)據(jù)庫而言，自適應(yīng)、自我修復(fù)的能力在大部分情況下可以自動處理這種波動，并力求自動恢復(fù)?？上У氖沁@種最佳預(yù)期并不總是在生產(chǎn)環(huán)境中得以實(shí)現(xiàn)，分布式數(shù)據(jù)庫可能存在某些BUG；而高并發(fā)負(fù)載的持續(xù)時(shí)間可能超出硬件的能力范圍；面包掉在地上黃油朝下的概率也極高。因此分布式數(shù)據(jù)庫可以解決一切集中式數(shù)據(jù)庫運(yùn)維中的問題，達(dá)到極高的可用性的說法并不成立。
對于分布式數(shù)據(jù)庫運(yùn)維來說，小問題無需介入，大問題介入不了是一種常態(tài)。其最主要的問題還是我們無法對分布式數(shù)據(jù)庫的健康狀態(tài)有一個(gè)十分準(zhǔn)確的評估。如果我們能夠了解分布式數(shù)據(jù)庫的內(nèi)部狀態(tài)，并提前做出預(yù)警，那么很多故障還是可以避免的。比如負(fù)載過高達(dá)到硬件資源極限可以通過切斷部分流量來實(shí)現(xiàn)快速恢復(fù)。而如果能夠在問題發(fā)生的更早期介入，數(shù)據(jù)庫的恢復(fù)時(shí)間也會縮短很多。
比較麻煩的是，分布式數(shù)據(jù)庫的健康評估是比較復(fù)雜的，對于分布式數(shù)據(jù)庫來說，健康評估更像是一個(gè)布魯姆過濾器。你發(fā)現(xiàn)數(shù)據(jù)庫有問題，那么數(shù)據(jù)庫肯定有問題。但是如果你檢查數(shù)據(jù)庫的狀態(tài)是健康的，那么數(shù)據(jù)庫僅僅是“可能處于健康狀態(tài)”，我們必須通過其他的因素來確認(rèn)其實(shí)健康的。
基于上面的認(rèn)知，我們覺得針對分布式數(shù)據(jù)庫的健康度需要從幾個(gè)方面來做綜合評估，傳統(tǒng)的指標(biāo)當(dāng)然還是需要的，我們需要從操作系統(tǒng)負(fù)載與性能、數(shù)據(jù)庫負(fù)載、數(shù)據(jù)庫并發(fā)、集群與網(wǎng)絡(luò)、負(fù)載均衡度、數(shù)據(jù)庫容量等數(shù)個(gè)方面進(jìn)行評估。
除此之外針對分布式數(shù)據(jù)庫，我們還需要引入新的評估要素，那就是數(shù)據(jù)庫功能的健康度評估，簡單查詢、簡單寫入、全表掃描、索引掃描、并行掃描、DDL操作等多種數(shù)據(jù)庫業(yè)務(wù)的響應(yīng)時(shí)間是否合理（比如是否超出P99延時(shí)），不同計(jì)算節(jié)點(diǎn)執(zhí)行相同的簡單操作的延時(shí)是否均衡等，也應(yīng)該作為健康評估的內(nèi)容。必須如此，才能解決分布式數(shù)據(jù)庫健康評估的“布魯姆過濾器陷阱”。
僅僅實(shí)現(xiàn)準(zhǔn)確的健康評估還不足夠，更重要的是發(fā)現(xiàn)健康問題之后還需要能夠進(jìn)行問題溯源與解決方案分析。要想實(shí)現(xiàn)這一點(diǎn)，必須從兩個(gè)方面做監(jiān)控的增強(qiáng)。一方面是更加準(zhǔn)確與全面的采集分布式數(shù)據(jù)庫的指標(biāo)，并能夠高效的進(jìn)行異常檢測，從而能夠全面的發(fā)現(xiàn)數(shù)據(jù)庫指標(biāo)的異常；另外一方面是能夠快速的積累故障模型，構(gòu)建常見故障的分析診斷與應(yīng)急處置的標(biāo)準(zhǔn)化方法。
比如上面是某國產(chǎn)分布式數(shù)據(jù)庫的一個(gè)故障場景，該場景會導(dǎo)致業(yè)務(wù)響應(yīng)變慢。只要擁有充分的指標(biāo)數(shù)據(jù)，通過規(guī)則引擎很容易描述出其中的場景，并形成自動化分析與診斷的工具。一切恐懼都來自于未知，正是因?yàn)槲覀儗a(chǎn)分布式數(shù)據(jù)庫的運(yùn)維經(jīng)驗(yàn)積累還不充分，才導(dǎo)致了遇到問題時(shí)的手足無措。二十多年前，我們面對Oracle數(shù)據(jù)庫的時(shí)候，也是如此的，隨著應(yīng)用場景的豐富以及運(yùn)維經(jīng)驗(yàn)被不斷的積累，這些問題都會慢慢好起來的。?
當(dāng)前名稱：一篇讀懂分布式數(shù)據(jù)庫的健康評估
本文來源：http://www.5511xx.com/article/cdgihpc.html
