OB 4.2 社区版使用评估建议

无意间听说微信公众号开通了【留言功能】，上一篇文章发的时候没有留意到这个功能。为了检验一下是否真的可以，今天再发一篇个人心得，话题就是围绕 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 容器。

不管是哪种部署方法，都要接受 OB 部署最低资源要求。不同版本 OB 对资源的最低要求不一样。这个要求不是官方文档中写的那个，而是实际探索的。就说 OB 4.2，尽管 8G 内存也可以起单节点 OB 集群，但是你基本上不能指望这样上生产。我建议还是测试环境 12G内存起步，生产环境 16G 内存起步。CPU 数量不是硬性要求，即使 CPU 个数不够，OB 进程启动时通过参数 cpu_count 也可以进行 CPU 超卖。只是两个内存参数必须设置好（memory_limit 和 system_memory)。这两个参数的设置实际上是看物理内存大小而定，俗称的“看菜吃饭”。所以在不同的地方可以看到不同的参数建议。OB 进程内部有一定逻辑判断会根据服务器可用内存自行设置一些值。只是 OB 原厂很少有小内存的服务器，并不一定理解中小企业的困难。所以有时候参数默认设置并不合理（如 system_memory 如果不设置就变成 30G）。除了内存外还有数据文件和clog 日志文件参数。OB 4.x 开始，数据文件和clog 日志文件都采取预分配的设计思路了。数据文件可以设置初始大小和最大大小，clog 日志文件就指定日志盘大小。这个大小不要小于 25G 。很多人想着省空间设置为几个 G 。OB 启动的时候内部租户都不够分这个日志空间的。所以，部署 OB 前的准备工作，磁盘怎么也要准备 50G 空间。25G 给数据文件 25G 给日志文件。内存至少 12G 。不满足这个要求，新手部署 OB 大概率会失败。这个不能怪 OB 部署工具不好。OB 社区版的数据迁移问题当 OB 社区版部署好后，下一个挑战就是数据迁移。数据迁移实际包含两个问题。一个是表结构兼容，二是表数据迁移。如果是从 MySQL 迁移到 OB ，那表结构兼容性方面基本上没有问题。其他的复杂的自定义函数、存储过程、触发器可能需要看看。如果是从 ORACLE 迁移到 OB，那一些数据类型就要考虑转换问题。这个跟 OB 无关，这属于 ORACLE 到 MySQL 的功能差异决定的，可以网上搜索这方面的经验。如果是从 DB2 迁移到 OB，DB2 表结构类型跟 MySQL 其实很接近，跟 ORACLE 有不少差异。但是 DB2 的 SQL 功能又跟 ORACLE 很接近，非 MySQL 可以比。所以 DB2 迁移到 OB 更多的考虑是用企业版 OB 的 ORACLE 租户。以前有过这个总结，可以参考《OceanBase 业务数据库实践（二）── DB2 迁移》。但是如果 DB2 上业务 SQL 比较简单的话，那平迁 OB 的 MySQL 租户的可行性还是很高的。
如果是 SQLServer 迁移到 OB，表结构的兼容转换也是少不了。从类型上 SQLServer 跟 MySQL 是比较接近的，但是 SQLServer 的 SQL 功能丰富程度又是跟 ORACLE 相对比较接近（差异依然很大，T-SQL 语法独一无二）。数据库（表结构和 SQL）改造是免不了的。但是最大的困难可能还是应用。跑在 SQLServer 上的应用很多使用 .Net 程序开发的，OB 的 ORACLE 租户并没有支持 .NET 的驱动。要使用 OB 的驱动的话，基本上所有 .NET 开发的应用代码都要修改。如果是 MySQL租户，还可以把 OB 的 MySQL 租户当 MySQL，使用，应用使用 MySQL 的 .NET 驱动。这是理论分析。如果有朋友有项目经验，欢迎留言交流。这类项目迁移到 OB 的可行性很低，所以项目案例很少。接着是数据迁移问题。
数据迁移首先看业务需求能不能接受停机迁移。如果业务能停机，那使用 MySQL 的全量逻辑导出再逻辑导入到 OB 的 MySQL 中即可。现成的 MySQL 技术就可以。也可以使用 DataX-Web 迁移（本质是 DataX，参考《如何使用 DataX 在 OB 和 传统数据库之间同步数据》）。此外，kettle 也可以，还支持业务模型的自定义转换。如果业务不能接受停机迁移，那数据迁移就要分全量数据迁移和增量数据同步。使用kettle 加相关mysql增量解析产品可以实现这个，使用 OB 社区版的 OMS 也可以支持这个。增量数据同步功能很诱人，使用有很多注意事项。如表要有主键或唯一键、表的ddl、大事务等。如果期望数据同步过程顺利，就需要选一个好的时间段，以及约束一下业务在数据同步期间少做 DDL 和大批量数据更新这种事情。数据迁移还有一步切换前的全量校验功能也非常重要。业务始终是要挑个时间段停机方便做数据校验（OB 和MYSQL的数据比对）。全量校验通过后就是切换。在数据迁移方案里，最大的风险就是业务双写了 MySQL 和 OB ，这个问题会超出 OMS 的处理范畴，所以一定要严格控制业务读写 MYSQL 和 OB 的账户。切换前后要反复检查数据库上的应用链接。该杀的杀，该阻断的阻断。除了 OMS 产品外，估计就 DSG 产品对迁移到 OB 支持的更好。数据迁移还有个迁移性能问题，这个后面跟数据库的性能诊断一起说。OB 的数据库性能问题
社区版 OB 上的性能问题分三类。一类是对比验证性的。OB 数据迁移完后，一上来就来一个大表统计，然后跟 MySQL 对比性能。如果租户资源很低的情况下，这种对比对 OB 是很不利的。OB 不是这么用的。OB 有 MySQL 不具备的能力，如高可用、扩展性、复杂查询等。如果只看 SQL，那么统计 SQL 在 OB 上也不是这样写的。OB 上建议将大表统计 SQL 加并行 HINT ，建议大表做分区表设计。这种统计 SQL 本来就很慢，业务如果都是这种 SQL，业务也会很慢，所以 SQL 本身的存在性就不大合理。一个 TP 类型的业务，大部分 SQL 都要求是短平快的，OB 上这些 SQL 可能比 MySQL 快也可能比 MySQL慢，但是 OB 的并发可以很高。当然大前提还是硬件资源要符合要求。比如说 SSD 盘。
即使是 AP 类统计 SQL， OB 4.3 后完全支持列存，OB 的统计 SQL 也可以跑的更快。表数据量越大，优势相比 MySQL 越明显。详情可以参考昨天的文章《OB 4.3 列存表使用体验》。所以，如果是对比 SQL 性能。先确保 SQL 代表了业务需求并且设计合理，其次要考虑业务场景的大部分 SQL。这样对比结论才是严谨的，可靠的，有说服力的。另外一类性能问题就是数据导入或迁移性能。这种导入和迁移很慢的，有两类原因。一是导入方法和迁移方法里没有发挥并行的特点，自身设计的写入就慢（比如说单线程顺序导入），并不是数据库上慢。这个很容易分析出来。另外一类就是导入和迁移的速度很快，导致触发了 OB 租户的 CPU 或内存资源瓶颈。特别是内存，OB 租户内存写入过快会导致频繁的转储（有磁盘 IO 操作），再快就会触发写入限速。如果比这个还要快，可能就直接碰到内存不足报错了。这个问题现象可能都差不多，实际原因有很多，需要借助 OB 的监控。用 dooba 监控 或者用 OCP 监控都可以提供更多线索，有了这些线索才好分析 OB 的性能。第三类性能问题就是业务读写 OB 慢。如果开发能找到具体的 SQL，就分析 SQL 的执行计划和相关表的索引、统计信息等。如果开发不知道 SQL，就需要借助 OCP 或 OB 的sql审计视图去定位这类慢 SQL。最后还是要看 SQL 的执行计划和表索引等。基本上客户业务在 OB 上性能问题的现象和分析思路跟在传统数据库上的差不多。分析性能的指导思想、流程都差不多，不一样的只是现在换了 OB 数据库。而 OB 数据库加上 OCP ，让这种性能分析诊断更加高效、精确。

