OB 4.2 社区版使用评估建议

数据运维 2024-04-15 穿过生命散发芬芳 手机阅读

无意间听说微信公众号开通了【留言功能】，上一篇文章发的时候没有留意到这个功能。为了检验一下是否真的可以，今天再发一篇个人心得，话题就是围绕 OB 4.2 社区版使用评估。

个人观点，不代表 OB 官方（原厂），仅供参考，不喜轻喷。

使用 OB 社区版的场景

如果客户用过 OB 企业版，业务规模很大的时候为了分担企业版成本，可以在兼容 MySQL 业务的非核心业务使用社区版。这部分客户已经接触过 OB 并有一定积累，并且有原厂技术支持，那大可以放心使用社区版。企业版跟社区版的核心原理都是一样的，有些技术问题是通用的。

如果客户没有用过 OB 企业版，想了解 OB 并试用 OB 但是当年又没有数据库预算，可以在非核心业务试用社区版。等试用 OB 积累了一定运维经验后再考虑在核心业务场景推广 OB 社区版或企业版。

如果客户计划业务上云使用云数据库 OB ，那可以开发测试环境部署 OB 社区版也了解一下 OB 。OB 原厂今年会大力做 OB 云数据库的推广，必要的售前技术支持应该会有的。

如果客户大量使用 MySQL 5.7或8.0 ，并且使用的是主从架构或 MGR 架构，并且经常遭遇主从同步中断导致修复麻烦或者从库重搭、或者遭遇 MGR 从节点同步因为数据或 DDL 或维护不当被踢出 MGR 节点进而重新修复或者重建 MGR 从节点事情，那可以毫不犹豫的评估使用 OB 4.2 社区版。就高可用、多活能力 OB 社区版能力相比 MySQL 主从和 MGR 优秀很多。当你的业务当初选择了 MySQL 而不是 ORACLE 或 SQLServer，就表示已经做过一轮风险评估（MySQL 可靠性并不非常高，业务得接受）。那么在 OB 社区版上的那点未知的风险在 MySQL 自身问题前面并不可怕。

如果客户用 MySQL 给数据仓库业务用，那建议毫不犹豫的评估 OB 社区版 4.2 或 4.3，因为 OB 适合 OLTP 和 OLAP 两种场景，没有额外的数据同步问题。能在 MySQL 上跑的数据仓库业务，在 OB 上只会跑的更好。

如果客户大量使用其他兼容 MySQL 的分布式数据库或国产数据库，其中有些是分库分表架构的 MySQL 数据库，如果业务对分库分表带来的可能的 SQL 限制、事务限制或者表结构变更问题表示难以接受，那也可以评估 OB 社区版。使用风险并不会增多，但是在 MySQL的兼容性功能、高可用能力、分布式能力、OLAP能力方面 OB 4.2 以及以后的版本只会更加优秀。

如果客户只是想找一个国产数据库做国产化项目，要求数据库跟主流国产服务器和国产系统兼容，也可以考虑 OB 社区版。虽然业务迁移的改造成本上 OB 社区版并不一定是最少的，但是 OB 社区版的功能以及发展前景确实最大的。

以上评估 OB 的使用建议主要是对比多个选择的风险的大小做出，是战略上的决策建议。战术上使用 OB 社区版还是会面临很多实际的困难、挑战。OB 功能很强大，但要用好也不是那么容易的。下面一一解释。

OB 社区版的部署问题

OB 社区版论坛（https://ask.oceanbase.com/）上经常可以看到很多部署问题。OB 社区版从 2.2 到 3.1 到 4.2 ，部署方法多得一只手都快数不过来了。至今还是有很多新用户在 OB 部署上碰到问题。

先总结一下 OB 社区版的部署方法有哪些。

  • 使用 OB rpm 包手动部署。包括节点的启动、集群的初始化、租户资源的分配和创建。掌握了这个方法，其他所有部署方法的问题都可以自己分析解决。这个技术难度并不高，可以参考《OB 社区版实战之手动部署三副本集群》。不同版本在启动参数会有些变化，其他原理相通。

  • obd 软件自动化部署 OB 。obd 软件的定位是自动化部署 OB 以及相关产品。obd 把 OB 集群部署初始化的逻辑自动化了。由于 OB 部署要指定不少参数，obd 接受一个参数文件。参数很多，文件的书写有一定难度。此外，对于已经部署好的集群，再次变更参数或节点规模等，obd 不得不引入更复杂的参数文件逻辑。学会用 obd 也有一定难度。尽管如此，有 obd 比没有 obd 还是要好，有不少用户通过 obd 学习 OB 运维 OB 。

  • oceanbase-all-in-one。实际上是部署 ocp-express 加一个 OB 集群。ocp-express 是 ocp 的精简版，也要元数据库，这个元数据库就放在这个 OB 集群里，会占用少量资源。这个 OB 集群的剩余资源就给业务使用（业务创建独立的租户）。这个部署有 web 界面，界面上的参数引导做得比较友好，所以成功率比 obd 要高出很多。其实 ocp-express 的部署原理就是 web 界面根据用户选择自动生成 obd 的配置文件，然后 后台 obd 根据参数文件运行对应任务。

  • ocp-all-in-one 。这个是社区版的 ocp。其功能是企业版 ocp 的子集。企业版 OB 由于兼容 oracle 和 mysql，社区版 OB 只兼容 mysql，所以社区版的 ocp 在 OB 运维功能上就不包含 oracle 租户的运维。除此以外大部分功能都会一样（目标是这样的）。尽管 OB 也鼓励发展第三方生态，在 OB 的自动化运维诊断平台上，目前依然是 ocp 做的最好。毕竟目前还是 OB 自己的产品研发最懂 OB 内核以及能拿到第一手的 OB 内核规划和得到内核技术支持。社区版的 ocp 也有自己的元数据库，是独立的 OB 集群。社区版的 ocp 跟企业版的 ocp 型态区别就是社区版的 ocp 就是一个 java 进程，而不是 docker 容器。社区版 ocp 部署好后，再通过 ocp 部署独立的业务 OB 集群。这里非常不建议业务把数据库放在 ocp 元数据库 OB 里。因为 ocp 是管理业务 OB 集群的，如果业务 OB 集群同时也是 OB 自己的元数据库，这在管理上就有个悖论了。

  • obshell。OB 近期的版本推出了一个特别的命令 obshell，这个命令看起来可以做多节点的进程通信，估计用意也是用来部署 OB 集群。个人很看好这个命令，第三方生态运维可以考虑集成。目前 OB 官方还没有给出这个命令详细使用文档（当前版本功能还不丰富且有些问题）。

  • k8s 上部署 OB 。这个是第三方主导的。如果客户对容器使用很有经验且 IT 平台已有 k8s 技术积累，可以考虑。

  • OB docker 容器。早期 OB 社区版为了探索部署推出的一种使用方法。当初 docker 内存至少 12 G ，是这个方法推广的一个困难。此外，docker 容器里的 OB 实际上使用的 obd 命令部署的。由于现在 OB 对内存的要求越来越低，小内存（8G）部署 OB 也成为可能，以及 obd 、ocp-express、ocp 的发展，这个 OB docker 容器的部署方法就没有什么优势和必要了。早期我也做过一个 OB docker 容器，感兴趣的可以了解《OB 社区版实战之 Docker 体验》。如果客户有 docker 技术积累，并且想将 OB 纳入 docker 技术体系中，那可以自己基于 OB 的其他部署方法去构建一个 docker 容器，而不要直接去使用 OB 提供的 docker 容器。