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

问题现象

触发场景

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

具体表现

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

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 任务日志中出现以下报错，表明清理阶段失败：

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 接口调用失败。

任务依赖关系如下：

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

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

诊断命令及预期结果

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

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. 在测试环境完整演练一次缩容流程后，再对生产环境执行。