OB 社区版问题论坛反馈方法问题

使用一个新数据库肯定会碰到问题，反馈问题也需要一些技巧。这个就跟 OB 关系不大。反馈问题至少要交代问题的背景、环境和复现方法，如果可以加上自己的已有的分析。论坛上很多问题一上来就是贴个图或者日志，或者说几句碰到什么问题。其他信息全靠别人猜，或者一句一句的沟通挖掘。

问题信息量的多少对问题的分析解决带来的难度会不一样。反馈 OB 的问题至少要提供下列信息：

• OB 所在主机的操作系统、资源（CPU、内存和磁盘）。

• OB 版本，集群资源分配明细。

• SQL 性能问题包含 SQL 文本以及解析执行计划（explain）。

• 集群稳定性异常给出 集群 RS 事件记录（__all_rootservice_event_history）。

• 操作类异常问题还要给出操作步骤。

在信息反馈中，OB 的日志属于比较特别的。OB 属于分布式数据库软件，日志量非常的丰富。这个日志大部分内容是研发给自己看的，不是给用户看的。日志量有时候有点泛滥导致运行日志所在的盘 IO 都容易成为瓶颈，所以日志还有截断逻辑。此外日志还有空间问题，所以也会有循环覆盖设计。虽然 OB 也提供了 trace_id 方便去定位日志，但对于普通的用户而言，那个日志量还是非常大的，并且也不好看懂。所以个人认为，分析 OB 的日志信息属于最后没有办法的办法。大部分问题都比较常见，从 OB 的功能原理结合文档和测试基本上都能分析判断，只有在遇到 BUG 问题或者文档还不成熟的情况下才需要借助日志去分析。

OB 社区版推出 obdiag 工具方便用户一键收集日志（这个工具很好用，以后再分享经验）。可以这么说，在 OB 研发眼里，绝大部分问题看日志是肯定都能找到原因的。这属于大招，比较消耗研发精力的。所以，不建议一碰到问题就使用这个方法。

这篇文章主要就是测试一下我的公众号文章的留言功能是否有了。如果有了留言功能，文章个人观点仅供参考，欢迎交流，不喜请轻喷。最后打个小广告，招聘 OB DBA，一年以上 DBA 或数据库相关运维经验，有 OBCP 认证或有意愿有能力考 OBCP 证书。工作地点包括杭州，宁波，温州，上海。有兴趣的公众号私信联系。更多阅读请参考：

• OceanBase 独立部署高级玩法二 ：2C8G版

• OB 社区版实战之手动部署三副本集群

• OB 社区版性能监控利器 DOOBA

• OceanBase 性能诊断（一）

• OceanBase 高级认证 OBCE 认证总结

• OB 4.3 列存表使用体验

​