本周要開啟一次艱苦的差旅行程，一周之內在五個城市間穿梭，拜訪數個客戶。因此本周可能只能寫一兩篇了。

上周五OBDIAG周會上，我提了兩個小工具的需求，其中一個是參數比對工具，希望OBDIAG提供一個能夠對OB參數進行分析的工具。

分布式數據庫的復雜度遠遠高于集中式數據庫，其最關鍵的一點就是節點和組件眾多，精細化管理眾多的節點會帶來很多問題，其中一個比較麻煩的問題就是參數管理。

對分布式數據庫而言，集群有集群的參數，每個數據庫節點，每個分布式數據庫組件也都有參數，同類的組件數量也很多，這些相同功能的組件都有完全相同的參數集，有些可以不同，有些不能不同。雖然你可以在安裝部署時盡可能使用相同的參數，但是在實際生產應用內中還是需要對參數進行調整，想要保持分布式數據庫的參數設置基本合理，其難度是很大的。

隨著數據庫上線運行、不斷擴容以及應對各種突發的問題，數據庫參數的變更會變得多起來，這些組件之間的參數可能會比較難以管理。OCEANBASE上可能有些OBSERVER的參數與大多數OBSERVER不同，從而導致這幾個OBSERVER的性能或者其他方面總是會出點小問題。GAUSSDB的某個CN節點的工作內存忘記調大了，跑在這個節點上的SQL就總是會慢一點，亦或是某個DN節點上的OS參數忘記調優了，這個節點的內存總是會換頁。

大多數分布式數據庫都有參數的白屏管理工具，不過這些工具都或多或少存在一些問題，需要人去利用工具一點點檢查參數設置是否存在問題，與真正的運維工作有很大的差距。面對數十個甚至上百個節點或組件，有些組件甚至可能有成百上千的參數，目前的國產分布式數據庫的白屏管理工具在這方面做得都不算太好。

分布式數據庫的參數分析工具需要什么功能呢？首先能夠找出所有的非默認的，被修改過的參數，詳細列出其在每個分布式組件上的值。一般情況下參數設置錯誤導致的數據庫問題都是人手工修改過的，因此我們需要對修改過的參數做重點分析。某些分布式數據庫目前還不一定具備直接找出非默認參數的能力，那么就需要定期對參數做備份，每天自動比對了。每天比對還可以找出最近變更的情況，比僅僅找出非默認參數更有價值。

如果工具做得再好點，不僅僅要找出最近修改過的參數，還要標注出這些參數是否是高危參數。我曾經和一些數據庫廠商的研發人員交流過這個問題，他們對“高位參數”或者參數的危險度分級問題也十分模糊。確實，高危參數不一定能在參數設置時搞清楚，有些高危參數是在運維實踐中才被發現出來的。雖然如此，數據庫原廠對自己的數據庫還是最了解的，是能夠標注出大量高危參數的。這項工作，OBDIAG團隊和OCEANBASE研發的同學已經在對接了。

如果這件工作再進一步，那就不僅僅是標注出高危參數，還需要找出配置不合理的高危參數，如果可能，最好能夠分析出建議配置。對于目前用戶對國產分布式數據庫的熟悉程度而言，這些工作依靠用戶的DBA還是十分困難的，如果有自動化工具支撐會相當有價值。

其次是標注出多個相同類型組件中存在差異的參數，一般情況下，一個分布式數據庫的不同服務組件中的同一個參數的設置都是類似的，當然也有些參數可能需要根據硬件環境等因素做不同的設置，存在不同的參數配置不一定就是不合理的。因此工具需要在表格中安排一列，告訴DBA這些參數的分布式環境設置策略，比如必須相同，建議相同，建議不同，必須不同等，這個標注也最好是數據庫原廠出具建議。

第三方面是對參數做個分類，比如數據庫緩存，數據庫編譯，數據庫并發，并行查詢，連接排序，RPC通訊等等。分類可以讓DBA更加明確地了解參數的大體作用。雖然數據庫廠商也在參考文檔中對參數做了解釋，但是這些解釋過于泛泛，文字也大多干澀，讓人看了摸不清頭腦。而且數據庫參數在數據庫版本升級后變化很快，而文檔不一定跟得上其節奏，因此在工具中列出參數分類與一些使用建議對運維的幫助就很大了 。

分布式數據庫參數管理方面的問題，其實已經在很多用戶現場被用戶發現了，只是大家感覺到這個方面的問題似乎不是那么緊迫，因此也沒有向數據庫廠商提出，數據庫廠商哪怕接到了用戶這方面的需求，也沒有當成比較急迫的需求來應對。實際上這方面的工作十分瑣碎，在數據庫原廠的配合下，由工具生態來完成也沒有問題，OBDIAG已經把我的這個需求放到了2.2版的實現任務里了。