Skip to content

Releases: oceanbase/oceanbase

v4.1.0_CE_BP1

12 May 05:19
@Fireatoms Fireatoms
v4.1.0_CE_BP1
bd50a54
Compare
Choose a tag to compare
v4.1.0_CE_BP1

Version information

Information Description
Release date May 12, 2023
Version V4.1.0_CE_BP1
Commit number bd50a54
OBServer RPM version oceanbase-ce-4.1.0.0-101000022023050809

About this version

This version fixes some bugs and improves stability.

Fixed issues

Notes

OBD V2.1.0 and later support the upgrade of OceanBase Database from V4.0.0 to V4.1.0.

版本信息

项目 描述
发布日期 2023-05-12
版本号 V4.1.0_CE_BP1
Commit 号 bd50a54
OBServer RPM 版本号 oceanbase-ce-4.1.0.0-101000022023050809

发版目的

本次发版主要是 BUG 修复，提升版本稳定性。

缺陷修复

注意事项

OBD V2.1.0 版本开始支持将 OceanBase 数据库社区版从 V4.0.0 版本升级至 V4.1.0 版本。

Assets 26

v3.1.5_CE

19 Apr 12:09
@Fireatoms Fireatoms
v3.1.5_CE
6d73a67
Compare
Choose a tag to compare
v3.1.5_CE

版本信息

信息 描述
发布时间 2023-04-19
版本号 V3.1.5
提交号 6d73a67
OBServer RPM 版本号 oceanbase-ce-3.1.5-100000252023041721

概要说明
间隔十余月，OceanBase 迎来了社区版 V3.1.5 版本的正式发布。该版本着重提高内核稳定性，特性上 OBKV 支持了基于热 key 的限流，OBCDC 通过架构优化降低了对使用者机器的资源要求。同时为满足用户对大宽表的期待，将单表列限制从 512 列优化提升至 4096 列。针对用户反馈及内部测试发现的问题，该版本也重点进行了修复。

特性更新

多模数据库（OBKV）支持基于热 key 的限流
新增支持多模数据库（OBKV）基于热 key 的限流功能。增加限流阈值设置，通过统计当前 QPS 最大的 K 个 rowkey 是否超过阈值决定是否执行限流。采用平滑的分梯度部分限流方案，避免简单粗暴切断流量对业务的影响。支持 tableapi 及 hbase 操作。核心能力如下：

  • 新增租户级配置项 kv_hotkey_throttle_threshold：指示OBKV限流阈值。当阈值为0时表示限流功能关闭；阈值大于 0 时，在一个epoch（2秒时间区间）内，访问数大于该阈值的 rowkey 会考虑在下一个 epoch 中被限流。取值范围为 [0, 1000000000000000000L] ，默认为0。
  • 新增虚拟表 __all_virtual_kv_hotkey_stat：用于记录被限流的 topK hotkey。
  • 新增视图 [G]V$OB_KV_HOTKEY_STAT：用于查看 topK hotkey 信息。系统租户下可查看所有租户信息，普通租户下只能查看本租户信息。GV$OB_KV_HOTKEY_STAT 可查看所有 server 上的信息，V$OB_KV_HOTKEY_STAT 只能查看本 server 上的信息。

同步链路系统（OBCDC）架构优化
早期 OceanBase 同步链路系统（OBCDC）对使用者的机器性能（内存大小/磁盘性能）要求比较高，V3.1.5 社区版本优化了 OBCDC 架构，减少内存使用，降低资源依赖，提升性能与稳定性。

单表支持列数上限从512提升至4096列
OceanBase将单表支持列数上限提升至4096列，通过大宽表设计，减少多表间的关联操作，提高该场景下数据库查询性能和数据处理能力。

  • 特别说明：有主键表可以支持指定 4096 列，无主键表因系统生成隐藏主键会占用 1 列，用户只可以指定 4095 列。

CLOG 日志文件支持按绝对值限制存储空间
早期 OceanBase clog 日志文件的存储空间阈值仅支持按照磁盘空间百分比进行限制，缺少直观性；同时对于部分共享存储，也无法准确表达使用空间水位大小。V3.1.5 社区版本在之前设计的基础上，支持使用空间绝对值限制的方式，替换固定磁盘规格限制，更灵活和易用。

  • 新增集群级启动配置项 log_disk_size：用于控制单台 observer 存储 clog 日志文件的最大空间使用量。取值范围 [0G, +∞)，默认“0G”，表示以磁盘总空间为准。当 log_disk_size 配置为负数或者配置大于磁盘总空间时，会造成 observer 初始化失败。参数可修改，但需要重启 observer 才生效。
  • log_disk_size 配置大于 0 时，磁盘使用上限由“磁盘总容量 * 可用百分比配置”变更为“log_disk_size * 可用百分比配置”。

新增支持 default_storage_engine 系统变量
为了方便 python django 框架适配，新增支持 default_storage_engine 系统变量，默认“OceanBase”。

行为变更

  • 租户级配置项 undo_retention 默认值从“0”变更为“1800”，表示转储中默认保留 1800 秒的多版本数据。

问题修复
（1）修复约束名为空时未查重，导致出现重名约束进而导致刷 schema hang 住的问题。
（2）修复合并时卡住，报错 buffer not enough 问题。
（3）修复恢复租户时，clog 回放卡住问题。
（4）修复强制取消备份失败，备份状态一直为 stopping 的问题。
（5）修复 FULL 副本偶然出现 replica is not readable，查询耗时高的问题。
（6）修复 backup zone 耗时过长导致数据备份失败的问题。
（7）修复 add partition 时，sql 卡住的问题。
（8）修复执行 6 亿数据的存储过程，导致内存不足，kvcache清理不掉的问题。
（9）修复 insert ... on duplicate key update 语句报 5024-重复主键的问题。
（10）修复 observer.log 日志有大量 Fail to erase key from cache 报错的问题。
（11）修复 slog 回放报错导致备库重启失败的问题。
（12）修复 R 副本切换 F 副本失败的问题。
（13）修复扩容 datafile_size 后，部分 server 不生效的问题。
（14）修复 insert into ignore 执行出现卡住的问题。
（15）修复 JSON 生成列创建索引内存爆的问题。
（16）修复开启 schema history 回收后，可能导致物理恢复失败的问题。
（17）修复备份恢复后，索引状态不符合预期的问题。
（18）修复恢复中的租户开启归档失败的问题。
（19）修复开 ps 后，select NULLIF(NULL, '') from dual 返回 4016 的问题。
（20）修复自动清理任务正常调度时，预期被清理的 backup_piece 未删除的问题。
（21）修复只读视图不支持读取后写入其他表的问题。
（22）修复 replace into 多条数据到混合字符集的表，查询数据有乱码的问题。
（23）修复 json 类型转换为 int 类型失败的问题。
（24）修复 from_base64() 的参数为换行符、制表符时，与 mysql 不兼容的问题。
（25）修复 sql 改写时丢失 hint 的问题。
（26）修复当备份清理任务在 doing 阶段发生切主时，切主后继续清理任务可能会报 4016 问题。
（27）修复 select udf 后 group by having聚合函数嵌套里用 select 调用形参 udf , 系统无法识别传参字段的问题。
（28）修复同样 sql 执行计划有差异导致返回结果不一致的问题。
（29）修复 PL 中游标使用 ROWID 别名触发 ORA-00904: invalid identifier 报错的问题。
（30）修复几类特殊场景下节点出 core 的问题。

