---
title: 2.x 版本下大事务导致事务悬挂、无法结束，以及 Clog 不同步的故障-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于2.x 版本下大事务导致事务悬挂、无法结束，以及 Clog 不同步的故障相关的常见问题和使用技巧，帮助您快速解决2.x 版本下大事务导致事务悬挂、无法结束，以及 Clog 不同步的故障的难题。
---
切换语言

- 简体中文
- English

划线反馈

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

更新时间：2026-06-12 03:56

适用版本： V2.1.x、V2.2.x 内容类型：Troubleshoot  

## 适用版本

OceanBase 数据库 V2.x 版本。

## 问题描述

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

## 问题原因

排查过程：

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

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

   ```

   ```shell
   +---------------+----------+
   | 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 不同步的节点上存在大量悬挂事务。

   ```shell
    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;

   ```

   ```shell
   +----------+---------------+
   | 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 有逐渐增多的趋势。

   ```

   ```shell
   +---------------+----------+
   | 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 日志，发现有内存分配的报错。

   ```shell
   [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）。

Previous

[事务参与者数量过多导致事务悬挂和性能抖动](https://www.oceanbase.com/knowledge-base/oceanbase-database-20000048153)

Next

[悬挂事务恢复后排查](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000466060) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线