OceanBase 4.2.1 LTS 发版 | 一体化数据库首个长期支持版本

在刚刚结束的年度发布会上，OceanBase 沿着“一体化”产品战略思路，发布了一体化数据库的首个长期支持版本 4.2.1 LTS。作为 4.0 系列的第一个 LTS 版本，该版本的定位是支撑客户关键业务稳定长久运行，我们非常认真的打磨了这个版本，目的就是为了让客户可以在关键业务负载中放心地规模化使用。

2023 年初，OceanBase 发布了面向开发者的 4.1 版本，在单机分布式一体化架构的基础上推出了大量新增功能，并且大幅提升了性能和稳定性，获得了开发者的很多好评。4.2.1 LTS 是面向 OLTP 核心场景的全功能里程碑版本，相比上一个 3.2.4 LTS 版本，新版本能力全面提升，适应场景更加丰富，有更全面的容灾解决方案。

经过 4.0.0、4.1.0、4.2.0 等多个版本的迭代打磨，新的一体化版本已经在生产环境支撑了上百个业务系统稳定运行，这些系统既包括私有化部署的环境也包括公有云环境。这些实践案例表明，使用新版本能够简化核心系统迁移的成本，提升系统的运行效率。

4.2.1 LTS 版本相比 3.2.4 LTS 版本在兼容性、性能、容灾能力、易用性等方面有大幅度提升，下文对于这些方面分别介绍其中的一些亮点，欢迎大家上手体验该版本的更多关键能力升级。

（一）Oracle 兼容性

定位于核心系统升级的 4.2.1 LTS 版本，是 Oracle 兼容性的一个里程碑版本，汇集了 OceanBase 在银行、券商、保险、运营商、电力、人社等多个行业实际业务场景中打磨出的各项兼容能力，让更多的业务场景可以利用 4.2.1 LTS 版本进行平滑应用迁移。

1. 复杂查询能力

Oracle 有较强的查询优化和执行性能，面对很多业务场景中复杂的 SQL 能高效的执行，这些是很多核心系统切换过程遇到的挑战。新的一体化版本中优化器能力有了质的提升，有了更多的查询改写能力，提升了多表 JOIN 请求的计划生成性能。执行器也有大幅度的性能提升，允许更多的算子下压操作，还引入了更多的自适应执行能力。TPC-H 和 TPC-DS 场景性能都比 3.2.4 版本有大幅提升。新版本能够大幅减少核心系统迁移遇到的复杂查询的性能挑战。

2. 存储过程

新版本对于存储过程的兼容能力也有大幅度提升，全面兼容了 Oracle 复杂数据类型，支持多维嵌套和完善的多层级联复杂数据类型访问，新增组合触发器和触发器 Order 能力支持，新增了 AnyData、AnyType 数据类型。新版本中，存储过程的编译结果支持了落盘持久化能力，大幅度优化了复杂存储过程重启的重新加载耗时。同时，系统还新增了很多 Oracle 的系统包，如 DBMS_TYPES、DBMS_XMLGEN、DBMS_SYS_ERROR 等。这些能力可以帮助业务场景更平滑地从 Oracle 迁移到 OceanBase。

3. LOB

新版本全面兼容 Oracle 的 LOB 能力，能够支持 TB 级别的 LOB 存储能力。对于 LOB 的操作也支持延迟加载，解决了 LOB 访问对于内存的依赖。4.2.1 版本同样兼容了 Oracle 操作 LOB 类型的 DBMS_LOB 包，用户通过 DBMS_LOB 包可以对 LOB 内容执行插入、更新、删除、读取等操作，更精细地实现业务需求。

4. JSON、XML

JSON 越来越多被用在各种业务中，新版本 Oracle 兼容模式也完善了 JSON 类型的支持，支持 JSON 类型的存储与查询，还支持了 Oracle 关于 JSON 新增的大部分函数如JSON_OBJECT、JSON_EQUAL等，方便在 Oracle 兼容模式中对 JSON 类型进行处理。新版本对于 XML 类型的支持也得到了进一步增强，支持了原生的XML Binary存储，能够加速XML的查询，也支持基于虚拟生成列在XML文档上建立索引。

5. Database Link & XA

相较于 3.2 版本 Database Link 只能支持跨数据库的读操作，新版本以 XA 事务能力为基础，在 Database Link 上支持了跨 OceanBase 和 Oracle 的写事务能力，也支持 OceanBase 到 OceanBase 的写事务能力。更强的 Database Link 功能的支持可以协助实际业务替换数据库过程中做得更平滑，改动更小。

（二）MySQL 兼容性

OceanBase 的 MySQL 兼容模式在之前的版本已经对 MySQL 5.7 有很好兼容能力的基础上，新的 4.2.1 LTS 版本引入了大量 MySQL 8.0 的新功能：

