?過節前我和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數據庫，也要支持國產數據庫產品。?