PG資料庫維運工具要涵蓋哪些能力

過節前我和PG中國社區合作搞了一個關於如何使用D-SMART來運維PG數據庫的線上直播，正好我的一個金融行業的客戶聽了我的介紹，打電話過來聊了聊。他們正在做資料庫信創的選型，也試用了多個國產資料庫，最後他們準備選擇TDSQL。當時我覺得有點意外，他們從2020年就開始在做國產資料庫選型，不過好像最初使用TDSQL後的感受並不太好。後來經過溝通才了解到，他們剛開始使用TDSQL的分散式資料庫，發現對研發要求太高，所以後來就全部選擇TDSQL的集中式MYSQL實例，用下來發現挺好用的。整個資料庫雲端的節點數也從最初的十幾個擴展到了大幾十個。

無獨有偶，昨天和另一個金融客戶在微信上聊了聊資料庫信創選型的事情，他們最後也選擇了TDSQL。和另外一個客戶相似的是，他們也是選擇了TDSQL的MYSQL集中式資料庫實例。他們目前已經遷移了數十套資料庫上去，大多數都是幾十GB到幾百GB的小庫。他們覺得，小資料庫，直接移轉到TDSQL的雲端平台上，使用起來十分便捷，TDSQL的資料庫雲端管平台和維運工具基本上已經能夠滿足他們日常運維的需要了。

透過交流我覺得，這兩個客戶選擇TDSQL，並不是因為TDSQL作為資料庫有多優秀（TDSQL其實不是資料庫，而是資料庫雲端平台解決方案，關於TDSQL今後有空，我會寫一篇詳細介紹），而是其資料庫雲管平台對於納管大量的小型資料庫實例，做的十分到位，使用者選擇它，並不是從資料庫技術來考慮的，而是從使用的便捷性與可靠性來考慮的。

從客戶選擇TDSQL的理由，我們再來看看PG資料庫的運維。泛泛的談PG資料庫的維運是個十分龐大的話題，因為不同的客戶有其特殊的應用場景，對PG資料庫的維運管理方式也有較大的差異。更複雜的是，和我所說的這兩個選擇TDSQL的客戶不同的是，PG資料庫既有小型資料庫，也有十分大型的資料庫系統。有些客戶在搞信創造替代的時候，是把Oracle資料庫1對1做替代的，很多資料庫的熱資料都超過數個TB。面對規模差異極大，維運要求不同的應用場景，維運工具要適應千差萬別的應用場景，確實是需要精心設計的。

PG資料庫在國內的應用這兩年發展的很快，再加上很多國產資料庫也是以PG開源專案作為基礎研發的，在應用、維運上十分相似，因此我們也可以把它們被歸類為PG類的資料庫產品。

目前的國產資料庫中，許多產品都是以PG社群版程式碼作為研發起點的，還有一些產品是基於openGauss開源專案的。這些資料庫的基礎特性都和社群版的PG資料庫類似，不過也做了一定的拓展。不過從使用與維運上，它們的許多特性都與社群版PG十分類似。

還有一些資料庫產品也和PG有著直接的關係，不過大部分基於PG的分散式解決方案PGXL/PGXC或CITUS。例如騰訊的TBASE，南大通用的GBASE 8C分散式版本、亞信的ANTDB，虛谷資料庫等。這裡就不做仔細的羅列了。這些資料庫的某個實例也是一個PG資料庫，對某個特定的實例也可以看做是PG資料庫實例，只不過在維運分散式資料庫的時候，需要更加關注整個群集與網路的問題，在維運上差別還是很大的。

概括的說，PG資料庫的維運需求分為五個方面，日常監控、故障預警、自動化巡檢、效能最佳化和故障診斷。

有些企業已經在把一些核心系統在遷移到PG類別資料庫了，對於這些系統，日常就有監控的需求。因此一個資料庫維運工具需要具備的最基礎的能力就是監控能力，能夠透過維運工具隨時了解資料庫執行個體的整體運作狀態。 D-SMART是透過健康模型來展示資料庫的運作狀態的。除此之外，如果我們在一些重大日期要做值守（例如企業的年終決算，國慶日等專案值守等），那麼我們就還需要一些能夠支撐關鍵系統值守的工具。

