?過節(jié)前我和PG中國社區(qū)合作搞了一個關(guān)于如何使用D-SMART來運維PG數(shù)據(jù)庫的線上直播，正好我的一個金融行業(yè)的客戶聽了我的介紹，打電話過來聊了聊。他們正在做數(shù)據(jù)庫信創(chuàng)的選型，也試用了多個國產(chǎn)數(shù)據(jù)庫，最后他們準備選擇TDSQL。當時我覺得有點意外，他們從2020年就開始在做國產(chǎn)數(shù)據(jù)庫選型，不過好像最初使用TDSQL后的感受并不太好。后來經(jīng)過溝通才了解到，他們剛開始使用TDSQL的分布式數(shù)據(jù)庫，發(fā)現(xiàn)對研發(fā)要求太高，所以后來就全部選擇TDSQL的集中式MYSQL實例，用下來發(fā)現(xiàn)挺好用的。整個數(shù)據(jù)庫云的節(jié)點數(shù)也從最初的十幾個擴展到了大幾十個。

無獨有偶，昨天和另外一個金融客戶在微信上聊了聊數(shù)據(jù)庫信創(chuàng)選型的事情，他們最終也選擇了TDSQL。和另外一個客戶相似的是，他們也是選擇了TDSQL的MYSQL集中式數(shù)據(jù)庫實例。他們目前已經(jīng)遷移了數(shù)十套數(shù)據(jù)庫上去，大多數(shù)都是幾十GB到幾百GB的小庫。他們覺得，小數(shù)據(jù)庫，直接遷移到TDSQL的云平臺上，使用起來十分便捷，TDSQL的數(shù)據(jù)庫云管平臺和運維工具基本上已經(jīng)能夠滿足他們?nèi)粘＿\維的需要了。

通過交流我覺得，這兩個客戶選擇TDSQL，并不是因為TDSQL作為數(shù)據(jù)庫有多優(yōu)秀（TDSQL實際上不是一個數(shù)據(jù)庫，而是一個數(shù)據(jù)庫云平臺解決方案，關(guān)于TDSQL今后有空，我會寫一篇詳細介紹），而是其數(shù)據(jù)庫云管平臺對于納管大量的小型數(shù)據(jù)庫實例，做的十分到位，用戶選擇它，并不是從數(shù)據(jù)庫技術(shù)來考慮的，而是從使用的便捷性與可靠性來考慮的。

(資料圖片僅供參考)

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

PG數(shù)據(jù)庫在國內(nèi)的應(yīng)用這兩年發(fā)展的很快，再加上很多國產(chǎn)數(shù)據(jù)庫也是以PG開源項目作為基礎(chǔ)研發(fā)的，在應(yīng)用、運維上十分相似，因此我們也可以把它們歸類為PG類的數(shù)據(jù)庫產(chǎn)品。

目前的國產(chǎn)數(shù)據(jù)庫中，很多產(chǎn)品都是以PG社區(qū)版代碼作為研發(fā)起點的，還有一些產(chǎn)品是基于openGauss開源項目的。這些數(shù)據(jù)庫的基礎(chǔ)特性都和社區(qū)版的PG數(shù)據(jù)庫類似，不過也做了一定的拓展。不過從使用與運維上，它們的很多特性都與社區(qū)版PG十分類似。

還有一些數(shù)據(jù)庫產(chǎn)品也和PG有著直接的關(guān)系，不過大部分基于PG的分布式解決方案PGXL/PGXC或者CITUS。比如騰訊的TBASE，南大通用的GBASE 8C分布式版本、亞信的ANTDB，虛谷數(shù)據(jù)庫等。這里就不做仔細的羅列了。這些數(shù)據(jù)庫的某個實例也是一個PG數(shù)據(jù)庫，對某個具體的實例也可以看做是PG數(shù)據(jù)庫實例，只不過在運維分布式數(shù)據(jù)庫的時候，需要更加關(guān)注整個集群與網(wǎng)絡(luò)的問題，在運維上區(qū)別還是很大的。

概括的說，PG數(shù)據(jù)庫的運維需求分為五個方面，日常監(jiān)控、故障預警、自動化巡檢、性能優(yōu)化和故障診斷。

有些企業(yè)已經(jīng)在把一些核心系統(tǒng)在向PG類數(shù)據(jù)庫遷移了，對于這些系統(tǒng)，日常就有監(jiān)控的需求。因此一個數(shù)據(jù)庫運維工具需要具備的最基礎(chǔ)的能力就是監(jiān)控能力，能夠通過運維工具隨時了解數(shù)據(jù)庫實例的總體運行狀態(tài)。D-SMART是通過健康模型來展示數(shù)據(jù)庫的運行狀態(tài)的。除此之外，如果我們在一些重大日期要做值守（比如企業(yè)的年終決算，國慶節(jié)等專項值守等），那么我們就還需要一些能夠支撐關(guān)鍵系統(tǒng)值守的工具。

在D-SMART中，圍繞數(shù)據(jù)庫運維我們提供了“監(jiān)控中心”、“日檢中心”、“告警中心”、“性能優(yōu)化中心”、“報告中心”、“容量管理中心”、“安全中心”、“工具中心”這幾個中心化的功能組合來滿足不同用戶，不同應(yīng)用場景的用戶的需求。

