OceanBase 4.1部署，OCP Express体验感受

从2022年至今，我们的生产环境大量使用了OceanBase，解决了MySQL大表等业务的痛点问题。所以说我们OB 3.x版本到4.0版本都测试和部署了，今年OceanBase 4.1版本发布以后，安装包内含了白屏化和OCP Express，我们也第一时间做了测试，今天就从一个用户的角度来讲讲OceanBase 3.x版本到4.0版本的部署感受，或许还能给想了解OB的同学一些帮助。

一、OceanBase 3.0时代部署

在OB3.0时代我们主要使用OBD和OCP来进行部署。先来讲下OBD的部署。

OBD部署OB

部署OB最开始使用的就是OBD，部署的步骤如下：

• 第一步，准备一台机器作为中控机。
• 第二步，准备若干台部署OB的服务器并配置好中控机器与他们的单向互信。
• 第三步，先去网站下载一个OBD，然后修改YML文件。
• 第四步，使用OBD deploy命令去启动OB。

上图的一个YML文件，他清晰表达了我的中控机会连接3个oceanbase-ce，也就是OBServer，每个server部署相关的端口和目录，而obproxy-ce表明了obproxy需要部署的机器。图中我做了一些简化，实际情况中YML还是会在每个组件上提供一些参数的可选配置项。修改YML文件有时候多按一个键可能yml文件就不对了，排查需要很长时间。零零总总的可配置项，遇到不确认的地方，查阅文档需要较长的时间，有时候会晕头转向。

OCP部署OB

OB提供了一个航空母舰一样强大的平台，你可以在这里面添加主机并监控主机，上传并管理需要安装的软件（其中包括OB OBserver 和OBproxy），性能监控和告警应有尽有。

但是安装OCP确实对于不熟悉它的人是有一定的门槛的：

• 第一步，安装docker。
• 第二步，使用OBD部署一个OB集群。
• 第三步，修改配置文件开始部署OCP，OCP的部署的配置文件选项比OBD的那个yml文件更复杂些。
• 第四步，使用OCP接管之前OBD创建的OB集群。

整个过程有时会遇到一些小问题，探索需要消耗一天的时间。我们在安装的时候曾经碰到过一些典型问题。

Problem2：磁盘容量不够
  custom_config:
     - key: datafile_maxsize
        value: 30g

Problem2、需要配置安装失败后删除元数据库
# Clean OCP's metadb cluster when uninstall
clean_metadb_cluster: true

在拥有一个强大的平台之后我们必须了解它和外部系统之间的关系，以便在出现问题的时候能准确排查

OCP的系统结构

OCP的架构是一个典型的Master-Slave结构，最左边对应的是存储OCP的元数据库，中间是OCP Server，右边是OCP agent。添加主机的时候就会添加Agent，OB管理服务会根据你在白屏中的需求和Agent交互。除了OCP还会根据Agent上报的指标触发告警服务，并且把指标传给server，由server写入元数据库。记得如果自动化部署OCP的元数据库，这个库是在宿主机。OCP Server是在docker里面的（组件是多个组件，使用docker完整交付较为方便）。

OCP使用的感受

终于我们可以添加集群开始安装部署第一个集群了，上传软件包，添加主机，新建集群，新建租户是不是喜大普奔呀。安装第一个集群轻松后，感觉是不是还不错，至少以后安装集群都是图形化操作了。

在我们使用OCP的过程中下面这些功能给我留下了深刻的印象，比如说用户管理，集群管理，在不用登录到数据库的情况下就可以完成安全添加用户的操作。

而且作为DBA有确认的习惯，对于小心翼翼保护企业核心资产的DBA来说，再多的确认也不为过。在分布式组件或者集群多的场景中，硬件问题出现的次数就会变高，我们经常会遇到记得有一次一个三节点的集群单台机器坏掉，ocp里面还是找到了替换机器这个选项，在丝滑的替换掉当前OBserver，心里的那块石头终于落了地。

OCP的告警服务做的相当周到，可以屏蔽掉一部分非核心告警，对于部分分摊，甚至你需要静默多少小时后恢复告警，是不是很细节？

最后在补充一下生产环境中OCP的相关部署配置：

根据能量守恒定量，一个强大的东西需要消耗强大大的资源，一般一台OCP需要8 核 16G，但是为了管理多套业务不同的集群，我们至少需要32核 64G外加4TSSD的配置来存储多个集群的监控数据。业务初期考虑到迁移数据我们还需要复用机器去部署OMS，初期的时候不建议去部署三节点集群，我们这样部署是为了保证集群的健壮和高可用。

二、OceanBase 4.0时代部署

优秀的行业标杆

当年做Oracle DBA的时候，Oracle Express清晰的DashBoard给我留下了深刻的印象，下图中最上面一部分是数据库当前的状态和这段时间各种资源的情况。图片中间部分标识了资源分布的情况，每一块每种资源消耗了多少，最后一部分是Top SQL。

初见Express，年轻人的第一辆特斯拉

在OB 4.0时代，我们迎来了OCP Express，下载了OB all-in-one package之后，obd web，然后选择好机器就可以配置了，下面是obd安装的主机相关的选项。

OCP Express同样简洁优美，就像年轻人的第一辆特斯拉一样，第一次安装OCP Express我感觉是蛮震撼的，3-5分钟就部署好OB。尤其是使用了较低的资源安装OB集群后，维护的时候可以看着这么赏心悦目的仪表盘，最主要这个还开源免费。

看下图，这是Expres的第一屏，最上面它展示了集群资源使用的情况，中间两栏是租户消耗各种资源的情况。租户的合并时间通常可以用来看下数据前面一天的写入量，以及各个租户的慢SQL的总量

接着是对应的资源，每个租户cpu io 内存整个物理资源的情况，如果达到水位了就需要考虑扩容。

DBA最常见的场景

DBA在日常生活中经常遇到CPU飙高，大多数是由慢日志带来的，这时候最快使用准备好的展示慢查询，可能使用kill一顿操作，让CPU回到低水位。接着再把SQL执行计划打出来，然后看下索引走的对不对，整个过程DBA同学像开飞机遭遇颠簸到平稳落地一般酸爽。

一个系统什么样的SQL对系统的影响最大？一定是执行频率高的Top SQL，提前看执行计划是不是最优，索引有没有最优，对于高频的SQL哪怕快上1ms，对于整个系统都有较大的提升，在OCP Express中我们也可以看到这些Slow SQL，并根据执行计划对他们进行调优，解决系统当前最好资源的SQL。

OCP和OCP Express对比

很多同学会疑惑OCP 和 OCP Express到底有什么区别，从我的使用感受来看，我的总结如下：

三、期待更美好的遇见

作为一个OB的深度用户，我们也想它变得更加完美，obd如果能更加简洁一点就好，就像top命令一样直接告诉我们observer和obproxy的目录就更好了，排错的时候直接就可以ssh到对应的机器上去翻日志了，OB有提供一个OceanBase Diagnostic Tool去一键收集日志。

在体验OCP Express的过程中，我们发现它照顾到了大多数用户的核心诉求：

• ssh端口是非知名端口无法部署。
• OB往zone里面添加OBserver
• OB proxy纳管
• 告警功能提升

还有就是，OB作为一款开源分布式数据库已经为我们提供了近乎商业版本的交付，期待更好的遇见。