作者簡介：羅呈祥。現就職於北京翼鷗教育科技有限公司，負責資料庫相關的運維管理和技術支援工作，擅長故障處理和效能最佳化，對分散式資料庫也有深入研究。
近期，OceanBase 社群釋出了一篇關於我們公司選型分散式資料庫的文章（戳：翼鷗教育攜手OceanBase，突破MySQL讀寫與容量瓶頸），詳細介紹了我們的選型考慮因素和對 TiDB、OceanBase 的測試對比，當然，我們最終選擇了 OceanBase。
其實，最初我們決定探索 OceanBase 時，因為對其瞭解不深，所以決定從監控系統入手，一邊研究，一邊積累經驗，監控系統的資料量也比較可觀。可以說，監控系統是一塊很好的試驗田。
我們的監控系統採用 Zabbix 方案，因為 Zabbix 業務語言與我們公司的開發語言高度一致，Zabbix server 端使用 C++ 編寫，前端採用 PHP 語言， 今天我主要分享下我們在監控系統使用 OceanBase 替換 MySQL 的經驗，包括業務痛點介紹、部署 OceanBase 時遇到的問題，以及 OceanBase 與 Zabbix 的版本相容測試、功能驗證等。
針對業務痛點選擇OceanBase
Zabbix 是一個基於 Web 介面的提供分散式系統監視及網路監視功能的企業級開源解決方案，能監視各種網路引數，保證伺服器系統的安全運營，並提供靈活的通知機制供系統管理員快速定位、解決存在的各種問題。 我們公司在最初使用 Zabbix 時，選用 MySQL 儲存資料，隨著業務量的增加，要監控的裝置和指標也越來越多，就出現瞭如下三個主要痛點。
痛點一：資料量大。 使用過 Zabbix 的人都知道，Zabbix 有兩張大表，即history_uint 和 history，用來存放監控資料。目前，我們監控系統的 history_uint 表資料增量約每天 33GB，history 表每天的資料增量約 50GB。因此，僅保留半年的資料，就非常龐大。
history和history_uint兩表每天的資料增量
痛點二：資料讀寫瓶頸。 隨著業務量的增長，系統中被監控的裝置也越來越多，監控資料的量也隨之增長，MySQL 出現單點寫入瓶頸。
痛點三：分割槽表不易維護。 Zabbix 有幾張存放監控資料的大表使用了按時間維度分割槽的分割槽表，便於資料清理，查詢，但不利於維護。
Zabbix分割槽表分割槽規則
基於上述三個痛點，相較於 MySQL，OceanBase 的優勢更加顯著。
首先，針對資料量大的痛點，透過之前我們在生產環境做的一些資料遷移測試，OceanBase 可以把業務資料壓縮至 MySQL 的 1/5 甚至 1/4，在相同規格的機器上，這樣的資料壓縮率可以支援我們存放期限更長的監控資料，一些線上資料遷移到 OceanBase 後的大小和壓縮率如下表所示。
可以看到對於不同的表，OceanBase 的資料壓縮率也不同， 綜合來看，平均壓縮率是 4.71。
其次，針對資料讀寫瓶頸這個痛點，由於 OceanBase 是基於 LSM-Tree 的分散式資料庫，因此，在資料寫入方面有天然優勢。根據生產環境規格的機器 sysbench 寫入效能測試的結果，OceanBase 的綜合寫入效能是 MySQL 的 3 倍以上。
OceanBase的LSM-Tree架構
最後，針對痛點三的分割槽表不易維護，我們也對 OceanBase 進行了測試。OceanBase 的 Online DDL 特性使它對分割槽表的維護非常平滑，不需要特定維護視窗停監控系統去做分割槽表的維護。truncate 表分割槽都是秒刪，資料清理非常方便。相比之下，MySQL 在清除分割槽的時候，不僅會鎖表，還會造成大量的磁碟I/O。
此外，我們在監控系統中選擇使用 OceanBase，也是為核心業務上線 OceanBase 積累經驗。
選型OceanBase的原因
環境準備和測試驗證
▋ 方案制定
我們計劃先使用 4 臺虛擬機器進行相容性測試和基礎功能驗證，機器規劃如下：
由於是本人申請的，所以機器名以申請人本人名字命名 -_-!
選擇部署的 OceanBase 軟體版本如下表所示。
我們的上線思路分為五步：
第一步，做相容性測試。主要測試儲存與服務的相容性，以及功能是否正常；
第二步，準備OceanBase叢集和相關元件。部署 OCP、OMS，使用 OCP 快速部署叢集；
第三步，遷移歷史資料。用 OMS 將表結構和全量資料遷移到 OceanBase 中，同時選擇增量資料同步；
第四步，開啟維護視窗。將服務資料庫連結地址更換到 OceanBase 叢集上；
第五步，清理同步鏈路釋放伺服器資源。
▋ 環境準備
我們根據官方文件部署了 OceanBase、OCP、OMS，在測試環境中也並沒有做太多規範化的配置，在匯入表結構後，使用即可。但根據我們的部署經驗，要注意 default collation 為 utf8mb4_bin。
測試叢集的拓撲圖
租戶管理介面
但我們在環境準備的過程遇到了一些問題：
第一，由於我們公司使用的 MySQL 版本是 8.0，在編譯好 Zabbix-server 後，發現連線 OceanBase 時總是失敗，而更換為 MySQL 5.7 版本的環境後編譯可以連線上資料庫，可能原因是 8.0 版本的密碼加密方式與 5.7 版本不同，這倒也不是什麼大問題。
Zabbix系統介面
第二，系統提示資料庫版本的問題。因為 OceanBase Proxy 對外顯示預設版本是 MySQL 5.6.25 ，Zabbix 會提示版本不支援，所以，需要修改 OceanBase Proxy 的 MySQL_version 引數到支援的版本，我們改成了 8.0.20 版本（ps：這個小功能不錯，可以根據需求調整到任意版本）。
▋ 功能測試
準備好環境後，我們開始功能測試與驗證，主要檢視服務執行狀態，檢查 Zabbix-server、UI 服務是否能正常啟動，以及在長時間執行後的狀態檢查，還要檢查基礎功能，包括增加監控項、資料採集，資料讀取，介面健康檢查，報警事件觸發等。此外，驗證資料遷移的一致性（OMS 自帶資料一致性校驗功能，所以只進行了抽樣檢查），以及進行 Zabbix 版本升級，agent 升級等。
在 Zabbix 6.0 版本測試過程中，各種功能正常，但在測試升級過程中（Zabbix版本從 6.0 升級到 6.2）遇到了一些問題。
- 觸發器問題：OceanBase 不支援觸發器，所有觸發器都建在 changelog 表。
- OceanBase 不支援把 text 修改為 varchar，在 4.0 版本之後支援，問題暫時擱置。
- changelog 表的問題，從程式碼上看是升級時要寫資料，使用觸發器，需要再驗證。
- Zabbix 新增機器後，重啟 Zabbix server 才能連通，這可能與程式有關，因為同一個程式，在使用 MySQL 時正常。該問題是 Zabbix 6.2 版本使用過程中的問題，比較致命，需要重點處理。
經過檢視 Zabbix 原始碼和測試驗證，我們發現以上問題的根本原因是 OceanBase 3.1.x 版本不支援觸發器。因為 Zabbix 在 6.0（LTSC）版本的表結構中，沒有使用到觸發器，而在 6.2 版本中，在一些表上建立了向 changelog 表插入資料的觸發器。
Zabbix中的部分觸發器
那麼，手動寫“外掛”實現觸發器的功能是否可行呢？我們也做了一些測試。透過對觸發器建立語句的分析，我們發現，在源表資料有變化的時候，包含 insert、delete、update，觸發器會把對應的資料插入 changelog 表。也就是說，只要訂閱表變更資訊即可。
怎樣實現源表的變更訂閱呢？這裡就可以使用 OceanBase 開源生態的重要工具——OMS。我們是透過 OMS 訂閱表的變化，把資料寫入 Kafka，然後消費 Kafka 的資料寫到 changelog 裡。透過這種方式，我們再進行功能測試，發現上述 Zabbix 的四個問題全部解決了，各種功能測試可以正常使用。
需要說明的是，在我們測試時，OceanBase 還是 3.1.4 版本，現在 OceanBase 的 4.0 版本已經發布，觸發器功能也開放了，後續我們會進行 OceanBase 4.0 版本與 Zabbix 的相容性測試，敬請期待後續分享。
選型總結與感謝
選擇 OceanBase 做 Zabbix 監控系統的底層儲存後，我們也在 Zabbix 程式碼上做了一些相容性修改，從目前的使用情況看，執行狀態良好。由於 OceanBase 使用 Paxos 協議確保主副本和從副本資料強一致，DML 操作插入、更新、刪除等首先寫入 MemTable，業務高峰期也不會出現磁碟 I/O 告警和主從延遲的情況。
目前我們已經在測試環境、線上環境上線了兩套 OceanBase 叢集，也已經在業務中使用了 OceanBase，後續會有更多業務陸續遷移到 OceanBase 中。
記得 OceanBase 在 2021 年開源的時候，我就嘗試部署過 3.x 版本，過程複雜，成功率低。 在不斷地快速迭代下，其部署變得方便，屢試不爽，再隨著生態工具（OCP、OMS、ODC 等）的釋出，OceanBase 社群版產品體系越來越完善，越來越好用。
與此同時，伴隨著 OceanBase 社群的逐漸壯大，很多社群使用者越來越活躍，他們的經驗對我們很有啟發，希望 OceanBase 未來能夠在社群持續發力，做好知識體系、文件建設，與使用者共建立強大的社群。