大事务场景切主后新主无法上任的问题

问题现象

存在大事务的业务在切主的场景下，新主上任一直超时，导致对应分区一直无主。

问题原因

首先说明前提：事务会为 memtable 内的每一个修改维护一个 callback，并通过链表的方式维护起来。通过回调这些 callback 来处理事务正常的操作（切主、提交、回滚等）；当 memtable 转储成为 sstable 后，对应的 callback 会释放，通过未提交事务的接口异步来处理这些数据。

例如：在租户拥有大量内存的场景下，当用户执行 delete 全表的大事务时，由于 delete 只会产生较小的数据量（delete trans node），因而内存中可能会存在上千万的 callback 数量，遍历的代价超过了默认值的 10 秒，导致一直无法分区上任。

因此问题的原因是：新主上任需要遍历事务中所有内存中的数据，遍历的代价超过了默认值的 10 秒，导致分区一直无法上任。

关键信息

暂无额外诊断信息。该问题通过观察切主后新主上任超时即可判断，无特定错误码。

问题的风险及影响

1. 改成 30 秒后，因为异常导致的强制切主会延迟到 30 秒，影响异常下的恢复。
2. 使用了全新的配置项 _ob_role_change_timeout，原先的配置项 ob_role_change_timeout 不再使用。

影响租户

sys 租户、MySQL 租户、Oracle 租户均受影响。

适用版本

OceanBase V3.2.3 版本，起始版本 V3.2.3.3 BP8，3.2.3 版本暂不修复。

解决方法

为了解决这一痛点，测试了全事务在 1 亿行 callback 的遍历速度，大概在 21 秒。由于考虑到用户机器性能的差距（测试用的机器较好）以及数据量的容错，选择 30 秒作为新的配置项默认值。

• 老版本通过设置 ob_role_change_timeout 为 30 秒。
• 新版本通过设置 _ob_role_change_timeout 为 30 秒。

规避方式

避免在大事务场景下进行切主操作，或控制大事务的规模以降低 callback 数量。