Assets 18

v4.1.0_CE

20 Apr 10:23
@Fireatoms Fireatoms
v4.1.0_CE
0765e69
Compare
Choose a tag to compare
v4.1.0_CE

Version information

Information Description
Release date 2023-04-20
Version V4.1.0.0
Commit number 0765e69
OBServer RPM version oceanbase-ce-4.1.0.0-100000202023040520

About this version

We further enhanced the stability of OceanBase Database in OceanBase Community Edition V4.1.0.0 based on the valuable feedback of our community users. Check the following for more details.

Fixed issues

  1. Fixed the issue where stack overflow would occur when the operating system page size is set to 64 KB
  2. Fixd the disconnection issue caused by the lack of updating session active time in the response logic of COM_PING
  3. Fixed the issue where backup statistics was not accurate
  4. Fixed the issue of failing to read the lob data length caused by the upgrade from version 4.0 to version 4.1
  5. Fixed a backup failure issue which occurred when many empty tablets exist
  6. Fixed the issue of memory leak caused by the ModulePageAlloc module

Notes

  1. OBD V2.0.0 does not support the upgrade from OceanBase Database Community Edition V4.0 to OceanBase Database Community Edition V4.1.
  2. OCP V4.0.3_CE now supports the upgrade from OceanBase Database Community Edition V4.0 to OceanBase Database Community Edition V4.1.

版本信息（V4.1.0）

项目 描述
发布日期 2023-04-20
版本号 V4.1.0.0
commit号 0765e69
OBServer RPM 版本号 oceanbase-ce-4.1.0.0-100000202023040520

发版目的

本次发版主要是BUG修复，提升版本稳定性。

BUG 修复

  1. 修复操作系统page size为64k场景下可能触发的爆栈问题
  2. 修复COM_PING响应逻辑里，没有更新session active time导致的断连问题
  3. 修复CDB_OB_BACKUP_SET_FILES表中OUTPUT_BYTES统计不准确问题
  4. 修复4.0升级4.1后，lob数据读取长度失败问题
  5. 修复空tablet数量较多时的备份失败问题
  6. 修复500租户ModulePageAlloc模块占用过高导致内存爆问题

注意事项

  1. OBD V2.0.0暂不支持4.0 observer升级4.1 observer
  2. OCP V4.0.3_CE开始支持4.0 observer升级4.1 observer
Assets 26

v4.1.0_CE_BETA

23 Mar 13:34
@Fireatoms Fireatoms
v4.1.0_CE_BETA
0265dfc
Compare
Choose a tag to compare
v4.1.0_CE_BETA

OceanBase 数据库社区版 V4.1.0

项目 描述
发布日期 2023-03-20
版本号 V4.1.0.0
OBServer RPM 版本号 oceanbase-ce-4.1.0.0-100000192023032010

OceanBase 数据库 V4.0 社区版本是对分布式数据库系统架构设计的全面升级，OceanBase 数据库 V4.1 版本面向公有云&开源用户场景需求，在对功能健全优化的同时，不断对产品进行打磨和完善，在对 MySQL 8.0 兼容、性能、易用性、成本方面进行优化增强，目标支持项目规模化复制，是真正可全面商业化推广的版本。

版本概要

本版本的核心能力特性如下：

  • 功能增强。

    支持 SQL 级资源隔离，租户级 IOPS 隔离优化，支持 Latin1 字符集等。

  • MySQL 兼容性增强。

    MySQL 8.0 版本系统函数、变量和 SQL MODE 系统化完善，支持 GIS 数据类型。

  • 性能提升。

    • TP 性能优化。

      • SYSBENCH 性能模型，综合读写性能（Read Write）1024 并发测试性能相比于 V4.0 版本提升约 40%。
      • TPCC 性能模型，tpmC (NewOrders) 1000 warehouse 测试性能相比于 V4.0 版本提升约 8%。

    • AP性能优化。

      • TPCH 查询性能优化，100GB 数据量顺序执行 22 条 SQL，整体性能相比于 V4.0 版本提升约 17%。
      • TPC-DS 查询性能优化，100GB 数据量顺序执行 99 条 SQL，整体耗时约 161s。

    • 数据导入性能优化，在 c6a.12xlarge 规格（48vCPU，96GB 内存）机器上使用旁路导入 LINEITEM 表（74GB），单 OBServer 节点导入速率可以达到 165MB/s。

    • 基于 OBProxy 的分布式事务路由优化，提升分布式事务性能。

    • 其它性能优化：Nest Loop Join 算子性能优化、Index Skip Scan 执行优化、Truncate Table 并行执行优化、 编译反馈优化。

  • 稳定性增强。

    扩展支持 LOB 存储规格上限。

  • 高可用增强。

    支持基于归档日志的物理备库，支持更多场景达成 RTO 时间降低到 8s 以内。

  • 运维能力提升。

    • 支持 4.0 系列版本在线升级。

    • 实时统计信息收集。

    • 日志系统与可读性优化整改。

    • 持久化与存储优化：自适应合并（Compaction）、小表空间优化等。

  • 产品形态。

    发布单机产品形态。

特性更新

功能增强

  • 支持 SQL 级资源隔离。

    在实际项目交付中我们发现，客户业务希望能够对资源隔离进行更细微的控制，比如某个用户执行不同 SQL 使用不同的资源规格进行隔离（同一个租户下不同 user 的资源隔离、user 执行的不同 SQL 使用不同的资源），通过这种细粒度的应用方式帮助业务分配和隔离资源（通常为 OLAP 和 OLTP 业务的资源），减少业务之间的互相影响。

    OceanBase 数据库 V4.1 版本支持创建资源组，支持绑定用户与资源组，后续用户在执行的业务 SQL 时，OceanBase 数据库根据预定义的 SQL 规则匹配相应的资源组，通过使用 DBMS_RESOURCE_MANAGER 系统包帮助用户自定义业务资源隔离方案策略，当前该资源隔离方案仅支持 MySQL 模式下对 CPU 的资源隔离。

  • 租户级 IOPS 隔离优化。

    OceanBase 数据库 V4.0 版本开始支持租户级 IOPS 隔离，通过在租户间按照 Unit 划分和租户内按照 IO 类别（category）划分的二级方式，可以基本保证租户内的不同任务只使用分配好的资源而不会挤兑其他任务，但同时也存在其他一些问题，例如 1）固定的 IO 类别不能支持用户根据任务作业定制，2）同一租户下的不同用户无法再进行资源隔离。因此我们将 IO 资源与 CPU 资源一样纳入到 Resource Manager 框架，实现用户界面统一的资源隔离体系。

    OceanBase 数据库 V4.1 版本通过 DBMS_RESOURCE_MANAGER 系统包来支持用户自定义 IO 资源隔离策略，通过在包函数 CREATE_PLAN_DIRECTIVE 设置 MIN_IOPS、MAX_IOPS 和 WEIGHT_IOPS 参数来设置隔离计划，IOPS 隔离方案同时支持 Oracle 租户与 MySQL 租户。

  • 支持 Latin1 字符集。

    随着 OceanBase 数据库社区用户和海外客户数目的增多，越来越多的项目提出了 Latin1 字符集的需求，希望可以在数据库层面进行支持从而避免项目迁移过程中复杂的字符集转换工作。因此 OceanBase 数据库在 V4.1 版本对 Latin1 字符集进行新增支持，同时在 MySQL 模式支持 latin1_bin&latin1_swedish_ci 字符序，在 Oracle 模式下支持 latin1_bin 字符序。

