共计 3729 个字符，预计需要花费 10 分钟才能阅读完成。
作者简介：罗呈祥。现就职于北京翼鸥教育科技有限公司，负责数据库相干的运维治理和技术支持工作，善于故障解决和性能优化，对分布式数据库也有深入研究。
近期，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 将来可能在社区继续发力，做好常识体系、文档建设，与用户共创立弱小的社区。