在D-SMART中，圍繞著資料庫運作我們提供了「監控中心」、「日檢中心」、「警告中心」、「效能最佳化中心」、「報告中心」、「容量管理中心」、「安全中心」、「工具中心」這幾個中心化的功能組合來滿足不同用戶，不同應用場景的用戶的需求。

對於日常監控功能，D-SMART提供了「今日看板」、「我的監控」、「關鍵SQL監控」這三個主要的維運監控工具。今日看板可以集中查看用戶監控的資料庫的綜合信息，「我的監控」允許用戶用傳統的監控方法去定義自己想要監控的指標，用於重大護航監控。而「關鍵SQL監控」則是為企業核心業務系統提供的專項監控工具。當某個核心業務系統的關鍵SQL出現問題的時候（例如執行速度變慢，執行計畫變更等），能夠及時告警，確保核心業務的安全運作。

對於大量的小型的資料庫實例，全面監控是不太現實的。如果一個十幾人的團隊要維運數百上千個資料庫實例，那麼最這些資料庫進行全面監控既不必要，也不可能。因此這種維運場景應該會把大量的監控工作變成自動化任務，由監控系統自動完成。

「資料庫日檢」是一個十分有效的自動化維運工具，每天半夜針對資料庫的運作資料以及一些規則自動做分析，並形成言簡意賅的日檢總結報告，維運人員上班後直接閱讀這些報告就可以了解自己運維的數百個資料庫實例中存在的一些常見問題，從而可以確定當天或近期是否需要對某些資料庫實例做相應的變更。

當我們需要維運大量的小型資料庫實例的時候，預警也變得十分困難了。傳統的「基線警告」的效果就變得十分雞肋了。除了資料庫實例宕機以外，其他的預警很難做的精準。海量的警報訊息會讓預警變得毫無意義。因此基於故障模型的「維運經驗告警」變得尤為重要。透過專家經驗與以往的經驗建構的複雜的規則不僅能夠更為精準的預警，也能讓告警產生後，維運人員可以更加快速的定位問題，消除隱患。

「資料庫巡檢」是廣大DBA都覺得十分雞肋的功能，最主要的問題在於這項工作必須做，但是做一次真正到位的巡檢既需要​​大量的專業DBA參與，又需要做大量的重複勞動，總的看來，性價比並不高。另外一方面，全面高品質的巡檢又能夠幫助我們發現一些系統隱患，有助於實現防患於未然。針對這個矛盾，如果能夠實現高品質的自動化巡檢，那麼問題就迎刃而解了。幾個月前，我們幫助一個使用者做了一次遠端巡檢，使用者把D-SMART採集的監控資料寄給我們實驗室，我們的資料庫專家利用遠端資料產生的巡檢報告，對近30套資料庫系統進行了一次遠距會診，幫助使用者發現了各類問題兩百多個，而這些工作僅僅花了不到2個人天。透過自動化手段，如果能夠把資料庫巡檢的效率提高了，那麼巡檢工作就不會這麼雞肋了。

除了巡檢之外，有些審計工作也十分關鍵，例如安全審計、容量審計、SQL審計等。因為這些審計需要十分專業的技能，另外工作量也很大，因此在面對大量的資料庫實例的時候，也和巡檢一樣變得十分雞肋，要想做到位成本太高，做不到位等於不做。不過這些工作如果能夠由自動化工具自動完成，那麼也就能夠發揮出十分重要的作用了。

實際上除了這些運維監控工作之外，大量的資料庫實例的管理工作還有很多自動化操作是DBA十分需要的，這也是我開始說的那兩個客戶選擇TDSQL的主要原因。管理海量的資料庫實例，資料庫雲端平台是必選項，只不過這些自動化管理功能本身就十分複雜，根據企業特性建構獨立的資料庫雲端平臺本身就是一個大工程。當然，如果企業雲端平台的RDS服務就能夠滿足你的資料庫應用需求了，那麼直接使用雲端平台的RDS就夠用了。當然面對現在的信創需求，需要企業的RDS需要不只支援開源的MYSQL/PG資料庫，也要支援國產資料庫產品。

以上是PG資料庫維運工具要涵蓋哪些能力的詳細內容。更多資訊請關注PHP中文網其他相關文章！