MySQL 兼容

  • MySQL 8.0 兼容，系统函数、变量和 SQL MODE 系统化完善。

    OceanBase 数据库 V4.0 及之前版本已经兼容了 MySQL 5.7 的大部分功能，但随着 OceanBase 数据库在公有云和社区上有了更多 MySQL 资深使用客户，其业务系统对 MySQL 8.0 存在特性依赖这个矛盾诉求愈加强烈。同时考虑到 MySQL 8.0 版本发布已有六七年时间，其版本特性也足够成熟。OceanBase 数据库从 V4.1 版本开始对 MySQL 8.0 能力进行系统化兼容支持，V4.1 版本主要包括如下：

    • 系统函数
      • 字符运算函数：BIN_TO_UUID() 、CHARACTER_LENGTH() 、LOAD_FILE()、IS_UUID() 、UUID_TO_BIN() 、OCTET_LENGTH()。
      • 时间日期函数：ADDTIME()、DAYNAME()。
      • 加解密函数：DECODE() 、DES_DECRYPT()、DES_ENCRYPT() 、ENCODE()、ENCRYPT()。
      • Perf 信息函数：FORMAT_BYTES() 、FORMAT_PICO_TIME()。
      • 信息函数：CURRENT_ROLE() 、ICU_VERSION()。
      • 窗口函数：BIT_AND()、BIT_OR()、BIT_XOR()。
      • 其他函数：NAME_CONST()。
    • SQL Mode
      • 独立SQL Mode：REAL_AS_FLOAT、TIME_TRUNCATE_FRACTIONAL。
      • 组合 SQL Mode：ANSI、DB2、MAXDB、MSSQL、ORACLE、POSTGRESQL、TRADITIONAL。
    • Information Schema
      • 视图兼容性：视图字段没有变化，字段类型或宽度或约束有兼容性调整。如VIEW_TABLE_USAGE、VIEWS、TABLES、STATISTICS、ENGINES、TABLE_CONSTRAINTS、REFERENTIAL_CONSTRAINTS、CHECK_CONSTRAINTS、PARAMETERS、ROUTINES、PARTITIONS 等。
      • 性能提升：基于本地表索引，普遍提升系统视图查询性能，如 STATISTICS 等。
    • Float(m, d)：完全兼容 MySQL 8.0 数据类型与精度。

  • 支持 GIS 数据类型。

    空间信息系统（GIS）提供了对空间对象（点、线、面以及复杂的空间对象）的存储、计算、索引能力，在交通出行行业有着广泛的应用，可以帮助用户快速构建空间计算能力。OceanBase 数据库 V3.2.4 版本开始支持 GIS，OceanBase 数据库的 GIS 设计选择了基于四叉树空间划分的索引方案，支持兼容 MySQL 8.0 的 GIS 数据类型，支持 SRS（空间参考坐标系）元数据的管理及缓存，支持基于 QuadTree 的空间索引，支持单值类型（GEOMETRY/POINT/LINESTRING/POLYGON）和多值类型（MULTIPOINT/MULTILINESTRING/MULTIPOLYGON/GEOMETRYCOLLECTION），并实现 MySQL 8.0 常用的空间计算函数。

性能提升

  • 数据导入性能优化。

    数据导入性能是 OLAP 领域内的一个重要衡量指标，在数据分析/大数据的业务应用中，数据量大是其中一个关键特征，那么如何将业务数据（text/csv 格式）快速的装载到数据库内部，对外提供查询分析服务，是会影响到 AP 领域数据库选择的技术能力和关键竞争力。

    数据库系统对于数据导入的通常做法是从客户端接收到数据，SQL 层进行数据解析，容错处理，路由分发，事务封装最后再进程存储持久化，这么做在设计上存在如下几个瓶颈点：1）一行一行数据进行，2）SQL 层过滤解析，3）CLOG 日志量大。因此 OLAP 系统数据库对此都有针对性优化，最常见的做法是通过旁路导入技术，将 SQL 的处理消耗代价屏蔽，使得数据可以直接持久化到磁盘上。

    OceanBase 数据库 V4.1 版本提供了旁路导入技术对数据加载执行路径进行精简，旁路导入跳过 SQL 层、事务模块、MemTable 等模块，直接将数据持久化到 SSTable，大大的提升了数据导入的速度。使用旁路导入能力需要为 load data 语句增加 HINT 标识，例如：load data /*+ direct(true , 1024) parallel(64) */ infile '/data/1/hits.tsv' into table hits Fields Terminated By '\t'; 通过视图 V$SESSION_LONGOPS 可以观测导入进度，支持多种模式主键冲突处理和过程容错，当前仅支持 CSV 格式数据文件。使用旁路导入在 c6a.12xlarge 规格（48vCPU，96GB 内存）机器上对 LINEITEM 表（74GB）进行数据导入测试，单 OBServer 节点导入速率可以达到 165MB/s。

  • 基于 OBProxy 的分布式事务路由优化，提升分布式事务性能。

    在业务数据建模时通常要求其事务处理尽可能聚集在一个数据节点上，来避免分布式事务引发的跨节点访问性能下降问题。OceanBase 数据库早期版本仅能支持事务内请求在一个 OBServer 节点上完成协同处理，因此 OBProxy 无法按照 SQL 本身访问数据的位置进行路由，这带来了分布式事务内 SQL 处理延迟增加，导致性能下降。客户业务在性能压测中，很多时候需要通过调整SQL顺序去优化性能，投入大量时间精力调优来降低分布式事务路由带来的负面性能影响。

    OceanBase 数据库 V4.1 版本针对分布式事务路由进行优化设计，借助 OBProxy 可将事务运行状态同步到 OBServer 节点上，不需要都发给协调者，每条 SQL 语句都可以计算路由，从而可以确保 SQL 请求可以在集群内任意 OBServer 节点上执行，从而消除不必要的处理延迟。通过 OBProxy 的配置项 enable_disributed_route 可开启分布式事务路由优化，默认开启。当前不支持 XA 事务的路由优化。

  • 编译反馈优化。

    通过编译反馈优化技术，在 SYSBENCH 测试模型下验证，性能综合提升约 10-15%。

  • 其它性能优化。

    • Nest Loop Join 算子性能优化，多级 Nest Loop Join 算子在特定 Group Rescan 场景下性能提升约 10 倍。
    • Index Skip Scan 执行优化，NDV 算子的计算量超过 50 万行数据时，性能可提升约 10 倍。
    • Truncate Table 并行执行优化，Truncate Table 语句执行效率提升约 10 倍。

