---
title: OceanBase 集群 Zone 缩容以及缩容期间的报错-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于OceanBase 集群 Zone 缩容以及缩容期间的报错相关的常见问题和使用技巧，帮助您快速解决OceanBase 集群 Zone 缩容以及缩容期间的报错的难题。
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

# OceanBase 集群 Zone 缩容以及缩容期间的报错

更新时间：2026-08-25 02:41

适用版本： V3.1.x、V3.2.x、V3.3.x、V4.1.x、V4.2.x 内容类型：Troubleshoot  

## 问题现象

### 触发场景

在 OceanBase 集群运行过程中，因前期临时扩容或测试需求向集群中增加了 Zone，后续需要将该临时 Zone 从集群中移除以恢复原始架构。用户通过 OCP 控制台或黑屏命令对目标 Zone 1 执行删除操作时触发。

### 具体表现

1. 用户在 OCP 上点击删除 Zone 后，子任务长时间卡住或报错失败。
 2. 报错信息出现在 `cleanAllFiles` 阶段，OCP 任务日志中出现类似以下内容：

```plain
POST request to agent, url:http://:62888/api/v1/ob/cleanAllFiles
Set state for subtask: , operation:EXECUTE, state: FAILED

```

3. 部分场景下用户提前手动清理了节点上的 OceanBase 安装目录或卸载了 RPM 包，导致 OCP 的自动化清理步骤找不到对应文件或包。
 4. 若不先调整 Primary Zone 直接删除，可能导致删除过程中业务访问到正在下线的副本，出现短暂报错或事务中断。

### 影响范围

- 受影响的系统：目标 OceanBase 集群及该集群上所有租户。
 - 受影响的业务：在删除 Zone 期间，若 Leader 位于待删除 Zone 上，可能导致对应租户的业务出现短暂事务中断、锁等待增加或查询延迟升高。

### 发生频率

必现。只要集群存在多余的 Zone 且用户发起删除操作，均会触发该流程。

## 问题原因

### 根因分析（5 Why）

1. **为什么删除 Zone 的任务会卡住？** 因为 Clean observer host 子任务失败，导致后续依赖它的子任务无法执行。
 2. **为什么 Clean observer host 会失败？** 因为该子任务最后一步调用 Agent 的 `cleanAllFiles` 接口清理节点文件时失败。
 3. **为什么 `cleanAllFiles` 会失败？** 因为目标节点上的 OceanBase 安装包和安装目录可能已被人工提前清理，Agent 执行清理时找不到目标路径或文件。
 4. **为什么节点会被提前清理？** 因为用户在删除 Zone 前可能已经手动卸载了 RPM 包或删除了数据/日志目录，但未在 OCP 侧同步状态。
 5. **为什么 OCP 不知道节点已被清理？** 因为 OCP 的元数据库只记录集群拓扑和任务编排状态，不会实时感知节点操作系统层面的文件或 RPM 包变更。

### 技术原理说明

OCP 删除 Zone 的流程将操作编排为多个子任务，其中 Clean observer host 负责在节点上执行收尾清理：先停止 observer/obproxy 进程，再按固定顺序卸载 RPM 包（`oceanbase` → `oceanbase-ce` → `oceanbase-ce-utils` → `oceanbase-ce-libs`），最后调用 `cleanAllFiles` 清理残留的安装目录和数据目录。若节点已被人工干预清理，OCP 的自动化步骤会因找不到目标而失败。

### 是否为已知问题/Bug

否。这是正常的运维操作流程，属于 OCP 自动化任务与人工操作之间的状态不一致问题，非产品 Bug。

## 关键信息

OCP 任务日志中出现以下报错，表明清理阶段失败：

```plain
POST request to agent, url:http://192.168.132.131:62888/api/v1/ob/cleanAllFiles,
request body:CleanFilesRequest(obClusterName=xxx, obPath=ObPath(installPath=/home/admin/oceanbase, dataPath=/data/1, logPath=/data/log1))
Set state for subtask: 17780224, operation:EXECUTE, state: FAILED

```

`Clean_observer_host_17780224_FAILED.log` 中显示 `oceanbase-ce-utils`、`oceanbase-ce-libs` 在节点上已不存在，但真正导致子任务 FAILED 的是最后的 `cleanAllFiles` 接口调用失败。

任务依赖关系如下：

```plain
Subtask: [17780224] Clean observer host, State: FAILED
Subtask: [17780231] Delete zone, State: PENDING, Dependencies: [17780224]

```

Clean observer host 是 Delete zone 的前置依赖，前者失败后后者及后续所有子任务全部卡住。

### 诊断命令及预期结果

在待删除节点上执行以下命令，检查 RPM 包是否仍存在：

