2.x 版本下大事务导致事务悬挂、无法结束，以及 Clog 不同步的故障

适用版本

OceanBase 数据库 V2.x 版本。

问题描述

1. OceanBase 集群一个节点 core 掉。手动拉起 OBServer 进程后，OCP 告警消除，OceanBase 集群正常，但是响应慢、执行 SQL 无响应。
2. 事务分配内存不足、部分节点存在悬挂事务、部分节点 home 目录满。

问题原因

排查过程：

1. 有 7 个节点（zone4:3 台、zone5:2 台、zone6:2 台）clog 日志不同步。

   obclient> select svr_ip,count(*) from __all_virtual_clog_stat where is_in_sync=0 and is_offline=0 group by svr_ip;
   

   +---------------+----------+
   | svr_ip        | count(*) |
   +---------------+----------+
   | 192.xxx.x.193 |       10 |
   | 192.xxx.x.194 |       10 |
   | 192.xxx.x.195 |       15 |
   | 192.xxx.x.196 |    26357 |
   | 192.xxx.x.199 |    25529 |
   | 192.xxx.x.200 |    24075 |
   | 192.xxx.x.202 |    27125 |
   +---------------+----------+
   7 rows in set (0.30 sec)
   

2. 根据 OCP 悬挂事务告警，查询事务悬挂情况，发现 clog 不同步的节点上存在大量悬挂事务。

    obclient> SELECT count(1),svr_ip FROM __all_virtual_trans_stat WHERE part_trans_action > 2 AND ctx_create_time < DATE_SUB(NOW(), INTERVAL 1200 SECOND) group by  svr_ip;
   

   +----------+---------------+
   | count(1) | svr_ip        |
   +----------+---------------+
   |       15 | 192.xxx.x.193 |
   |        6 | 192.xxx.x.194 |
   |       15 | 192.xxx.x.195 |
   |      422 | 192.xxx.x.196 |
   |     1945 | 192.xxx.x.198 |
   |      502 | 192.xxx.x.199 |
   |      727 | 192.xxx.x.200 |
   |     1945 | 192.xxx.x.201 |
   |      299 | 192.xxx.x.202 |
   +----------+---------------+
   

3. 这些悬挂事务 ID，在 __all_virtual_processlist 中查询均无对应 session 记录，说明业务侧已经结束，但 OceanBase 数据库在事务提交阶段出现故障，无法完成事务提交。

4. 经过运维排查：网络、时钟、磁盘等都没有问题。

5. 之后经过一段时间的观察，202 节点 clog 仍有几千个 partition 未同步，且未同步 partition 有逐渐增多的趋势。

    obclient> select svr_ip,count(*) from __all_virtual_clog_stat where is_in_sync=0 and is_offline=0 group by svr_ip;
   

   +---------------+----------+
   | svr_ip        | count(*) |
   +---------------+----------+
   | 192.xxx.x.193 |       35 |
   | 192.xxx.x.194 |       16 |
   | 192.xxx.x.195 |      298 |
   | 192.xxx.x.196 |    26580 |
   | 192.xxx.x.199 |    26431 |
   | 192.xxx.x.200 |    27547 |
   | 192.xxx.x.202 |     6671 |
   +---------------+----------+
   

6. 查看 OBServer 日志，发现有内存分配的报错。

   [2022-01-17 23:28:19.735300] ERROR [STORAGE.TRANS] dup (ob_memtable_key.h:184) [124314][1112][Y0-0000000000000000] [lt=12] [dc=0] alloc memory for memtable_key fail BACKTRACE:0xxxxxxxx 0xxxxxxxx 0xxxxxxxx 0xxxxxxxx 0xxxxxxxx 0xxxxxxxx 0xxxxxxxx 0xxxxxxxx 0xxxxxxxx 0xxxxxxxx 0xxxxxxxx 0x8
   

   经过进一步排查，200 与 202 故障节点内存已超使用限制。最终确定是租户的 MemStore 内存不够。

7. 同时确认该集群搭建集群后上线前测试适配过程中，当时执行 update 大事务线上验证测试，故修改了大事务限制参数 _max_trx_size（默认 100M 至 5G）。

问题原因

2.x 版本不支持未提交事务的转储，大事务导致了 MemStore 用满，而 MemStore 用满导致 clog 同步失败（当 clog 无法回放时，clog 同步也会失败），clog 同步失败导致事务提交无法达成多数派，因而出现悬挂事务。

解决方法

临时采用增加内存的方式恢复节点。

1. 将所有节点 memory_limit 参数调大后增加租户的内存分配。
2. 重启故障机器，等待 clog 同步完成后悬挂事务也正常结束了。
3. 调整事务参数 _max_trx_size 为默认值（100M）。