OceanBase 运维管理工具 OCP 4.x 升级：聚焦高可用、易用性及可观测性

 可视化的管控平台，对 OceanBase 这类的分布式数据库及大规模数据的运维管理来说，是提升运维效率与数据库管理水平的重要工具。OceanBase 运维管理工具 OCP 作为专为OceanBase数据库设计的企业级全生命周期管理平台，为用户提供了全面的数据库可视化运维监控能力，既能让新手迅速掌握 OceanBase 数据库的使用，也能作为DBA在生产环境中日常运维的得力助手。

OCP 4.x 在继续增强基础运维功能的同时，基于 OceanBase 内核能力、实际运维场景以及用户诉求，推出了多项场景贴合的实用性功能，希望帮助用户更高效地管理和运维 OceanBase 数据库。

一、全面提升 OceanBase 数据库可观测性

（一）全链路追踪

数据库前后端调用链路极其复杂，当业务出现超时或者性能异常问题时，用户往往难以定位问题是出在数据库内部组件还是是网络上，通常只能根据经验和日志进行分析，造成问题分析、解决耗时较长，从而影响了业务的连续性。OceanBase 4.x 在诊断能力方面有了显著提升，其中包括被誉为“排查利器”的全链路追踪功能。全链路追踪可以实现对 SQL 请求从客户端->OBProxy->OBServer 整条链路的耗时精准追踪，帮助用户快速定位具体问题发生在执行阶段、机器或功能模块，并提供相关的执行信息。

OCP 4.2.1 版本开始支持租户和会话级别的全链路追踪可视化配置，通过与 OpenSearch 配合，实现不同维度的快速检索，如按耗时检索，指定 Trace ID 或 SQL ID 检索等，直观地看到请求从客户端到数据库内部全链路各组件的执行信息，从而快速发现真正的问题点，避免不同角色相互推诿。

图 1：OCP 全链路追踪诊断能力

（二）监控大盘

在实际使用 OCP 的场景中，用户可能会遇到如下业务监控诉求：

○   OCP 默认提供的监控指标已超过 60 个，业务环境只需关注其中部分指标。

○   类似双 11 这样的业务高峰发生时，如何监控多个业务集群？

○   当多个监控指标存在关联时，如 QPS、RT、TPS 等，如何查看同一时刻的指标数据？

○   当发现某个指标暴增时，如何区分这是正常的波峰流量还是异常行为？

为了更好地解决上述监控需求，OCP 4.2.2 提供了监控大盘功能，用户可以添加多个图表来显示不同集群或租户的指标和数据，实现多对象、单个或多个指标监控视图的关联查看或多个集群的不同监控指标。同时，监控大盘支持图表联动，实现同步展示多个指标的监控数据，帮助用户更好地分析数据。此外，监控大盘提供同比、日比、周比、月比 四种监控对比方式，帮助您轻松发现数据异常。您还可以根据数据特点选择折线图、饼图、表格等七种不同的图表类型，从而更好地理解和分析数据。监控大盘还支持图表拖拽、放大、下钻（单指标场景下）等多种功能，帮助您实现对数据库系统整体性能和运行状态的全面监控，提升 OceanBase 集群的整体可观测性。

图 2：OCP 监控大盘

（三）自定义监控

当前 OCP 已经内置了 50 多个监控指标以及 180 多条告警规则，基本涵盖常见的业务场景。为了更好的满足用户在不同业务场景的定制化诉求， OCP 4.2.1 实现了自定义监控功能，支持用户根据自身业务场景定制化监控图表和告警，典型场景包括对于 OceanBase 3.x 的转储次数、分区数以及表数量监控等，方便用户通过监控或者告警及时感知系统内部变化，从而及时解决相应问题，避免对业务产生影响。

二、更加完备的数据库高可用能力

（一）租户级主备库

主备库是 OceanBase 用于避免关键型业务发生站点故障的解决方案。该解决方案能够在远端维护生产数据库的一个同步物理副本，从而以简单和经济的方式防止数据丢失和停机。如果生产数据库由于任何原因不可用，客户端连接可以迅速地故障切换至同步副本以恢复服务。

OceanBase 数据库在 4.1.0 版本之前，集群有两种角色：主集群和备集群，备集群是主集群的一个数据备份，保证事务一致性。从 4.1.0 版本开始，物理备库采用独立的主备库架构，主备关系存在于租户级别，主备之间通过网络直连或第三方日志服务建立传输渠道，只传输日志，即主或备的角色信息属于租户，分为主租户和备租户，集群不再有主备角色的概念，而仅仅是承载租户的容器。主租户是用户创建的业务租户，支持完整的数据库服务能力；备租户则仅提供容灾和只读服务的能力。

OCP 4.2.0 开始支持通过基于日志归档及基于网络进行搭建租户的主备关系，支持构建 1 主 1 备或多备和级联方式的租户级物理备库高可用解决方案。用户仅需通过主备库日常切换和主备库容灾切换即可动态改变租户角色，同时 OCP 实现展示主备延时以及提供暂停&开启同步功能，最大限度的帮助用户提升主备库的管理效率。

（二）仲裁服务

仲裁服务通过仅传递部分选举日志，在半数全功能副本故障导致日志无法达成多数派时，租户可通过仲裁服务实现自动降级来恢复数据库服务。OCP 支持为 OBServer 4.1 及以上版本对 2F 或 4F 的租户配置仲裁服务，提供仲裁服务的部署、启停、接管、删除、升级等能力，实现了对仲裁服务的全生命周期管理能力，同时基于仲裁服务低资源消耗以及支持多集群的特性: 

