问题现象
出现问题的场景是 lob 日志，一条完整的 lob 行产生的日志是 big row start / middle / end。事务内部会在回放 big row end 过程中把内存中积攒的当前 b 行给组装成一个完整的 row，因此会做反序列化的动作。但是若 leader 在写 lob 日志的过程中触发 rollback 操作，可能会产生两条 big row start。因此在此 BUG 下，实现上备机在第二个 big row start log 回放期间做了反序列化操作，触发数据结构的防御性报错，进而回放失败；内存的一些数据结构做了回滚操作，导致了 core。
关键诊断信息
触发条件
若 leader 在写 lob 日志的过程中触发 rollback 操作，可能会产生两条 big row start。
事前巡检
关键日志一：回放报错 4016。
如下日志信息。
replay redo log error(ret=-4016, ret="OB_ERR_UNEXPECTED"关键日志二：deserialize mutator row fail。
如下日志信息。
WARN [STORAGE.TRANS] get_next_row (ob_memtable_mutator.cpp:1048) [882753][0][Y0-0000000000000000-0-0] [lt=58979] [dc=0] deserialize mutator row fail(ret=-4016)
问题原因
问题原因是 OceanBase 数据库内部的 BUG，因为语句执行超时，需要回滚，接下触发的 rollback to savepoint 需要持久化日志，此时候若遇到事务正在写 lob 行日志，可能会写两条 log row start 日志，导致备回放报错失败，这里实现上存在一个缺陷。
问题的风险及影响
问题发生后，所有相关租户的 follower 副本都有问题。
日志回放报错之后内存可能会被写坏，由于日志一直在重试回放，所以所有 follower 节点都有一定的概率撞到 coredump；有导致集群多数派 core 的风险，比较严重。
影响租户
影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。
影响版本
OceanBase 数据库企业版 V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本。
解决方法
问题发生前：
升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V3.2.3 BP9 Hotfix1（oceanbase-3.2.3.3-109010012023072721）、V3.2.3 BP9 Hotfix2（oceanbase-3.2.3.3-109020032023081510）、V3.2.3 BP9 Hotfix3（oceanbase-3.2.3.3-109030012023111713）、V3.2.3 BP9 Hotfix4（oceanbase-3.2.3.3-109040012024071014）、V3.2.3 BP10（oceanbase-3.2.3.3-110000092023091219）、V3.2.4 BP5（oceanbase-3.2.4.5-105000012023081513）。
问题发生时：
暂无快速阻止问题副本所在节点继续 core 的手段，只能采用新补副本的方式来替换有问题的副本（用 leader 上的副本 rebuild 出来的副本大概率是对的），待有问题的副本被 GC 掉之后，相关节点才不会继续 core。
同时需要尽快暂停业务，防止问题污染新副本。
规避方式
尽量减少存在 lob 列的事务中，报错（比如说超时）从而导致语句回滚的场景。