```bash
rpm -qa | grep oceanbase

```

- **若结果为空**：说明包已被手动卸载，可在 OCP 上跳过卸载子任务。
 - **若结果包含 `oceanbase-ce-utils`、`oceanbase-ce-libs`**：说明包仍存在，需排查 Agent 是否正常通信，或尝试重启 OCP Agent 后重试。

### 关键标识

- OCP 子任务 ID：如 17780224
 - Agent API 接口：`/api/v1/ob/cleanAllFiles`

## 问题的风险及影响

### 业务影响程度

中。若在业务高峰期操作或未提前将 Leader 切出待删除 Zone，可能导致该 Zone 上承载的业务出现短暂事务中断、锁等待或延迟增加。

### 系统风险评估

高。删除 Zone 的操作涉及副本迁移和集群拓扑变更，操作期间若再发生其他节点宕机，可能导致剩余副本不满足多数派，进而引发集群不可用。

### 是否有数据丢失风险

无。Zone 删除操作本身不会删除数据，数据副本会先迁移到其他 Zone。但如果操作过程中强行终止任务或同时出现其他故障，可能存在元数据不一致的风险。

## 影响租户

目标 OceanBase 集群上的所有租户（包括 sys 租户和业务租户）。

## 适用版本

OceanBase 数据库版本 V3.X 及以上版本，通过 OCP 平台纳管或黑屏手动管理的集群。

## 解决方法

### 详细操作步骤

#### 步骤 1：前置检查

1. 确认集群及所有租户处于「运行中」状态。
 2. 确认剩余副本满足多数派，即删除后 F/L 副本数量仍大于删除前总数的 1/2。
 3. 确认操作期间不会有其他节点宕机。

#### 步骤 2：调整 Primary Zone，将 Leader 切出待删除 Zone

通过 SQL 降低待删除 Zone 的优先级（以 zone1 为例），将 Leader 切出到其他 Zone。若集群有多个租户，需对每个业务租户执行。Sys 租户通常也需要调整。

也可通过 OCP 控制台白屏界面调整 Primary Zone。

#### 步骤 3：确认副本迁移完成

通过 OCP 页面或 SQL 观察 Leader 分布和副本迁移进度，确认待删除 Zone 上已无 Leader。

#### 步骤 4：在 OCP 上删除副本以及 Zone

1. 在 OCP 上执行删除副本操作。
 2. 在 OCP 上执行删除 Zone 操作。
 3. 若删除 Zone 时报错（如 `cleanAllFiles` 失败），按步骤 5 处理。

#### 步骤 5：处理卸载子任务失败

若任务在 `cleanAllFiles` 或卸载步骤报错：

1. 登录目标节点，执行 `rpm -qa | grep oceanbase`。
 2. 若结果为空（包已手动删除），在 OCP 任务详情页找到失败的子任务，点击「跳过」。
 3. 若包存在但 OCP 检测不到，重启该节点的 OCP Agent 服务后，在 OCP 上重试子任务。

### 操作风险评估

中高风险。涉及集群拓扑变更和 Leader 切换，操作期间集群容错能力下降。

### 预计恢复时间

- Primary Zone 调整 + Leader 切换：通常 1~5 分钟。
 - 副本迁移：取决于数据量，可能数分钟至数小时。
 - Zone 删除本身：1~10 分钟。

### 回滚方案

若删除 Zone 后发现问题，可重新向集群中添加同名的 Zone，并执行扩容操作恢复副本分布。但重新添加 Zone 后需要重新均衡副本，耗时较长。

## 规避方式

### 预防措施

1. 扩容时若仅作临时用途，应在需求结束后尽快规划缩容，避免临时节点长期存在于集群中。
 2. 缩容前务必在低峰期操作，并提前通知业务方。
 3. 不要在 OCP 删除 Zone 之前手动清理节点上的安装包或目录，应让 OCP 完成完整流程；若已手动清理，需提前告知运维人员准备跳过对应子任务。

### 监控告警建议

1. 在 OCP 上开启集群状态告警，监控 Zone 状态、Leader 分布和副本迁移进度。
 2. 缩容操作期间加强对集群可用性和节点状态的监控，确保操作期间无其他节点异常。

### 最佳实践推荐

1. 严格按照"先切 Leader、再删 Zone"的顺序操作，不要在 Leader 未切出前直接删除 Zone。
 2. 对于多租户集群，逐个租户调整 Primary Zone，避免一次性大批量修改导致系统负载突增。
 3. 在测试环境完整演练一次缩容流程后，再对生产环境执行。

上一篇

[租户内存不足导致 allocate memory fail](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006739705)

下一篇

[Oracle 租户事务型临时表实现细节](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006802567) ![有帮助](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) 咨询热线