本文來自OceanBase 用戶的實踐分享

隨著OceanBase數據庫應用的日益深入，數據量不斷攀升，單個表中存儲數百萬乃至數千萬條數據的情況變得愈發普遍。因此，部署專門的運維工具、實施針對性的表性能優化策略，以及加強指標監測工作，都變得更為重要。以下為基于我們的使用場景，所采取的一些部署和優化措施分享。

一、OCP部署升級

1．OCP升級

（1）4.2.1BP1升級到4.2.2，本來以為毫無波瀾但是下載完畢一鍵包并完成前期準備工作啟動后發現無法登錄OCP的服務器了，后臺查看日志發現提示需要更新一下admin用戶的權限，有小伙伴后續如果遇到密碼正確就是無法通過監測的時候需要注意查看一下是不是提示admin賬戶權限不足使用echo "admin ALL=(ALL) NOPASSWD:ALL" >> /etc/sudoers更新一下權限設置應該就好了。

（2）OCP升級進入系統以后系統自動更新ocpAgent代理工具但是，這個版本跟4.2.1一樣存在ocpAgent安裝異常（OCP升級服務于本服務在一個設備情況下ocpAgent會報stat /home/admin/ocp_agent/pkg_store/ocp-agent-ce-4.2.1-20231208144448.el7.x86_64.rpm: no such file or directory解決方案也比較簡單直接復制這個文件到這個位置即可重試）

（3）隨后是升級OBProxy集群節點到最新版本，一切都順利完成后開始測試相關告警功能和測試新增的監控大盤功能和之前提交的（UI錯位等問題的解決情況），測試后發現UI問題已經基本解決完畢，發現了一處新的UI問題已經提交。

2．ES部署及OCP接入

為了讓日志能進行鏈路查詢記錄，需要部署ES和OpenSearch，使用docker按照官網教程部署了OpenSearch和ES并配置相關信息后重啟OCP即可接入，接口查看ES的記錄情況發現均無異.（配置地址：https://www.oceanbase.com/docs/common-ocp-1000000000584788）

二、警告配置和一些異常處置/性能優化

（1）部署完畢后第一個告警就是時間不同步，但是我通過chrony測試發現一切正常，ocpAgent查看監控數據NTP時鐘便宜數據也是正常范圍。

（2）將該問題以及相關日志提交到問答論壇后很快就有相關專業工程師解答并提出測試說明，通過測試發現Debian系列系統存在clockdiff在sudo下權限不足的問題，回復為已知問題，正在修復。于是聽取建議我將這個告警進行了屏蔽。

（3）性能異常警告：當天晚上發現一個“SQL 巡檢，SQL 性能下降”的問題，一早通過OCP查看后發現是一個SQL存在超過平均查詢時間較多的情況的一個告警。但是點擊SQLID無法跳轉到SQL詳細信息頁面，查看F12發現不存在該資源。

（4）黑屏問題定位：通過黑屏模式查詢[select svr_ip, plan_type, elapsed_time, AFFECTED_ROWS, RETURN_ROWS, tx_id, usec_to_time(REQUEST_TIME), substr(query_sql, 1, 10000) from gv$ob_sql_audit where sql_id='B7A34188E00F96CA660B2D39A3968328' ?order by elapsed_time desc limit 10;]找到了對應ID的SQL情況，使用該SQL到OCP對應租戶的SQL診斷工具中搜索該SQL前部分關鍵詞就獲得了對應SQL請求信息。

（5）性能優化：通過查看索引情況以及字形情況以及針對SQLID進行鏈路查詢發現了部分字段沒有命中索引以及根據優化建議發現索引建立不足以及表設計不合理的三個問題。針對索引問題重新建立了索引。針對表設計不合理主要體現在當前表單為超大型表，數據量過千萬，但是沒有進行分區設計，也沒有進行分段設計導致數據檢索存在掃表情況，于是針對當前表進行了功能拆分劃分了歷時數據和熱數據，歷時數據清理到歷史表并做分區處理，熱數據存留當前表保障當前業務。

（6）SQLID無法連接異常提交：通過本次性能優化發現告警部分的SQLID無法被定位到SQL詳情，通過后續查詢后發現URL的[/diagnosis/1/realtime/2]這個部分應該為對應的集群和租戶在當前環境下位[/cluster/1/tenant/2]修改后即可定位到SQL詳情，發現該問題后就將相關問題通報到官方相關人員進行記錄。

三、基于obdiag的一些集成化開發和暢想

1．obdiag是一個敏捷測試工具是ob官方的一個有效的集群日志收集和巡檢的工具，在工作中可以提供異常建議以及指定腳本巡檢等功能，在我的日常工作中也充當著重要的伙伴角色。

2．但是obdiag只有本地黑屏執行，配置文件也比較麻煩且報告也是用符號構成的，針對核心運維還好但是不可以進行任務分發到不同員工進行巡檢基于該需求，我們計劃開發一套帶權限管理支持多人巡檢，支持報告轉換為Json并可視化的一套工具用于輔助多人運維的場景。

3．目前實現：

（1）已經完成報告的Json序列化實現，通過Go語言已經完成了報告的解析工作

（2）數據結構：

 type Table struct {TableName stringColRows   []TaskReport
}type TaskReport struct {Task       stringTaskReport string
}

（3）報告解析：

 func parseTable(input string) ([]Table, error) {lines := strings.Split(input, "\n")var table []Tablefor _, line := range lines {// 檢查是否是表頭行或分隔行if strings.HasPrefix(line, "+") {continue}// 按分隔符 "|" 分割cols := strings.Split(line, "|")if len(cols) < 3 {continue // 如果不是數據行，跳過}taskName := strings.TrimSpace(cols[1])taskReport := strings.TrimSpace(cols[2])// 如果是表名行，創建一個新的表if taskReport == "" {table = append(table, Table{TableName: taskName,})continue}// 如果是表頭行，跳過if taskName == "task" && taskReport == "task_report" {continue}// 將提取的數據添加到切片中table[len(table)-1].ColRows = append(table[len(table)-1].ColRows, TaskReport{Task:       taskName,TaskReport: taskReport,})}return table, nil
}

（4）通過上述方法我們成功實現了數據解析工作，后續將結合gin框架等一些框架實現數據入庫和可視化操作并實現可視化腳本以及可視化巡檢執行和可視化報告解析。

（5）秉承著OB社區氛圍建立本項目在完成基本功能后將全面開源到Github并在社區進行發布。

四、一些OceanBase的使用感想和未來期待

1．OB是國產開源分布式數據庫性能和部署以及開源社區氛圍最好的選擇，這也是我們正式項目的選擇，在我們公司的CRM項目中已經穩定運行并使用了一年時間，其中版本從3.xx升級到現在的4.2.1BP4每一次升級都能感受到團隊的努力付出以及聽取社區的各種建議意見。

2．有濃厚的社區氛圍才能使得一個開源產品能夠有生命力，才能催生企業產品有更多的價值，相信OB在未來的道路上能越走越遠。我們也愿意陪著OB一起成長，為社區添磚加瓦貢獻自己的力量和智慧。

3．未來我們將引入更多系統接入到OB集群，計劃將ERP系統以及其他管理業務系統引入OB并優化集群建立方式加強閃存集群的建設以及加強OOS二次備份的規則利用多一次的機會保障系統穩定安全。