新增多种 SQL mode 的支持，包括 REAL_AS_FLOAT, POSTGRESQL, NO_DIR_IN_CREATE 等 13 个
新增支持十多个函数，包括 BIN_TO_UUID, CURRENT_ROLE, IS_UUID 等
触发器功能中 CREATE TRIGGER 语句支持 PRECEDES/FOLLOWS 子句定义触发顺序
公共表达式功能（CTE）支持 WITH ... UPDATE ... 和 WITH ... DELETE ... 用法
新增函数索引支持
进一步完善 INFORMATION_SCHEMA 的兼容表现

接下来聊聊很多用户都期待的 Binlog Service，很多数据生态产品都支持解析 MySQL Binlog 格式，为了让 OceanBase 更好的融入 MySQL 兼容生态，新版本新增 Binlog Service 能力，可以将 OceanBase 的增量日志转换成 MySQL Binlog 格式，并且全面兼容 Binlog 协议，当用户将 MySQL 替换为 OceanBase 时，可以继续复用 MySQL 的增量日志解析工具。

作为一体化数据库，OceanBase 也在持续提升产品的性能和性价比。不同业务会侧重于不同功能不同场景，对于性能的需求也是多方面，有些业务关注系统的极限性能，有些关注小规格机器的性价比，另一些业务会关注 DDL 的性能，还有的业务关注 AP 场景的性能。OceanBase 4.2.1 LTS 版本在这些方面都有很多性能提升和改进。

（一）TP性能

OceanBase 基于单机分布式一体化架构已经打造了单机能力可以超越单机 MySQL 的系统，新版本在各种规格下性能相比之前的版本均有较多提升，在 96 Core 机器上，sysbench 压测的性能相比 3.2.4 版本提升 9% 到 100%。新版本对于小规格有更大幅度的优化，提升比例从 51% 到 152% 不等，在 read only、insert、update 三种场景的性能都达到了 3.2.4 版本的 2 倍以上。

（二）AP性能

OceanBase 一体化数据库在分析查询场景性能有大幅度提升，在新的 4.2.1 LTS 版本中，计划优化能力、执行能力相比较 3.2.4 LTS 版本均有质的提升，以 TPC-DS 场景为例，其所模拟的决策支持场景有大量的 JOIN 操作，对于优化器和执行器都有非常大的挑战。在新版本上 TPC-DS 100G 性能是 3.2.4 版本的 2.7 倍，性能优化效果更显著。

（三）统计信息

对于分析查询场景，想要生成好的执行计划，必须要有准确的统计信息。在 HTAP 环境中，表格中的数据随着业务的运行也在不停的变化，OceanBase 4.2.1 LTS 新增了多项能力来更好的获取准确的统计信息，最终可以生成更好的执行计划。

在 4.2.1 LTS 版本中，全量的统计信息收集会在每日规定的时间窗口内进行，通过DBMS_SCHEDULER 包进行相关的设置，也可以使用 DBMS_STATS 包立即执行统计信息相关的操作。

在线统计信息收集功能是让表格在突然写入了大量数据的过程中自动维护统计信息，确保及时生成最优的执行计划。新版本中，当用户执行 CREATE TABLE AS SELECT、INSERT INTO SELECT、LOAD DATA 等语句时，在请求执行的过程中，利用原本数据迭代流程，采用增量更新的方式，对统计信息进行更新。在线统计信息收集功能，不仅能够更及时地维护统计信息，而且相比显式调用统计信息收集更轻量、更快速。

优化器动态采样功能能在 SQL 运行时收集需要的统计信息，帮助优化器生成更好的执行计划，优化查询性能。当没有可用的统计信息或者查询条件中存在复杂谓词，比如 "c1 like '%test%' "，无法用选择率计算公式进行行数估计，再加上用户明确指定开启的场景，OceanBase 会在计划生成阶段启用动态采样以获得更准确的统计信息。

（四）DDL

在业务迁移数据的开始阶段，会将业务所有的表格在 OceanBase 系统中创建出来，会有并发的建表语句执行。在汇总、清算等业务场景中，业务会在执行流程中进行 Schema 操作，例如使用 Truncate Table 清空一些计算的中间数据。

最新的 4.2.1 LTS 版本对这些场景有优化。Create Table 语句与 Truncate Table 允许并行执行，在通常的生产环境中，批量并发操作新版本性能相比 3.2.4 LTS 版本有 10 倍以上的性能提升。在优化执行效率的同时，OceanBase 依然保证了严格的并发控制，同一张表的并发Truncate Table 会串行执行，另外，如果表上正在执行修改事务，Truncate Table 语句也会等待事务结束才会执行，确保了 Truncate Table 严格的并发控制行为。

（五）旁路导入

