作者简介：罗呈祥，现就职于北京翼鸥教育科技有限公司，负责数据库相关的运维管理和技术支持工作，擅长故障处理和性能优化，对分布式数据库也有深入研究。
近期，OceanBase社区发布了一篇关于我们公司选型分布式数据库的文章，详细介绍了我们的选型考虑因素和对TiDB、OceanBase的测试对比，当然，我们最终选择了OceanBase。
其实，最初我们决定探索OceanBase时，因为对其了解不深，所以决定从监控系统入手，一边研究，一边积累经验，监控系统的数据量也比较可观，是一快很好的试验田。
我们的监控系统采用Zabbix方案，因为Zabbix 业务语言与我们公司的开发语言高度一致，Zabbix server端使用C++编写，前端采用PHP语言，今天我主要分享下我们在监控系统使用OceanBase替换MySQL的经验，包括业务痛点介绍、部署OceanBase时遇到的问题，以及OceanBase与Zabbix的版本兼容测试、功能验证等。
1. 针对业务痛点选择OceanBase
Zabbix是一个基于Web界面的提供分布式系统监视及网络监视功能的企业级开源解决方案。Zabbix能监视各种网络参数，保证服务器系统的安全运营，并提供灵活的通知机制供系统管理员快速定位、解决存在的各种问题。我们公司在最初使用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的原因
2. 环境准备和测试验证
2.1 方案制定
我们计划先使用4台虚拟机进行兼容性测试和基础功能验证，机器规划如下（由于是本人申请的，所以机器名使用了本人的名字命名 -_-!）。
选择部署的OceanBase软件版本如下表所示。
我们的上线思路分为五步：第一步做兼容性测试，主要测试存储与服务的兼容性，以及功能是否正常；第二步是准备OceanBase集群和相关组件，部署OCP、OMS，使用OCP快速部署集群；第三步迁移历史数据，用OMS将表结构和全量数据迁移到OceanBase中，同时选择增量数据同步；第四步打开维护窗口，将服务数据库链接地址更换到OceanBase集群上；第五步清理同步链路释放服务器资源。
2.2 环境准备
我们根据官方文档部署了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版本（这个小功能不错，可以根据需求调整到任意版本）。
2.3 功能测试
准备好环境后，我们开始功能测试与验证，主要查看服务运行状态，检查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的兼容性测试。
3. 选型OceanBase的总结与感想
选择OceanBase做Zabbix监控系统的底层存储后，我们也在Zabbix代码上做了一些兼容性修改，从目前的使用情况看，运行状态良好。由于OceanBase使用Paxos协议确保主副本和从副本数据强一致，DML 操作插入、更新、删除等首先写入 MemTable，业务高峰期也不会出现磁盘I/O告警和主从延迟的情况。
目前我们已经在测试环境、线上环境上线了两套OceanBase集群，已经在业务中使用OceanBase，后续会有更多业务陆续迁移到OceanBase中。
记得OceanBase在2021年开源的时候，我就尝试部署过3.x版本，过程复杂，成功率低。在不断地快速迭代下，其部署变得方便，屡试不爽，再随着生态工具（OCP、OMS、ODC等）的发布，OceanBase社区版产品体系越来越完善，越来越好用。OceanBase社区也越来越活跃，逐渐壮大，一些社区用户的经验对我们很有启发。希望OceanBase未来能够在社区持续发力，做好知识体系、文档建设，与用户共创建强大的社区。
欢迎持续关注 OceanBase 技术社区，我们将不断输出技术干货内容，与千万技术人共同成长！！！
搜索🔍钉钉群（33254054），或扫描下方二维码，还可进入 OceanBase 技术答疑群，有任何技术问题在里面都能找到答案哦～