稳定性增强

  • 扩展支持 DBMS_LOB 规格上限。

    在 OceanBase 数据库早期的版本中，LOB 数据存储大小限制在 48MB 以内，这对客户使用 LOB 带来了强约束限制。在本次架构升级中，通过存储层将 Lob 宏块的数据拆成多条 Lob Meta 进行存储，取数据的时候再将多条 Lob Meta 中的数据聚合成一个连续 Buffer 返回给 SQL 层处理，这样突破了数据存储大小的限制，通过普通 SQL 使用 LOB 规格扩展达到了 512MB，在 Oracle 模式下通过系统包 DBMS_LOB 使用 LOB 规格可扩展到 TB 级别。

高可用增强

  • 支持基于归档日志的物理备库。

    如何不断提升数据库的高可用能力是 OceanBase 数据库设计之初的目标之一，OceanBase 数据库通过分布式架构技术和多副本数据管理，可以满足大部分场景下业务系统高可用诉求。但是在银行、保险等对数据库高可用有极端追求的客户业务中，单集群的两地三中心在跨城网络通信不佳的情况下依然存在服务不可用风险（即地域级容灾），因此 OceanBase 数据库推出了物理备库的方案来解决跨城地域级容灾问题。

    在 OceanBase 数据库早期的版本中，物理备库（V3.x 版本之前称为主备库）采用集群级日志传输的策略，主备集群需要相互感知日志同步状态且存在租户间日志耦合的问题。在 OceanBase 数据库 V4.1 版本中将集群级别粒度的物理备库细化到租户级别的物理备库，主租户与备租户相互不感知实现完成解耦，归档日志同步采用异步同步策略，通过三方介质 NFS/OSS 来完成，主备租户支持日志断点续传，Switchover 和 Failover 切换操作。在租户级的物理备库方案下，OceanBase 数据库的一个集群内即可以存在主租户也可以存在备租户，帮助业务应用获的更均衡的资源利用率。

  • 支持更多场景达成 RTO 时间降低到 8s 以内。

    OceanBase 数据库 V4.0 版本架构升级针对分布式故障检测、分区选举能力进行优化和设计，使能够在故障恢复时缩短 RTO 的时间 <8s，但是故障场景是复杂和耦合的，在 V4.1 版本中继续识别分析分布式数据库故障场景，并加以优化使得在大多数场景下可以达成 RTO<8s 这个系统设计目标，主要完善优化场景如下：

    • 主 OBServer 节点故障宕机，连同 OBProxy 对外一起恢复服务。
    • 主 OBServer 节点的日志盘故障或数据盘故障，主节点报错但不退出，集群分区 Leader 进行迁移和选主后对外提供服务。此时可用副本数减少，故障的节点仍需要人工干预恢复。

运维能力提升

  • 支持 4.0 系列版本在线升级。

    OceanBase 数据库 V4.0 版本是大的架构升级版本，其中存储数据、内部表、视图、配置项、部分功能行为均发生了不兼容变化，所以 V3.x 版本无法支持热升级到 V4.0 版本，建议通过 OMS 工具进行数据逻辑迁移进行升级。但是从 V4.1 版本开始，系统数据兼容和支持物理在线升级是 OceanBase 数据库核心关键能力目标，同时也是满足客户项目升级不中断诉求，降低升级复杂度和代价，助力 OceanBase 数据库 V4.1 版本在市场项目上应用和推广。

    OceanBase 数据库 V4.1 采用轮转升级的总体策略。

    1. 发起升级操作后，集群将进入混部状态，系统按 Zone 替换 OBServer 的二进制程序，直至全部节点替换完毕后退出混部状态，此时高版本的 OBServer 的二进制程序以兼容方式运行低版本的数据和行为。
    2. 在租户内执行升级命令，系统内部进行变量/系统表/数据校验和升级修正。集群内租户需逐一执行同样升级命令，最后完成集群整体升级。推荐使用 OCP 工具完成集群在线升级任务。

    OceanBase 数据库 V4.1 支持的升级场景如下：

    • 支持集群在线升级。
    • 支持主备集群升级，主备集群需各自升级。建议先升级备集群后主集群，升级前建议先通过 Switchover 命令将集群内租户状态调整一致。
    • 支持从 V4.0 版本开始的后续版本连续升级，包括功能版本和补丁版本。
    • 升级成功的 OBServer 节点不支持回退，因此建议升级前做好数据和二进制程序备份。
    • 支持租户级版本升级。但不推荐同一节点不同租户的版本长期不一致，建议集群内所有租户协同升级到同一版本。

    与此同时，升级过程中也存在如下约束限制：

    • 禁止 DDL 操作，升级完成后自动开启。
    • 禁止 Major Freeze 操作，升级完成后会自动开启。
    • 禁止迁移复制和负载均衡，升级完成后会自动开启。
    • 禁止物理备份恢复操作，升级完成后会自动开启。
    • 禁止 Switchover/Failover 操作，升级完成后会自动开启。
    • 禁止新建租户操作，升级完成后会自动开启。

  • 日志系统与可读性优化整改。

    OceanBase 数据库 V4.1 版本对日志输出进行了系统性分析和优化调整，主要包括：

    • 日志级别定义：增加 DIAG 诊断日志级别，将无需用户感知的 WARN、ERROR 归到 DIAG 日志。对需要保留面向运维的预警/报错日志，进行日志级别分类调整，如下：

      日志级别 面向对象 定义 原日志级别
      ERROR DBA/用户 OBServer 不能提供正常服务的异常，如磁盘满监听端口被占用等。也可能是产品后台的内部检查报错，例如 4377(dml defensive check error)，4103 (data checksum error) 等，需人工干预恢复。
      WARN DBA/用户 出现非预期场景，OBServer 能提供服务，但行为可能不符合预期，例如写入限流告警。
      INFO DBA/用户 系统状态变化信息。 INFO
      EDIAG 研发 Error Diagnosis，协助故障排查的诊断信息，非预期的逻辑错误，如函数参数不符合预期等。 ERROR
      WDIAG 研发 Warning Diagnosis，协助故障排查的诊断信息，预期内的错误，如函数返回失败。 WARN
      TRACE 研发 任务级调试信息。 TRACE
      DEBUG 研发 详细调试信息。 DEBUG

    • 错误码关联：分类错误消息并完善对应的错误码。为用户的每一条告警、错误定义响应的错误码，用户可根据错误码检索文档寻找解决方法。

    • 按错误码限流：针对 WDIAG 级别日志按错误码进行限流，被限流日志仅输出错误码及限流日志数。增加 diag_syslog_per_error_limit 配置项用于控制此限流功能，默认单个错误 200 条 DIAG 日志每秒。

    • 日志文件自描述：在日志文件头部增加记录机器地址、机型信息 CPU 类型、OS 版本、OBServer 版本和 TimeZone 信息等。

  • 视图标准化优化，对视图/内部表进行重新整改设计，统一标准化视图输出共 73 个，推荐用户通过视图获取 OceanBase 数据库元数据等信息，更多信息请参见 文档链接。

  • 实时统计信息收集。

    统计信息的准确度是优化器生产良好执行计划的基础，OceanBase 数据库早期版本已经支持多种方式生成统计信息：

    • 通过系统包 DBMS_STATS 或 ANALYZE 命令手动触发收集.
    • 通过定时任务自动收集统计信息.
    • 在数据量变化超过一定阈值时自动收集统计信息。

    在 OceanBase 数据库 V4.1 版本中我们新增支持 Online 统计信息收集能力，通过系统变量 _optimizer_gather_stats_on_load 或者 HINT 可以启用该能力，当业务支持 CTAS 或者 INSERT 语句时，OceanBase 数据库会实时增量更新统计信息，避免常规统计信息收集时全表扫描所带来的的系统开销。

  • 持久化与存储优化。

    • 自适应合并（Compaction）：Compaction 会消耗大量的 IO 操作和 CPU 资源，因此针对不同的业务场景，需要采取不同的 Compaction 策略。在 LSM 存储体系下，Compaction 的核心目标是对这三类因子（写放大、读放大、空间放大）做最优平衡，自适应 Compaction 策略即是通过对表的历史转储、查询行为进行统计分析，抽取出当前 Tablet 特征，并依此判断该 Tablet 是否需要调度合并，在用户无感知的情况下完成合并。

    • 表空间优化：在小表多分区的场景下，宏块存储会有一定的存储放大现象，在分区数很多时容易出现磁盘空间不够的问题。通过将多个小 SSTable 存入一个物理宏块中进行合并存储，小表多分区场景下优化后宏块使用比例约 4%，宏块碎片比例约为 1.5%，大大提高了磁盘使用率。