当业务迁移到 OceanBase 时，首先面临的挑战就是把大量的数据迁移到 OceanBase 中，在新版本中，旁路导入功能可以大大加速数据导入的速度，通过让一张表格写入数据的流程绕过 SQL 引擎和事务引擎，直接按照存储引擎的格式生成持久化的数据，在很多场景下可以让导入性能提升 6 倍。旁路导入功能是一个完备的功能，有很多让使用者贴心的使用体验。旁路导入在表级别进行并发控制，正在执行旁路导入的表会与表上的其他修改事务互斥，保证数据的一致性。同一时间其他表上的操作不会受影响。旁路导入功能还适配了备份恢复和物理备库功能，新写入的数据会实时归档，也会同步到备库。所以，旁路导入功能不仅可以用在新业务加载数据的场景，日常的数据操作和运维管理也可以使用。

（一）仲裁服务

仲裁服务是专为OceanBase集群提供活性检测和容灾切换的服务。仲裁服务自身不存储用户数据，与集群内的各台机器之间只有心跳通信，带宽占用极小。

基于仲裁服务的两地三中心高可用部署方案在主城市的两中心各放置两副本，在灾备城市放置仲裁服务。集群正常工作时，主城市的四副本依然以 Paxos 一致性协议为基础进行事务日志的高可用同步，四副本的多数派为三，集群中一台机器出现故障时，不会影响集群的正常服务。仲裁服务会实时维护与主城市四副本之间的活性检测，当主城市任一中心故障时，会出现两台机器故障，仲裁服务会介入管理让另一个状态正常的中心恢复数据库的服务。基于仲裁的高可用方案在大幅度减少对于跨城网络带宽的依赖同时，依然保证了在主城市单个中心故障时服务连续性和数据可靠性，是理想的两地三中心的数据库部署方案。

同时，为了异地灾备，OceanBase 使用备集群异步同步主集群的所有数据变更。备集群对于跨城带宽的使用是弱依赖，当跨城同步的日志量超过跨城带宽时，会出现备集群同步落后的现象，不会影响主集群的服务，为业务提供更好的服务连续性。在业务高峰期过后，备集群能够利用主集群归档的日志继续日志同步，在业务低峰期将数据库的状态追赶上主集群，简化数据库的运维操作。

（二）故障恢复时间 RTO < 8 秒

OceanBase 一直以稳定可靠的容灾能力为业务的连续性提供保障，在新版本中，机器宕机时数据库的恢复时间小于 8 秒的能力，即 RTO < 8 秒。

在数据库的实际运行环境中，出现的异常情况不仅是机器宕机，还会出现网络中断、IO 异常甚至是数据库进程被中断等。另外，出现异常的也不一定是数据库机器，还有可能是路由层 OBProxy 所在服务器。异常情况的处理不仅要考虑通常 TP 业务的并发事务执行场景，也要考虑执行 DDL、数据加载等运维场景。

新版本中，我们继续完善了故障恢复能力，以用户实际遇到的多种类的异常问题作为优化目标，打磨每个模块处理异常的细节，让上述提到的各种异常情况发生时，数据库的服务都能在 8 秒内恢复，给业务提供更强的持续可用能力。

（三）租户级别物理备库

之前版本的 OceanBase 物理备库功能是集群级别的，同一个集群所有的租户必须同时是主库状态或者同时是备库状态。但是，使用 OceanBase 的用户会使用不同的租户来承载不同的业务，容灾的需求也就会以租户粒度有区别。新版本提供租户级别物理备库功能，让备库功能做到租户粒度，允许同一个集群中同时存在主库角色的租户和备库角色的租户，也就允许两个集群的不同租户互为主备，例如，A租户的主库在集群 1、备库在集群 2，B 租户的主库在集群 2、备库在集群 1。通过更加灵活的方式，可以方便用户安排更符合实际业务的容灾部署方案。

同时，新的物理备库方案在内核层面做了全新设计，解除了对于集群运行状态的依赖，备库同步只依赖归档存储中的日志即可，即使主库不存在了，也可以基于备份数据和归档日志搭建出备库，所以，只要归档日志还在，用户也不用担心主库日志回收导致的备库同步的断流风险。

（一）Auto DOP（自动选择请求执行并行度）

并行度（DOP：Degree of Parallel）用于描述请求执行时可以使用的并行资源量，是决定并行执行速度的关键参数。之前的版本需要用户在请求、Session 或表格维度指定并行度，虽然可以根据业务需求精确指定，但是却比较繁琐。为了解决手动指定并行度的不便和限制，新版本查询优化器可以在生成查询计划时评估查询需要执行的时间，自动确定是否开启并行和开启适量的并行度。这样可以避免由于手动指定并行度而导致的性能下降。

（二）外表

外表功能可以访问数据库外部的文件，直接映射成数据库内的表格进行访问并读取文件中的数据。相比较于把外部数据导入数据库后再进行分析处理，外部表直接读取外部数据文件，既方便又快速。在新版本中，OceanBase 支持文件系统的文件或 OSS 上的对象作为外表的源，支持以 CSV 格式解析外表数据。