OceanBase替換 MySQL,如何打造更穩定的Zabbix監控系統

作者簡介：羅呈祥。現就職於北京翼鷗教育科技有限公司，負責數據庫相關的運維管理和技術支持工作，擅長故障處理和性能優化，對分佈式數據庫也有深入研究。

近期，OceanBase 社區發佈了一篇關於我們公司選型分佈式數據庫的文章（戳：翼鷗教育攜手OceanBase，突破MySQL讀寫與容量瓶頸），詳細介紹了我們的選型考慮因素和對 TiDB、OceanBase 的測試對比，當然，我們最終選擇了 OceanBase。

其實，最初我們決定探索 OceanBase 時，因爲對其瞭解不深，所以決定從監控系統入手，一邊研究，一邊積累經驗，監控系統的數據量也比較可觀。可以說，監控系統是一塊很好的試驗田。

我們的監控系統採用 Zabbix 方案，因爲 Zabbix 業務語言與我們公司的開發語言高度一致，Zabbix server 端使用 C++ 編寫，前端採用 PHP 語言，今天我主要分享下我們在監控系統使用 OceanBase 替換 MySQL 的經驗，包括業務痛點介紹、部署 OceanBase 時遇到的問題，以及 OceanBase 與 Zabbix 的版本兼容測試、功能驗證等。

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 社區版產品體系越來越完善，越來越好用。

有獎徵稿：

隨着國內數據庫等信創產品越發強大，很多社區用戶越來越活躍，期待更多用戶分享Zabbix與國產系統支持的經驗，做好知識體系、文檔建設，與用戶共創建強大的生態。