产品形态

  • 支持单机产品形态。

    随着 OceanBase 数据库 V4.0 版本单机分布式一体化架构升级逐步完成，我们也顺利推出 OceanBase 数据库单机产品，支持通过 OCP/OBD 来部署安装单机版本，来帮助 ISV、小客户、社区用户等快速上手体验 OceanBase 数据库 V4.1 版本所带来的新产品能力，同时我们支持单机版本在线转化升级为分布式版本，在数据管理规模无法满足项目要求或业务需要更高的高可用能力时，可以轻松实现“角色”转换。

性能报告

测试环境规格：

资源 规格
CPU 平台架构 x86_6...
Read more
Assets 26

v3.1.4_CE_BP3

10 Feb 07:57
@Fireatoms Fireatoms
v3.1.4_CE_BP3
16544a2
Compare
Choose a tag to compare
v3.1.4_CE_BP3

版本信息

信息 描述
发布时间 2023-02-10
版本号 V3.1.4 BP3
提交号 16544a2
OBServer RPM 版本号 oceanbase-ce-3.1.4-103000102023020719

发版目的

本次发版主要是BUG修复，提升版本稳定性。

新增功能

  • 备份恢复支持OSS存储介质。

BUG修复

Assets 18

v4.0.0.0_CE_BP3

20 Jan 03:28
@Fireatoms Fireatoms
v4.0.0_CE_BP3
05bbad0
Compare
Choose a tag to compare
v4.0.0.0_CE_BP3

版本信息（V4.0.0 BP3）

项目 描述
发布日期 2023-01-12
版本号 V4.0.0.0 BP3
commit号 05bbad0
OBServer RPM 版本号 oceanbase-ce-4.0.0.0-103000022023011215

发版目的

本次发版主要是BUG修复,提升版本稳定性。

BUG 修复

1.[Bug]: NULL changed to '' after adding DISTINCT [3.1.4, 4.0.0]#1248
2.[Bug]: Unit testing make fail #1273
3.fix last_active_time reset bug when change user
4.fix physical restore report -4018 issue
5.[CP] [CP] fix connect by memory leak
6.fix size overflow when reconstruct sql
7.Fix 4.0.0 allocator deconstruction core bug
8.Fix migration reuse local major makes checksum error
9.fix insert oom caused by wrap allocator's interface empty
10.Fix full outer join with for update causing core
11.Fix observer core at create tablet for migration
12.fix null complex argument core
13.Fix deadlock when auto increment service alloc handle
14.fix ret= -4016 when switch leader
15.fix merge into result error when hitting plan cache

注意事项

  1. obdv1.6.2开始支持4.0 observer版本间的升级；
  2. ocp4.0-ce-bp1版本开始支持observer版本间升级；
Assets 26

v4.0.0.0_CE_BP2

13 Dec 09:54
@Fireatoms Fireatoms
v4.0.0_CE_BP2
58fdb0e
Compare
Choose a tag to compare
v4.0.0.0_CE_BP2

版本信息（V4.0.0 BP2）

项目 描述
发布日期 2022-12-09
版本号 V4.0.0.0 BP2
commit号 58fdb0e
OBServer RPM 版本号 oceanbase-ce-4.0.0.0-102000032022120718

发版目的

本次发版主要是BUG修复。

BUG 修复

  1. [Bug]: ERROR [CLOG] handle_submit_task_ 导致合并hang住 #1229
  2. observer core at oceanbase::sql::def_relational_eval_func #1131
  3. observer core at oceanbase::sql::int_int #1124
  4. observer core at oceanbase::common::ObDatum::get_int #1123
  5. hosts在pl 中被误判为关键字 #1230

注意事项

  1. obdv1.6.2开始支持4.0 observer版本间的升级；
  2. ocp4.0暂不支持4.0 observer版本间升级；

Version information

Information Description
Release date 2022-12-09
Release number V4.0.0.0 BP2
Commit number 58fdb0e

About this version

To provide better services to community users, OceanBase Community Edition V4.0.0.0BP2 optimizes the database to make it more stable based on the feedback on applications of the community project.

Fixed issues

  1. [Bug]: ERROR [CLOG] handle_submit_task_ cause major freeze hang #1229
  2. observer core at oceanbase::sql::def_relational_eval_func #1131
  3. observer core at oceanbase::sql::int_int #1124
  4. observer core at oceanbase::common::ObDatum::get_int #1123
  5. [Bug]: Hosts is misidentified as a keyword in pl #1230

Notes

  1. obdv1.6.2 begin support the upgrade of observer 4.0；
  2. ocp4.0 can not support the upgrade of observer 4.0；
Assets 26

v3.1.4_CE_BP2