對于日常監(jiān)控功能，D-SMART提供了“今日看板”、“我的監(jiān)控”、“關(guān)鍵SQL監(jiān)控”這三個主要的運維監(jiān)控工具。今日看板可以集中查看用戶監(jiān)控的數(shù)據(jù)庫的綜合信息，“我的監(jiān)控”允許用戶用傳統(tǒng)的監(jiān)控方法去定義自己想要監(jiān)控的指標，用于重大護航監(jiān)控。而“關(guān)鍵SQL監(jiān)控”則是為企業(yè)核心業(yè)務(wù)系統(tǒng)提供的專項監(jiān)控工具。當某個核心業(yè)務(wù)系統(tǒng)的關(guān)鍵SQL出現(xiàn)問題的時候（比如執(zhí)行速度變慢，執(zhí)行計劃變化等），能夠及時告警，確保核心業(yè)務(wù)的安全運行。

對于大量的小型的數(shù)據(jù)庫實例，全面監(jiān)控是不太現(xiàn)實的。如果一個十幾人的團隊要運維數(shù)百上千個數(shù)據(jù)庫實例，那么最這些數(shù)據(jù)庫進行全面監(jiān)控既不必要，也不可能。因此這種運維場景應(yīng)該把大量的監(jiān)控工作變成自動化任務(wù)，由監(jiān)控系統(tǒng)自動完成。

“數(shù)據(jù)庫日檢”是一個十分有效的自動化運維工具，每天半夜針對數(shù)據(jù)庫的運行數(shù)據(jù)以及一些規(guī)則自動做分析，并形成言簡意賅的日檢總結(jié)報告，運維人員上班后直接閱讀這些報告就可以了解自己運維的數(shù)百個數(shù)據(jù)庫實例中存在的一些常見問題，從而可以確定當天或者近期是否需要對某些數(shù)據(jù)庫實例做相應(yīng)的變更。

當我們需要運維大量的小型數(shù)據(jù)庫實例的時候，預警也變得十分困難了。傳統(tǒng)的“基線告警”的效果就變得十分雞肋了。除了數(shù)據(jù)庫實例宕機以外，其他的預警很難做的精準。海量的告警信息會讓預警變得毫無意義。因此基于故障模型的“運維經(jīng)驗告警”變得尤為重要。通過專家經(jīng)驗與以往的經(jīng)驗構(gòu)建的復雜的規(guī)則不僅能夠更為精準的預警，也能讓告警產(chǎn)生后，運維人員可以更加快速的定位問題，消除隱患。

“數(shù)據(jù)庫巡檢”是廣大DBA都覺得十分雞肋的功能，最主要的問題在于這項工作必須做，但是做一次真正到位的巡檢既需要大量的專業(yè)DBA參與，又需要做大量的重復勞動，總的看來，性價比并不高。另外一方面，全面高質(zhì)量的巡檢又能夠幫助我們發(fā)現(xiàn)一些系統(tǒng)隱患，有助于實現(xiàn)防患于未然。針對這個矛盾，如果能夠?qū)崿F(xiàn)高質(zhì)量的自動化巡檢，那么問題就迎刃而解了。幾個月前，我們幫助一個用戶做了一次遠程巡檢，用戶把D-SMART采集的監(jiān)控數(shù)據(jù)發(fā)給我們實驗室，我們的數(shù)據(jù)庫專家利用遠程數(shù)據(jù)產(chǎn)生的巡檢報告，對近30套數(shù)據(jù)庫系統(tǒng)進行了一次遠程會診，幫助用戶發(fā)現(xiàn)了各類問題兩百多個，而這些工作僅僅花了不到2個人天。通過自動化手段，如果能夠把數(shù)據(jù)庫巡檢的效率提高了，那么巡檢工作也就不會這么雞肋了。

除了巡檢之外，一些審計工作也十分關(guān)鍵，比如安全審計、容量審計、SQL審計等。因為這些審計需要十分專業(yè)的技能，另外工作量也很大，因此在面對大量的數(shù)據(jù)庫實例的時候，也和巡檢一樣變得十分雞肋，要想做到位成本太高，做不到位等于不做。不過這些工作如果能夠由自動化工具自動完成，那么也就能夠發(fā)揮出十分重要的作用了。

實際上除了這些運維監(jiān)控工作之外，大量的數(shù)據(jù)庫實例的管理工作還有很多自動化操作是DBA十分需要的，這也是我開始說的那兩個客戶選擇TDSQL的主要原因。管理海量的數(shù)據(jù)庫實例，數(shù)據(jù)庫云平臺是必選項，只不過這些自動化管理功能本身就十分復雜，根據(jù)企業(yè)特點構(gòu)建獨立的數(shù)據(jù)庫云平臺本身就是一個大工程。當然，如果企業(yè)云平臺的RDS服務(wù)就能夠滿足你的數(shù)據(jù)庫應(yīng)用需求了，那么直接使用云平臺的RDS就夠用了。當然面對現(xiàn)在的信創(chuàng)需求，需要企業(yè)的RDS需要不僅僅支持開源的MYSQL/PG數(shù)據(jù)庫，也要支持國產(chǎn)數(shù)據(jù)庫產(chǎn)品。?

關(guān)鍵詞： 核心業(yè)務(wù) 另外一個 自動完成 運行狀態(tài)