其实,最初我们决定探索 OceanBase 时,因为对其了解不深,所以决定从监控系统入手,一边研究,一边积累经验,监控系统的数据量也比较可观。可以说,监控系统是一块很好的试验田。
我们的监控系统采用 Zabbix 方案,因为 Zabbix 业务语言与我们公司的开发语言高度一致,Zabbix server 端使用 C++ 编写,前端采用 PHP 语言,今天我主要分享下我们在监控系统使用 OceanBase 替换 MySQL 的经验,包括业务痛点介绍、部署 OceanBase 时遇到的问题,以及 OceanBase 与 Zabbix 的版本兼容测试、功能验证等。
痛点二:数据读写瓶颈。随着业务量的增长,系统中被监控的设备也越来越多,监控数据的量也随之增长,MySQL 出现单点写入瓶颈。
痛点三:分区表不易维护。Zabbix 有几张存放监控数据的大表使用了按时间维度分区的分区表,便于数据清理,查询,但不利于维护。
基于上述三个痛点,相较于 MySQL,OceanBase 的优势更加显著。首先,针对数据量大的痛点,通过之前我们在生产环境做的一些数据迁移测试,OceanBase 可以把业务数据压缩至 MySQL 的 1/5 甚至 1/4,在相同规格的机器上,这样的数据压缩率可以支持我们存放期限更长的监控数据,一些线上数据迁移到 OceanBase 后的大小和压缩率如下表所示。
可以看到对于不同的表,OceanBase 的数据压缩率也不同,综合来看,平均压缩率是 4.71。
其次,针对数据读写瓶颈这个痛点,由于 OceanBase 是基于 LSM-Tree 的分布式数据库,因此,在数据写入方面有天然优势。根据生产环境规格的机器 sysbench 写入性能测试的结果,OceanBase 的综合写入性能是 MySQL 的 3 倍以上。
最后,针对痛点三的分区表不易维护,我们也对 OceanBase 进行了测试。OceanBase 的 Online DDL 特性使它对分区表的维护非常平滑,不需要特定维护窗口停监控系统去做分区表的维护。truncate 表分区都是秒删,数据清理非常方便。相比之下,MySQL 在清除分区的时候,不仅会锁表,还会造成大量的磁盘I/O。
此外,我们在监控系统中选择使用 OceanBase,也是为核心业务上线 OceanBase 积累经验。
▋ 方案制定
我们计划先使用 4 台虚拟机进行兼容性测试和基础功能验证,机器规划如下:
* 由于是本人申请的,所以机器名以申请人本人名字命名 -_-!
我们的上线思路分为五步:
第一步,做兼容性测试。主要测试存储与服务的兼容性,以及功能是否正常;
第二步,准备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 版本不同,这倒也不是什么大问题。
第二,系统提示数据库版本的问题。因为 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 表插入数据的触发器。
那么,手动写“外挂”实现触发器的功能是否可行呢?我们也做了一些测试。通过对触发器创建语句的分析,我们发现,在源表数据有变化的时候,包含 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 未来能够在社区持续发力,做好知识体系、文档建设,与用户共创建强大的社区。