13 Dec 12:16
@Fireatoms Fireatoms
v3.1.4_CE_BP2
0fda7c0
Compare
Choose a tag to compare
v3.1.4_CE_BP2

版本信息

信息 描述
发布时间 2022-12-12
版本号 V3.1.4 BP2
提交号 0fda7c0
OBServer RPM 版本号 oceanbase-ce-3.1.4-102000012022120715

概要说明

修复bug：租户数超过32个observer 重启失败的问题；#1228

Version information

Informarion Description
发布时间 2022-12-12
版本号 V3.1.4 BP2
提交号 0fda7c0
OBServer RPM version oceanbase-ce-3.1.4-102000012022120715

Fixed issues

  • [Bug]: Failed to restart the observer when the number of tenants exceeds 32 #1228
Assets 18

v4.0.0.0_CE_BP1

25 Nov 10:28
@LINxiansheng LINxiansheng
v4.0.0_CE_BP1
dd289d2
Compare
Choose a tag to compare
v4.0.0.0_CE_BP1

RELEASE NOTE

Information Description
Version V4.0.0_CE_BP1
OBServer RPM version oceanbase-ce-4.0.0.0-100000282022112511

About this version

This version fixed one bug.

BUGFIX

  1. Fix the observer can not reboot and high cpu usage on UOS and openEuler; #1181
  2. There is no upgrade function supported by obdeploy. Only UOS customer need to upgrade the observer to the new version;

发布说明

项目 描述
版本号 V4.0.0_CE_BP1
OBServer RPM 版本号 oceanbase-ce-4.0.0.0-100000282022112511

发版目的

本次发版主要是BUG修复。

BUG 修复

  1. 修复了UOS和openEuler操作系统observer无法启动或者cpu高的问题； #1181
  2. obd的升级流程还没提供，非UOS系统的用户不需要升级到这个版本；
Assets 22

v4.0.0.0_CE

02 Nov 03:14
@LINxiansheng LINxiansheng
v4.0.0_CE
6af7f9a
Compare
Choose a tag to compare
v4.0.0.0_CE

OceanBase 数据库社区版 V4.0.0.0_CE

OceanBase 社区发布 V4.0.0 版本是对分布式数据库系统架构设计的全面升级，定位为 Beta 测试版本，社区会关注用户使用反馈，不断对产品进行打磨和完善，应用项目投产上线需要慎重审视和仔细评估。

OceanBase V4.0 版本在保证功能特性不丢失的前提下，重新审视了数据库与分布式系统两个领域最基础的设计，全新推出业内首个单机分布式一体化架构，重点构建 HTAP 和云化两个基础能力属性。与此同时，本版本也从架构上解决了 V3.2 版本的设计瓶颈，支持更多用户业务关注的多个核心能力，在内核功能、兼容性、稳定性、性能上取得突破。

版本信息

信息 描述
发布时间 2022-11-02
版本号 V4.0.0_CE
提交号 6af7f9a
OBServer RPM 版本号 oceanbase-ce-4.0.0.0-100000272022110114

版本概要

本版本的核心能力特性如下：

  • 架构升级与受益

    支持单机分布式一体化架构，包含自适应日志流、支持超大事务、RTO 时间降低到 8s 以内、NTP 服务依赖优化、支持分区数量能力上限等版本基础核心能力构建。

  • 内核能力增强

    Online DDL 能力增强，支持租户级备份，字符集扩展，支持数据编码，支持 IOPS 隔离，LOB 规格上限扩展，支持表锁和死锁检测等。

  • 兼容性增强

    支持 DDL 语句的外键约束，支持视图列信息展示，支持 DML 触发器，支持更多 SQL MODE 和函数等。扩展支持 SEQUENCE 对象，支持存储程序，支持 SQL 文本中的预处理，支持自增列做为分区键。

  • 性能大幅提升

    • SYSBENCH 性能优化，综合读写性能（Read Write）1024 并发测试性能相比于 V3.1 版本提升 1 倍。

    • TPCH 查询性能优化，100GB 数据量顺序执行 22 条 SQL，整体性能相比于 V3.1 版本提升 5 倍。

  • 运维能力提升

    支持全链路追踪，支持 SESSION 状态的监控和诊断（ASH），标准化视图优化，支持 Schema History 回收功能，支持自动清空回收站功能等。

特性更新

架构升级与收益

  • 自适应日志流介绍

    OceanBase 早期版本的架构体系里以分区为基本单元进行操作，当系统内的分区数量达到一定程度之后，以分区为单元的操作的消耗也随之增大，逐渐形成了 OceanBase 的使用痛点：单节点支持的分区数量受到限制，单节点上涉及跨分区的数据修改也需要两阶段提交协议来保证事务的原子性等问题。

    日志流是由 OceanBase 自动创建和管理的实体，它代表了一批数据的集合，包括若干分区和有序的 Redo 日志流。在新的系统架构下，一个 Unit 内的所有分区的事务修改日志可以都记录在一个日志流中，通过日志流把修改同步到其他 Zone 的对应 Unit 上。OceanBase 的每个租户每有一个 Unit，就会有一个对应的日志流。系统会把一个日志流和其所对应的分区关系固定下来，只有迁移发生时，才会改变这个对应关系。

  • 支持超大事务

    基于新的自适应日志流架构，对事务引擎进行重新设计，解决了分布式数据库普遍的大事务场景使用痛点，比如事务大、参与者数量多、事务提交卡等问题。新事务引擎能稳定应对在线业务、批处理、订正数据等多种业务场景，使得用户在各自繁杂的业务场景下可以放心的使用数据库。

  • RTO < 8s

    基于全新的自动选主协议以及全面的探活机制，进一步将机器故障场景下系统恢复时间降低到 8s 以内，帮助业务系统更快恢复，最大程度减少业务影响，给业务带来持续可用的能力。

  • NTP 服务优化

    基于全新的自动选主协议，取消了对 NTP 时钟的依赖，打破原来早期版本对所有节点的时钟偏差控制在 100ms 以内的强需求。OceanBase V4.0 版本允许的时钟偏差可以达到 2s，同时支持动态修改时钟，不会对数据正确性和集群稳定运行带来影响。

  • 优化分区能力上限

    在自适应日志流的架构设计下，系统内部一个 Unit 内的所有分区共享一个资源组，大大降低了早期版本每个分区独立申请保存系统资源，提升系统资源的利用率，因此不再需要根据配置限制 OBServer 节点的分区上限个数，但分区上限仍受机器可用物理资源限制。