○   在单集群模式下，通过 N 个集群复用同一仲裁服务，用户可以至少减少 N 个全功能副本的节点配置，极大的降低集群的硬件部署成本。

○   在两地三中心部署模式下，仲裁服务可以解决两地三中心同城副本故障时 RT 变大的问题，同时可以有效降低跨城带宽开销，并降低第三机房（两地三中心部署模式）的部署成本。

总体简单来说，仲裁服务实现了 OceanBase 数据库高可用能力的“减量不减价"，使 OceanBase 数据库的高可用解决方案在成本和收益之间达到了完美平衡。

三、更加精细化的资源管控

（一）资源隔离

OceanBase 数据库是面向多租户设计，用户通过在集群层面实现了实例资源的池化，实现 DBaaS（Database as a service）平台。在 OceanBase 数据库中，每一个租户即一个实例（类似于 MySQL 实例）。租户（tenant）既是数据库对象（如表、视图、储过程等）的容器，也是资源（CPU、内存、IO 等）的容器，租户间已经进行资源隔离，保障了相互之间的访问不受影响。但如何解决单个租户内的资源管理呢？

○   当多个不同业务共享同一租户，某个业务的非预期负载上升会影响其他高优业务的正常运行。

○   当租户内存在混合负载时，对资源需求较高的数据分析或批量作业会影响在线交易类业务的 RT。

○   在某些 7x24 高可用性的业务系统中，后台任务（如数据备份、合并/转储以及 DDL 操作）可能会影响在线业务

○   大小账号或者某类异常 SQL 的运行可能造成在线业务的 RT 升高。

为此，OCP 4.2.0 基于 OceanBase 内核能力提供了精细化 资源管理的重要能力：资源隔离，通过高度精炼的方式简化用户配置难题，实现了用户级别、后台任务以及更细粒度的 SQL 级别资源隔离，满足不同场景的资源控制需要，同时支持动态调整资源隔离计划能力，如启用、停用、修改及删除资源隔离计划。在保证可用性和性能的前提下，资源隔离可以帮助用户优化资源使用效率，降低资源使用成本。

图 3：OCP 精细化管理能力演示

（二）租户间 IOPS 资源隔离

I/O 吞吐通常是数据库系统最常见的资源瓶颈，也是资源管控的最大难点之一。OceanBase 4.0 通过虚拟化磁盘带宽（IOPS）达成对最重要的 I/O 资源进行了限制，解决了不同业务租户间磁盘争用的难题，实现如同多个租户运行在多块不同的磁盘的实际效果，使 OceanBase 的租户具备业内一流的 I/O 隔离能力。OCP 4.2.1 开始支持用户在创建 Unit 时根据业务重要程度设置 IOPS，确保对应租户下所有业务请求都会受到此 IOPS 的限制，进而确保高优业务不受其他低优业务影响，保障业务平稳运行。

四、业务视角的产品优化

OCP 4.x 版本从用户视角出发，实现了 80 多项易用性方面的改进和优化，包括 900 多个产品错误码，告警中心能力和任务编排优化，以及增加产品功能和限制提示等, 帮助用户更好地管理 OceanBase 数据库和使用 OCP。OCP 4.2.2 提供了一个重要的新功能：标签。标签是 OceanBase 管理的资源（如 OceanBase 集群、仲裁服务、租户、OBProxy 集群以及主机等）进行标识的工具。标签的应用场景主要有：

○   使用标签查询资源：通过标签对资源进行标记，可以帮助用户从不同维度对具有相同特征的资源进行分类、标记和搜索，使资源管理变得更加简单。

○   使用标签作为资源的别名或者备注：当资源名称不具有业务含义时，用户可以赋予资源具有业务意义的名称，帮助用户快速识别资源的作用。

同时，标签管理提供了批量绑定、编辑以及删除等功能，使用户能够更方便、更快捷地使用标签。

五、写在最后

综上所述，OCP 4.X 在 OceanBase 数据库的可观测性、高可用、资源管控以及易用性等方面均进行了显著的优化，在基础运维和稳定性方面，该版本也取得了显著的改善：

○   基础运维方面：OCP 支持了更多的基础运维操作，包括迁出 OceanBase & OBProxy 集群 及仲裁服务管理能力，新增 OBLB/OBNDS 告警，实现了表级别恢复，支持 COS(腾讯云)/OBS（华为云） 等对象存储介质等。整体上来说，OCP 实现了对于 OceanBase 数据库基础运维操作高达 95% 覆盖度；

○   稳定性方面：我们着重优化监控收集计算逻辑以及资源使用。在银行客户实际业务场景中， OCP 4.2.2 实现稳定支持 100+ 集群，2000+ 租户， 800+ 物理机器的资源管理规模。未来，我们会继续增强基础运维能力，如统计信息管理、库&表回收站以及 Region/Zone 管理等。为了帮助用户更好的运维数据库，我们会继续增强可观测性如全链路监控，等待事件以及日志分析等，探索自动化运维如信息采集、根因分析以及预案管理等。此外，我们也会着力降低 OCP 的部署成本，如使用开源的时序数据库替代 MonitorDB 以及优化应用计算逻辑等。

面向未来，OCP 将继续朝着“简单留给客户，复杂留给自己”的产品理念不断前进，我们希望将 OCP 打造成为 OceanBase 一站式的全生命周期的管理平台。在每次版本迭代中，我们都致力于切实解决用户场景中的痛点和难点。同时，我们也希望倾听您的声音和宝贵建议，让我们一起努力让 OCP 产品更完善，帮助用户更高效地管理 OceanBase 数据库。