OceanBase 数据库事务管理中的 upper_trans_version

OceanBase 数据库事务管理中的 upper_trans_version 是决定了 Minor SSTable 中可回收位点的关键逻辑，本文将详细展开相关概念以及已知问题。 upper_trans_version 是事务管理和存储管理逻辑中的一个关键逻辑，OceanBase 数据库内核团队会追踪相关的问题并在发现问题后尽快修复，具体的问题请参考本文详细说明章节。对用户来说，应当尽快推高到包含修复的版本。滞留在有问题的版本是有风险的。

详细说明

OceanBase 数据库 V3.x 版本开始有了转储未提交事务能力，未提交的事务也会被持久化到 Minor SSTable 上，后续已提交事务持久化到 major sstable（也叫做基线 sstable）后，数据会同时存在在 minor 和 major 中。 如果长时间不回收这部分已经“没有用”的 Minor SSTable，既会导致读链路的增长影响相关查询的 RT，也有可能造成不必要的磁盘空间浪费。如果系统中有大量并发的事务，这些事务在不同时间开始，不同时间结束，系统的转储合并动作也同时在后台发生，就需要有一个明确的算法决定哪些 Minor SSTable 是需要回收的。OceanBase 数据库 V3.x 的事务状态都存储在内存中，事务状态也有一个标识来标记事务是否需要被保留。upper_trans_version 的计算逻辑是根据内存态的信息计算，计算的逻辑也相对简单。 OceanBase 数据库 V4.x 为了更好的管理事务状态数据，引入了事务上下文表和事务数据表，这些运行态的信息也同样可以通过转储合并持久化下来，但这同时导致 upper_trans_version 这个用于决定 minor 可回收位点的逻辑发生了变化也变地更加复杂：当 major sstable 的事务快照右边界超过 Minor SSTable 的 upper trans version 才可以回收 Minor SSTable。

OceanBase 数据库内核计算出“正确”的 upper_trans_version 是非常重要的，如果 upper_trans_version 计算的偏小，会导致本来应该保留的 minor 被回收，本来应该被读到的事务没有了，会导致数据正确性问题。精准地计算出 upper_trans_version 在大事务和复杂系统上是有代价的，如果 upper_trans_version 只是略微偏大，是没有问题的，只会有少量的（甚至是不可见）的性能代价，但比精准计算出 upper_trans_version 就会划算很多。 在计算 upper_trans_version 时，每个 SSTable 的 upper_trans_version 被初始化为 INT64_MAX，也就是 9，223，372，036，854，775，807。如果 upper_trans_version 长久地计算不出来（维持在默认值 INT64_MAX），这会导致判断 minor 回收位点无法进行。minor 如果一直被持续生成且来不及及时被回收合并，一方面存储占位会有增长，另一方面积压持续可能导致 SSTable 总数超过 MAX_SSTABLE_CNT_IN_STORAGE（64） 个（相关任务会收到报错 -4037）。如果有持续的事务和写入，有可能会导致 OceanBase 数据库的限速机制生效，最终导致用户的请求响应受到影响。 upper_trans_version 计算不出来的影响和相关概念需要展开详细解释三点： upper_trans_version 如果计算不出来，大概率并不会第一时间就产生用户可感知的影响。upper_trans_version 直接影响的是 OceanBase 数据库中 Minor SSTable 生产与消费的过程。系统不断有写入，转储的过程会生成 Minor SSTable；系统 minor 回收、合并的过程会消费 Minor SSTable（转储合并中有 mini，minor 更复杂地逻辑本文暂时不展开，不影响主逻辑）。如果生产 minor 的速度没有消费的速度快，最终造成了 Minor SSTable 的堆积（e.g. 最终 SSTable 超过 64 个），此时还有很高的 TPS 可能就会产生可感知的影响。 但终归需要时间累积和负载累积才会外显出可见的影响。不过任何 OceanBase 数据库的集群，特别是生产集群想要保持集群稳定无风险都要避免 upper_trans_version 长时间计算不出来（比如天数以上），因为一旦发生影响面是大的，且止损方式是有代价的。 第二点需要解释一下为什么系统中可能存在 upper_trans_version 没有立即计算出来的情况：这是因为当前的算法逻辑还依赖事务的状态。 如果系统中还存在正在运行中的事务，特别是长事务，那在长事务完结前 upper_trans_version 就是无法被计算出来的。所以在 Minor/Mini SSTable 的 UPPER_TRANS_VERSION 长时间算不出来中提供的巡检逻辑是：长时间的计算不出来的 upper_trans_version 是需要被监控的风险。后续也会增强在 OceanBase 数据库的运行日志告警逻辑中。OceanBase 数据库内核团队还在持续优化 upper_trans_version 的算法，未来预期会有优化。 当系统长时间计算不出来 upper_trans_version，且系统持续有大量的 TPS 涌入，用户可能感受到存储空间占用放大；TPS 下跌，RT 变慢的现象。如果不幸因为 upper_trans_version 计算有问题导致这些系统行为，通过现象进行根因诊断是艰难的。这也是因为 OceanBase 数据库的容错机制在能力越来越强的同时也越来越复杂：如果直接导致了 MemStore 限速，大概率计算不出来 upper_trans_version 的节点是一定会受到写入影响，取决于集群架构（如是 3F、2F1A，Leader是否打散）的具体情况，可能影响部分节点或者系统全局的请求响应；如果 MemTable 无法刷盘导致 clog checkpoint 位点无法推进，影响 clog 的回收机制，当 clog 不可回收日志（cur_unrecyclable_log_disk_size）达到 60%（OceanBase 数据库 V4.x 版本 clog 限速启动的默认配置，log_disk_throttling_percentage），最终会导致触发 clog 提交限速。导致系统中相关的请求受到影响。但 clog 限速达到的影响面会更加复杂一些， 这是因为 clog 组件在 OceanBase 数据库 V4.x 版本也做了更多优化，例如感知 Leader IO 能力下的 clog 聚合算法提升，这对部分故障场景会有消减影响的作用，最终导致只有部分请求受到影响。对用户是件好事情，但也同时提高了诊断的难度。对系统来说，是遇到 MemStore 限速还是 clog 限速，就看系统在 MemStore 内存资源和 clog 存储资源哪个相对“更富裕”，哪个是系统这个木桶的“短板”。 对 OceanBase 数据库集群而言，理解 upper_trans_version 是复杂和需要深入地，要诊断 upper_trans_version 相关的问题是有代价且有难度的。OceanBase 数据库内核团队会追踪相关的问题并在发现问题后尽快修复。对用户来说，应当尽快推高到包含修复的版本。滞留在有问题的版本是有风险的。

目前 OceanBase 数据库 V4.x 版本有两个已知的问题会导致 upper_trans_version 计算不出来：

• OceanBase 数据库 V4.2.5 版本，在增强 transfer 不杀事务能力时，工程实现中引入了一个 upper_trans_version 计算不出来的问题。 在 OceanBase 数据库 V4.2.5 BP2 Hotfix3（oceanbase-4.2.5.2-102030052025032518）及 V4.2.5 BP3（oceanbase-4.2.5.3-103000142025033110）上进行了修复。详细参见：Minor/Mini SSTable 的 UPPER_TRANS_VERSION 长时间算不出来。

• OceanBase 数据库 V4.2.1 版本，有一个 HA 场景下 upper_trans_version 计算不出来的。 在高版本也进行了修复。

影响版本

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

适用版本

OceanBase 数据库 V4.x版本。