内核能力增强

  • Online DDL 能力增强

    在 OceanBase 早期的版本中，由于架构设计上的限制，对数据库 Online DDL 能力进行了有限支持，例如不支持主键修改操作给业务使用带来了诸多不便。得益于新版本一体化的架构设计，OceanBase 针对涉及到数据搬迁的 Online DDL 操作进行增强支持，主要包括：

    • 支持添加主键、修改主键和删除主键

    • 支持添加外键、删除外键

    • 支持修改列名和列类型，包括字符、数值、日期等类型的相互转换

    • 支持普通表转换为分区表

    • 支持在线修改表或列的字符序

  • 支持租户级备份

    多租户是 OceanBase 的核心价值能力之一，在大多数客户系统中，用户都选择在同一个集群中创建了多个租户，每个租户代表一个业务单元，根据业务的不同种类和对客户的重要程度，需要有不同的备份频率和策略进行细粒度支持。在 OceanBase V4.0 版本中将集群级别粒度的备份能力细化拆分到租户级别粒度，支持按租户级别的备份，也支持将备份数据恢复到新租户。优化数据备份快照保留策略，减少备份期间的磁盘空间影响。同时拆分数据备份与日志备份存储目录，支持分别接入不同性能的备份介质。

    有关租户级备份的更多详细信息，参见 备份恢复

  • 扩展更多字符集

    支持 UTF8、UTF16、GBK、GB18030 和 BINARY 字符集，新增支持 UTF8MB4_BIN、UTF16_BIN、GBK_BIN、GB18030_BIN、UTF8MB4_GENERAL_CI、 UTF16_GENERAL_CI、GBK_CHINESE_CI和GB18030_CHINESE_CI 排序规则。

  • 向量化引擎开源

    OceanBase 在商业版 V3.2.3 全面实现了向量化引擎，以 Architecture aware 的设计改造了全部的算子和绝大部分常用的执行表达式，充分发掘现代 CPU 的 cache 特性以及优化指令，并应用于 TPC-H 的 benchmark 中。向量化带来了大量的算法优化可能，通过在向量化的框架下进行算法和数据结构优化，实测整体执行性能相比原先非向量化执行引擎性能提升普遍在 4-5 倍，很多算子和单场景可获得 10 倍以上的性能提升。在本次版本发布中，OceanBase 将其向量化引擎能力全部开源，帮助用户在 OLAP 场景下获取更好的性能。

  • 数据编码开源

    OceanBase 通过数据编码压缩技术实现了数据的高压缩比，是帮助用户减小存储成本重要技术手段。OceanBase 本次开源多种数据编码方法，包括字典编码、RLE 编码、常量编码、差值编码、前缀编码、列间编码等，并支持每一列自动选择最合适的数据编码。通过编码和压缩，使用相同的块大小（16KB）、以及相同的压缩算法（lz4），同样的数据存放在 OceanBase 中，要比在 MySQL 5.7 中平均节省一半的空间，同时没有损失任何查询性能。

    有关数据编码的更多详细信息，参见 数据压缩与编码

  • 支持 IOPS 隔离

    OceanBase 早期的版本已经支持了租户级别的 CPU 和内存隔离，V4.0 版本开始支持租户间 IOPS 隔离，租户之间彼此感知不到对方对磁盘带宽的占用，避免租户间业务的 IO 资源争抢，实现完备的租户资源隔离能力。

    用户通过 UNIT CONFIG 设置 UNIT 的资源规格，其中 MIN_IOPS、MAX_IOPS、IOPS_WEIGHT 是 IOPS 隔离相关资源，租户的可用资源与 UNIT 绑定。通知支持动态调整租户的 IOPS 规格，修改 UNIT CONFIG 中的 IOPS 相关设置即可实时生效。在租户内部，支持通过配置项 io_category_config 分配各类别 IO（业务请求、系统日志等）请求的百分比，进而细粒度控制 IO 资源分配与调度。

  • LOB 规格上限扩展

    在 OceanBase 早期的版本中，LOB 数据存储大小限制在 48MB 以内，这对客户使用 LOB 带来了强约束限制。在本次架构升级中，通过存储层将 Lob 宏块的数据拆成多条 Lob Meta 进行存储，取数据的时候再将多条 Lob Meta 中的数据聚合成一个连续 Buffer 返回给 SQL 层处理，这样突破了数据存储大小的限制，使得 LOB 存储上限扩展达到了 512MB，后续将持续优化到 TB 级别。

  • 支持表锁和死锁检测

    表锁允许业务以指定的方式锁定表或分区，避免业务并发操作造成数据破坏。在 OceanBase V4.0 版本中支持了 Online DDL 操作，因此必须配套表锁保护 DDL 与 DML 并发时的正确性问题。新增支持 LOCK TABLE 语法，支持 SHARE 和 EXCLUSIVE 两种锁定模式，同时支持对锁冲突的死锁检测。

MySQL兼容性增强

  • 支持 DDL 语句的外键约束

    OceanBase 数据库默认开启外键约束检查，外键约束检查开关由租户变量 FOREIGN_KEY_CHECKS 来控制，要求约束的列的值取自于另外一个表的主键列。在早期的版本中，外键约束检查仅对 DML 操作有效，DDL 操作不受影响。OceanBase V4.0 版本中支持了 FOREIGN_KEY_CHECKS 系统变量对 DDL 部分的影响，其行为保持与 MySQL 兼容。

  • 支持视图列信息展示

    在 MySQL 数据库中，视图列信息和表列信息一样，被作为基础的元信息被存储在数据字典中，并通过 INFORMATION_SCHEMA.COLUMNS 显示给用户。OceanBase 数据库内部仅对表列信息进行了持久化存储，V4.0 版本通过采用动态解析视图定义的方法，避免了对视图复杂的依赖关系解析，实现在 INFORMATION_SCHEMA.COLUMNS 中展示视图列信息。

  • SQL Mode 扩展支持

    扩展支持 MySQL 默认开启的 SQL Mode，新增支持 NO_ZERO_DATE、ERROR_FOR_DIVISION_BY_ZERO 和 NO_AUTO_CREATE_USER 三个 SQL Mode，产品行为与 MySQL 兼容。针对 NO_ENGINE_SUBSTITUTION 仅支持语法兼容。

  • 支持 SQL 文本中的预处理

    支持 SQL 文本中的预处理语句（Prepared Statements），Prepared Statements 接口使用二进制协议相比交互式SQL 接口具有更高的执行效率，使用方法大体如下：

    • PREPARE 准备执行语句。PREPARE stmt1 FROM 'SELECT SQRT(POW(?,2) + POW(?,2))';

    • EXECUTE 执行准备好的语句。SET @a = 3; SET @b = 4; EXECUTE stmt1 USING @a, @b;；

    • DEALLOCATE PREPARE 释放一个准备好的语句。DEALLOCATE PREPARE stmt1;

  • 支持自增列做为分区键

    例如：

    create table t2(inv_id bigint not null auto_increment ,c1 bigint, primary key (inv_id) ) partition by hash(inv_id) partitions 8;

    使用自增列作为分区键时需要额外注意，自增列的值全局唯一，但在分区内不保证始终增长，和原生 MySQL 行为不同。和其他分区方式相比，对这类分区表的插入操作性能会有一定的下降。

  • 支持 SEQUENCE 对象

    扩展支持 SEQUENCE 对象，满足业务系统对 SEQUENCE 对象的依赖诉求，降低客户在业务迁移过程中的适配复杂度。支持 CREATE/ALTER/DROP SEQUENCE 对象，支持获取 CURRVAL、NEXTVAL 和重置取值等对象操作，支持的对象取值范围从 INT64_MIN 到 INT64_MAX。

  • 支持存储程序

    支持兼容 MySQL 5.7 语法的存储程序（包含存储过程和存储函数），支持游标、流程控制语句、异常处理、存储程序相关的DDL操作和视图和状态查询。同时扩展支持多个系统包，例如 DBMS_STATS、DBMS_SESSION 等。

  • 支持 DML 触发器

    支持在表上创建触发器，兼容 MySQL 5.6 语法。当在该表上 DML 操作满足条件时、触发用户自定义行为。

  • 支持更多函数

    • 支持函数 ADDTIME()，将指定的时间间隔添加到给定的日期和时间。例如：SELECT ADDTIME('2007-12-31 23:59:59.999999', '1 1:1:1.000002');

    • 支持函数 DAYNAME()，返回给定日期的工作日名称。例如：SELECT DAYNAME('2018-01-8');

    • 支持聚合函数 BIT_AND()/BIT_OR()/BIT_XOR()，返回表达式的按位与/或/异或的运算结果。

    • 新增函数 UUID_SHORT()，返回 64-bit 无符号整数。例如：SELECTUUID_SHORT();

运维能力提升

  • 支持全链路追踪

    OceanBase 作为一款久经沙场的分布式数据库，其内部数据访问的链路已经非常复杂，当线上出现超时等问题的时候，往往无法有效快速定位问题出现的第一现场，需要依靠有经验的运维人员对追个环节进行排查，验证影响到运维效率和故障影响速度。OceanBase V4.0 版本设计了一套全链路追踪的机制，能够提升全链路问题定位的效率，贯穿从业务 APP > 客户端驱动(JDBC, OCI) > 代理（OBProxy）> 数据库节点（OBServer）到全部流程，用户通过 PL/SQL 或 OBClient 接口在应用程序 APP 中设置相关标识信息（MODULE/ACTION/CLIENT_INFO/CLIENT_IDENTIFIER）到正在使用的链接中，运维人员可以通过 PL/SQL 程序包，控制相关应用程序设置的标识信息维度是否打开全链路跟踪诊断以及设置诊断输出策略；诊断日志以 OpenTracing 数据模型输出到 OBProxy 和 OBServer 日志文件中进行保存, 通过对诊断日志解析, 即可达到追踪每个 SQL 每个事务在全链路中执行耗时等相关诊断信息。

    有关全链路追踪的详细介绍，参见 全链路追踪

  • 支持 SESSION 状态的监控和诊断（ASH）

    OceanBase 数据库早期版本已经支持获取当前正在执行的 SQL 的状态信息，包括等待事件等信息，但只能通过 __all_virtual_session_wait 查询到 session 最近一次等待事件。OceanBase V4.0 版本支持更全面的 session 与等待事件之间的关系图（ASH），不仅包含当前执行的 SQL 的状态，还包含 SESSION、USER、SQL、WaitEvent 等多个维度状态历史信息。ASH 能够以 1s 为周期采样系统中所有 Active Session 状态，采用过程中全程不加锁不影响业务 SQL 的正常执行。OCP 通过对这些状态采样信息进行综合汇总分析，帮助用户了解过去一段时间里系统的负载以及等待状态，及时发现并预警问题。

  • 支持实时执行计划监控

    OceanBase 在 SQL 执行计划的诊断中引入了 SQL Plan Monitor, SQL Plan Monitor 提供了关于逻辑执行计划、物理执行计划、算子吐行数、算子开始/结束时间点等信息, SQL Plan Monitor 信息只能在 SQL 执行完毕后获得，可以通过 GV$SQL_PLAN_MONITOR 租户级视图获取相关信息。OceanBase V4.0 版本支实时 SQL Plan Monitor，可以实时的查看当前租户各 SQL 执行计划状态，在客户实际业务场景或者是诊断分析场景, 如果存在 SQL 卡住的问题, 此时通过实时 SQL Plan Monitor 也可以查询各个执行线程执行算子的执行状态。

  • 支持 Schema History 回收功能

    解决 Schema History 只增不删导致 Schema History 过多，影响 OBServer 启动慢的问题。通过隐藏配置项 _schema_history_recycle_interval 控制 Schema History 回收周期，该配置项缺省值是 0，表示关闭 schema history 回收功能。

  • 支持自动清空回收站功能

    OceanBase 数据库回收站提供以租户为单位，当磁盘空闲空间不足时，按照 FIFO 策略，自动清理回收站空间的功能。增加配置项 recyclebin_object_expire_time 用于指定回收站中对象的过期时间。

性能报告

测试环境规格：

CPU 平台架构 x86_64
ECS 类型 ecs.g7.8xlarge
计算资源 32核
内存资源 128GB
磁盘资源 500G ESSD云盘
操作系统 CentOS Linux release 7.9.2009 (Core)

测试版本：

产品 版本信息
OBServer (V4.0.0_CE) observer (OceanBase_CE 4.0.0.0)
REVISION: 100000152022102115-06570c6f755c1fabe3ca9a25bef54af77e7c8c9c
BUILD_TIME: Oct 21 2022 17:22:38
OBProxy (V4.0.0) obproxy (OceanBase 4.0.0 2)
REVISION: 1-local-b1ef5a6b5b196916ae26bdea814765e5165a801f
BUILD_TIME: Oct 22 2022 11:06:04

SYSBENCH OLTP 负载测试

测试方案:

  1. 通过 OBD 部署 OceanBase 集群，ODP 和 Sysbench 单独部署在一台机器上, 作为客户端的压力机器。

  2. OceanBase 集群规模为 1：1：1，部署成功后先新建跑 Sysbench 测试的租户及用户（sys 租户是管理集群的内置系统租户，请勿直接使用 sys 租户进行测试），设置租户的 Primary Zone 为 RANDOM，RANDOM 表示新建表分区的 leader 随机到这 3 台机器。

  3. 启动 Sysbench 客户端，进行 point_select、read_write、read_only 和 write_only 测试。

  4. 每轮测试 --time 设置为 60s，线程数取值可以为 32/64/128/256/512/1024。

  5. 测试数据量为 30 张非分区表，100 万行数据，即 --tables=30，--table_size 设置为 1000000。

租户规格：

  • MAX_CPU = 26

  • MEMORY_SIZE = 70g

测试结果：

Point Select 性能

Threads V4.0.0_CE QPS V4.0.0_CE 95% Latency (ms) V3.1.0_CE QPS V3.1.0_CE 95% Latency (ms)
32 180360.71 0.21 139124.75 0.28
64 312254.88 0.26 232522.69 0.36
128 473423.04 0.41 322185.31 0.63
256 571193.03 0.89 362650.60 1.58
512 604975.51 2.97 387072.57 3.96
1024 614351.07 4.33 401404.45 7.84

**Read Only 性能...

Read more
Assets 26